[css-values-3] Serialisation of empty url() undefined #6447
Labels
Closed Accepted by CSSWG Resolution
Commenter Satisfied
Commenter has indicated satisfaction with the resolution / edits.
css-values-3
Comments
|
The CSS Working Group just discussed
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
added a commit
that referenced
this issue
Oct 12, 2022
|
Fixed per WG resolution, assuming commenter satisfied. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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:
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:
Current implementation status is:
about:invalidThe text was updated successfully, but these errors were encountered: