[css-values-3] Serialisation of empty url() undefined

[gsnedders]

https://drafts.csswg.org/css-values-3/#url-empty, with tests at https://github.com/web-platform-tests/wpt/blob/master/css/css-values/urls/empty.html

This section states:

If the value of the url() is the empty string (like url("") or url()), the url must resolve to an invalid resource (similar to what the url about:invalid does).

This doesn't appear to define what the computed value of an empty url() is, thus it would appear to be undefined. The tests (by @emilio) assert that the value is about:invalid, rather than it merely being similar to it (resolving to an abstract invalid resource).

Compare with, under Relative URLs above:

When a appears in the computed value of a property, it is resolved to an absolute URL, as described in the preceding paragraph. The computed value of a URL that the UA cannot resolve to an absolute URL is the specified value.

Current implementation status is:

• Blink has not implemented e051892 (which changed the empty URL behaviour)
• Gecko has, and uses about:invalid
• WebKit has not implemented the change

[css-meeting-bot]

The CSS Working Group just discussed Serialization of empty url(), and agreed to the following:

• RESOLVED: serialize as url("")

The full IRC log of that discussion

Topic: Serialization of empty url()
github: https://github.com//issues/6447
smfr: CSS Values talks about empty URLs and how we avoid normal behavior of resolving against stylesheet URL
smfr: empty treated as involved
smfr: and we introduced "about:invalid" as a URL
smfr: which is what Gecko serializes
smfr: ??? serializes the resolved URL which is wrong
smfr: but I think empty URLs serialize as such
TabAtkins: That was my intention, and I'm happy to adjust spec to make it clearer
smfr: Also do we serialize as url() or url("")
TabAtkins: I think completely empty URL, is that even valid?
fantasai: it is valid, just tested
fantasai: it is valid, i just tested
TabAtkins: That would be a serialization nobody uses
TabAtkins: so I lean toward url("") because at least one browser is doing that currently
emilio: Who?
TabAtkins: whoever is passing that test
emilio: smfr updated the test to use empty string
emilio: but Firefox serializes as about:invalid and I don't know what WebKit and Blink do
https://wpt.fyi/results/css/css-values/urls/empty.html?label=experimental&label=master&aligned
TabAtkins: nevermind, nobody passes that
smfr: Test expect everything becomes quoted
TabAtkins: let me see if CSSOM specifies anything
TabAtkins: yes, CSSOM expects all URL functions to contain a string
https://drafts.csswg.org/cssom/#serialize-a-url
TabAtkins: regardless of whether inputted with or without quotes
https://drafts.csswg.org/cssom/#serialize-a-url
TabAtkins: so for consistency, empty url() should also serialize with quotes
astearns: so proposed resolution is to make this test valid, using quoted empty string?
emilio: before we resolve, I wanted to make an argument for url()
emilio: if you consider invalid URL not a URL
emilio: but I'm fine
astearns: If you're fine with the explicitly quoted empty string, I think it makes much more sense, it's consistent
astearns: any objections?
RESOLVED: serialize as url("")
myles: I didn't quite catch it, but is your reasoning about wanting @else *before/alongside* font-supports() becuase of the "unknown value" issue making negation hard?
TabAtkins: am I reading your draft right that @else can also directly follow an @supports or @media, and not just an @if?
yes
zakim, end meeting
As of this point the attendees have been jensimmons, rachelandrew, drott, Morgan, jfkthame, smfr, miriam, TYLin, chrishtr, cbiesinger, dandclark, alisonmaher, lea, dlibby, oriol,
... TabAtkins, bkardell_, chris, dholbert, GameMaker, emilio, bradk
RRSAgent, please draft minutes v2
I have made the request to generate https://www.w3.org/2021/09/15-css-minutes.html Zakim
I am happy to have been of service, astearns; please remember to excuse RRSAgent. Goodbye
I didn't want @if to be "the new conditional rule" replacing all the others
it's just needed to get else-chaining working properly when you're querying across feature sets
@tabatkins: how would someone use @supports without @else to use a color font on a browser that supports it, but use a fallback font instead if the browser doesn't?
I said up above (in IRC, not on phone) - @supports doesn't use the unknown value. Unknown things are just false, so you can negate them normally.
Or I should say, *unrecognized* things are false, to avoid confusion. ^_^
@tabatkins: so if the author says "@supports colorfonts { @font-face { colorfont } } @supports not colorfonts { @font-face { notcolorfont } }" you're saying that this will work?
yup
at least per spec!
(well, that exact syntax actually violates the grammar so both would be thrown out as invalid rules, but wrap those suckers in parens or turn them into functions and you're golden)
That's nice, I was going to suggest it actually
oh wait, you're replying to Myles, not me
reading higher up, comment still applies though, nice nice :)
@tabatkins: yeah, when this topic first came up to the WG i asked if this was possible and the WG said no
Yeah, I think that's what prompted us to decide that @supports doesn't use the unknown bool
Because if a browser doesn't understand a syntax, it doesn't understand the feature (and the chance of disconnect when a specialized supports syntax is added well after a feature is implemented was considered not worth worrying about)
https://github.com//issues/6520#issuecomment-905712330
(I could be misremembering the ordering tho)
@tabatkins: myles: One question - if an author uses @supports, is there a way to say "else"? | myles: If there's not a way to do that... @font-faces join together to form a family, rather than overriding
yeah, i misremembered during that meeting, sorry

[tabatkins]

Fixed per WG resolution, assuming commenter satisfied.