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