[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 <url> 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

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

[tabatkins]

Fixed per WG resolution, assuming commenter satisfied.