- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 15 Sep 2021 16:44:48 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Nesting @supports inside @font-face / font tech queries`, and agreed to the following:
* `RESOLVED: Adopt if/else as next level of css-conditional`
* `RESOLVED: Accept the PR`
<details><summary>The full IRC log of that discussion</summary>
<fantasai> Topic: Nesting @supports inside @font-face / font tech queries<br>
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/6520<br>
<fantasai> chris: Basic problem is that we need a way to ensure that only one of the possible options works<br>
<fantasai> chris: if you have unicode-range and a character outside that range, all the others will be loaded to see if it has that char<br>
<fantasai> chris: so this has been paired with another issue<br>
<fantasai> chris: It seems we need to discuss together<br>
<fantasai> lea: Looks like primary problem with using @supports is that pattern<br>
<fantasai> lea: of older code being unwrapped, but wrapping new code in @supports<br>
<fantasai> lea: but that doesn't work well with @font-face<br>
<fantasai> lea: because the second rule doesn't override the first rule<br>
<fantasai> lea: they combine to form a single family<br>
<fantasai> lea: although normally only second font is used<br>
<chris> q+ to add that the existing format overload does have the "only one wins" characteristic<br>
<fantasai> lea: if browser encounters character not in the second, it will download the first to check if it is there<br>
<fantasai> lea: so for this we would need an else condition<br>
<fantasai> lea: so that we never have both @font-face rules in effect at the same time<br>
<fantasai> lea: There's a proposal from Tab to combine feature queries and media queries, and has else<br>
<drott> q+<br>
<fantasai> lea: Tab suspects it's easy to implement<br>
<fantasai> lea: if this can be implemented together with font-technology(), that would be nice<br>
<fantasai> lea: concern that if implement without it, we'll have this problematic pattern<br>
<astearns> ack chris<br>
<Zakim> chris, you wanted to add that the existing format overload does have the "only one wins" characteristic<br>
<fantasai> chris: Overloading the format string does have this benefit of combining the conditionals properly<br>
<lea> q?<br>
<fantasai> chris: if we don't rapidly converge, we'll be stuck with that<br>
<fantasai> astearns: So you're concerned to get if/else quickly so that practice doesn't ossify into bad syntax<br>
<fantasai> chris: people will just ship what's in the spec now<br>
<fantasai> myles: I thought we would remove the complicated resource grammar<br>
<astearns> ack drott<br>
<fantasai> drott: I spoke to implementers, to Anders and Rune who are familiar with our CSS code<br>
<fantasai> drott: They have no immediate concerns with the when/else proposal<br>
<fantasai> drott: Which brings my question of timing<br>
<chris> \0/ to no concerns!<br>
<fantasai> drott: I'm also supportive of removing the syntax in the spec now<br>
<fantasai> drott: but eager to have something to enable font tech feature testing atm<br>
<fantasai> drott: We're supportive of the when/else proposal, but it would be better to have font tech queries soon and maybe when/else as an upgrade path<br>
<fantasai> astearns: Is it possible to have a font-tech syntax in the @font-face that would handle the conditional?<br>
<fantasai> drott: Current feature in spec is encapsulated in src descriptor<br>
<fantasai> drott: in the format() function<br>
<fantasai> drott: Authors can order it by most advanced tech, and then the UA will pick the one that it supports<br>
<fantasai> drott: In current proposal, without @else we have an accumulation of fonts into the family<br>
<lea> astearns: https://drafts.csswg.org/css-fonts-4/#font-face-src-parsing<br>
<lea> ^ that is the current syntax<br>
<fantasai> astearns: Would it be possible to have a limited state for this font technology where you could put it into your @font-face and have a font face exist if the font technology was supported, but have it not exist if it wasn't<br>
<fantasai> astearns: no fallback, just make this font face if the tech is supported<br>
<fantasai> drott: You could use different families<br>
<fantasai> lea: If you don't want fallback, that's fine. You just make an @font-face<br>
<fantasai> astearns: so wanted to remove things from spec, remove the current syntax<br>
<fantasai> astearns: in favor of clearer if/else<br>
<fantasai> astearns: but people still want conditional on font<br>
<fantasai> astearns: and it would be nice to have that font tech<br>
<fantasai> chris: we need to do both<br>
<fantasai> chris: for a solution<br>
<drott> fantasai: I think we had previous notes on this, can't find it<br>
<drott> fantasai: it was basically: we should have both, the font-technology function in @supports, and the ability to query the tech in the format function, and they should share the syntax. And the syntax should be simpler.<br>
<astearns> s/would handle the conditional/would not handle the conditional with fallback/<br>
<chris> q+<br>
<drott> fantasai: for @supports, you might want to query not only if it's color, but you might want to query for format<br>
<drott> fantasai: I would simplify the syntax of the font-technology function.<br>
<drott> q+<br>
<drott> fantasai: In a way to remove the sub functions, and just have a list of keywords, for example font-format-...<br>
<fantasai> fantasai: ....<br>
<fantasai> drott: I think you did post it somewhere, I had updated my pull request to flatten it...<br>
<fantasai> chris: ...<br>
<drott> q-<br>
<lea> q?<br>
<lea> q+<br>
<fantasai> chris: The format shouldn't be the orphan that gets left behind that you have to do in src, it should be same conditional thing that we do in font-technology<br>
<fantasai> chris: so if woff5 comes along, we can also put that in this new shiny syntax<br>
<astearns> ack chris<br>
<drott> fantasai: it should be the same function, for format and font technology<br>
<chris> I don't really like calling it font-format<br>
<fantasai> lea: If I understand correctly, a format should also have been a condition in @supports<br>
<chris> yes exactly lea<br>
<fantasai> lea: if designing today that's how we would do that<br>
<fantasai> lea: only reason we have format function is that it's legacy<br>
<chris> we can't get *rid* of the format legacy though, so it has to remain in the spec<br>
<fantasai> lea: so I think what Chris is saying is that we also need to be adding a font-format() function into @supports so that authors can combine @font-technology queries<br>
<fantasai> lea: whereas what fantasai is saying is to have only format() function, and have it allowed both in src and @supports<br>
<fantasai> s/chris: .../lea: I think that was my proposal to flatten from color() to color-/<br>
<fantasai> astearns: So we're looking for a way to express simper supports queries in @font-face rules<br>
<fantasai> astearns: and remove fallback ability<br>
<drott> fantasai: I think we're not aiming to remove fallback<br>
<fantasai> chris: The things that drott proposed, it would be helpful to allow that as a direct query in @supports conditions<br>
<fantasai> myles: I think adding that should be blocked on having some way of solving the problem that jfkthame described<br>
<drott> q+<br>
<astearns> ack lea<br>
<fantasai> astearns: ?<br>
<fantasai> lea: No way to do else, so authors will need to negate their queries<br>
<fantasai> lea: and it would get very verbose and complicated<br>
<fantasai> myles: not even sure if it's possible<br>
<fantasai> myles: because there's a third value here, not just supported or not supported, but also case of "browser doesn't know what you're talking about"<br>
<fantasai> chris: So need a resolution on proposal, but also how do we move forward on Tab's draft<br>
<fantasai> chris: Can we adopt it as an ED?<br>
<fantasai> myles: We should split this font-specific issue<br>
<fantasai> myles: one piece blocked on else rule and one that isn't<br>
<drott> q?<br>
<fantasai> myles: and discuss else rule in its own CSSWG issue<br>
<astearns> ack drott<br>
<fantasai> drott: I discussed this issue with jfkthame offline. I think he's here?<br>
<chris> this is its issue: https://github.com/w3c/csswg-drafts/issues/112<br>
<fantasai> drott: In our question, jfkthame expressed some flexibility regarding timing<br>
<fantasai> drott: I'd like to emphasize what chris was saying earlier, if we move the supports syntax from CSS as it is now, then we don't have anything to do feature testing<br>
<fantasai> drott: I consider @supports an upgrade path<br>
<fantasai> myles: I've heard some people say they want to remove unimplemented flexbility in the spec now, and others don't want to remove it but to reformulate to make it simpler<br>
<fantasai> myles: either one is reasonable to me<br>
<fantasai> lea: which part is blocked on what?<br>
<fantasai> myles: If we want to keep the unimplemented features of the format() in src, we wouldn't need to be blocked on else<br>
<TabAtkins> It is true that `@supports unknown-font-thing() {...} @support not (unknown-font-thing()) {...}` will fail to match both of them (the first is unknown, treated as false; the second is negated unknown, which is still unknown and thus treated as false)<br>
<fantasai> lea: the problem with that is that we don't want microsyntaxes<br>
<TabAtkins> whereas `@support unknown-font-thing() {...} @else {...}` would match one or the other, guaranteed.<br>
<lea> q+<br>
<astearns> ack lea<br>
<fantasai> lea: Important point from the issue drott raised hasn't be raised yet<br>
<fantasai> lea: else is syntactic sugar for negation<br>
<fantasai> lea: but another way to work around is to use unicode-range<br>
<fantasai> lea: drott mentioned that most font-face rules are generated, and have unicode-range alreay<br>
<fantasai> lea: which means this isn't a problem<br>
<fantasai> myles: unicode-range is an orthogonal feature<br>
<TabAtkins> Oh wait, sorry, I was wrong - @supports doesn't use the unknown value.<br>
<fantasai> myles: if author is trying to use fancy syntax that is / isn't supported<br>
<TabAtkins> We resolved on that a bit ago.<br>
<fantasai> myles: both @font-face rule and fallback will have the same unicode-range<br>
<TabAtkins> Unknown things are just false in @supports.<br>
<fantasai> myles: so the problem still applies<br>
<fantasai> lea: Problem is if the character is not included in the range<br>
<fantasai> myles: problem that I'm concerned about is that character is inside the unicode-range block, but not supported by the font's CMAP table<br>
<fantasai> myles: in that case the browser will download both fonts serially<br>
<fantasai> drott: Should have unicode-range identical to CMAP<br>
<TabAtkins> So my statement above was wrong - both are equivalent, and you'll definitely select one or the other. (We use unknown for @media, where the browser very well *might* match an unknown query once it starts supporting it; a browser that doesn't understand a feature, by definition, doesn't support it, so that's a safe `false`.)<br>
<drott> fantasai: Lea was concerned about multiple different microsyntaxes. My proposal doesn't do that. Format function, should have identical syntax, whether it's in src: or in @supports.<br>
<lea> q+<br>
<astearns> ack fantasai<br>
<drott> fantasai: If that's the case, we can ship src: first - ship @supports version later.<br>
<drott> q+<br>
<astearns> ack lea<br>
<fantasai> lea: There's another unexplored option<br>
<fantasai> lea: what if we had an inline conditional function that does supports queries<br>
<fantasai> lea: A supports() or supports-if() function to put inside any value<br>
<fantasai> astearns: I think it would be a good idea to write down what you're suggesting, Lea<br>
<fantasai> astearns: but getting a proliferation of options, unsure we can get to resolution on anything specific today<br>
<astearns> ack drott<br>
<fantasai> astearns: I think we can resolve at least that we would like to work on the if/else syntax<br>
<fantasai> TabAtkins: Adopt as an ED in the WG? Currently draft in my personal repo<br>
<lea> +1 to working on @else proposal<br>
<jfkthame> +1<br>
<fantasai> astearns: resolution would be to adopt, yes<br>
<fantasai> fantasai: so that would be css-conditional-3?<br>
<fantasai> TabAtkins: sure<br>
<drott> q+<br>
<astearns> ack drott<br>
<fantasai> drott: potentially add any resolution, then idea would be to have a font-tech function to combine with that?<br>
<TabAtkins> I also was udner the impression that Conditional started with 1.<br>
<fantasai> dbaron[m]: I think conditional-3 is already advanced<br>
<drott> +1 to that.<br>
<fantasai> fantasai: oh, I meant whatever's next<br>
<drott> sorry, fantasai, I did not capture what you said.<br>
<fantasai> RESOLVED: Adopt if/else as next level of css-conditional<br>
<fantasai> astearns: So question of current font-technology draft and reworking them with existence of if/else in mind<br>
<fantasai> astearns: so take back to issue to determine what changes, if any, need to be made<br>
<fantasai> chris: I don't see a dependency there<br>
<fantasai> chris: I think we can adopt PR as-is<br>
<drott> +1 as well<br>
<fantasai> lea: +1<br>
<fantasai> lea: this is something useful immediately<br>
<TabAtkins> +1<br>
<drott> zes<br>
<fantasai> astearns: Adopting PR will resolve the issue?<br>
<drott> s/zes/yes<br>
<fantasai> lea: the bulk of it<br>
<fantasai> astearns: And we can open new more tightly constrianed issues<br>
<fantasai> astearns: So proposed resolution?<br>
<fantasai> drott: Adds font-technology() function to @supports, which has a flat list of font technologies and options, which can be used inside an @supports rule<br>
<drott> https://github.com/drott/csswg-drafts/commit/62cfd95a5f52604c952e4aa37be6e4d6386f88f5<br>
<fantasai> myles: the @else rule should make it clear that it works with this new query inside @supports<br>
<fantasai> myles: either explicitly or implicitly<br>
<fantasai> myles: And i'd ask implementers not to implement font-technology() without @else<br>
<fantasai> myles: because if you oonly give ability to do it wrong, people will do it wrong<br>
<fantasai> lea: why?<br>
<dbaron[m]> That request to implementers should be in the spec.<br>
<fantasai> myles: because @else is the solution to this problem, so one depends on the other<br>
<jensimmons> +1 to myles<br>
<lea> s/lea: why?/lea: they can still do it right, it's just tedious/<br>
<drott> fantasai: I am not sure, I agree with this particular PR.<br>
<dbaron[m]> s/sure,/sure/<br>
<drott> fantasai: I think the function should have identical syntax to what we should have in src:.<br>
<drott> q+<br>
<drott> fantasai: one question I have: font-technology - would this be allowed to be queries in src:?<br>
<drott> s/queried/queries<br>
<drott> s/queried/queries/<br>
<fantasai> astearns: I think we should merge it in and take separate issues<br>
<fantasai> chris: I edit both specs anyway<br>
<drott> +1 to that, if we can have the font-technology PR<br>
<fantasai> myles: but if we're making src less flexible than it is to day (in ths spec)<br>
<astearns> ack drott<br>
<fantasai> fantasai: happy to do so, as long as we can work on it and not just ship what's in the PR<br>
<chris> @drott I see the PR on your fork repo but not the one on the csswg repo<br>
<fantasai> myles: I think it's OK to resolve this, I think fantasai's idea about making them match makes sense to me<br>
<fantasai> myles: I think making them match gives drott a path to implementing that doesn't rely on us standadizing a big new feature<br>
<fantasai> myles: so I think that's the best path forward<br>
<fantasai> astearns: we're not got to solve everything today<br>
<fantasai> astearns: so let's merge the PR and file more issues<br>
<drott> +1<br>
<lea> +1<br>
<chris> +1<br>
<fantasai> astearns: any objections?<br>
<fantasai> RESOLVED: Accept the PR<br>
<chris> :)<br>
<fantasai> myles: Can we add a note to the PR to say "don't implement this yet, implement this other thing first"<br>
<fantasai> astearns: open an issue<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6520#issuecomment-920187550 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 16:44:51 UTC