- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 25 Aug 2021 17:01:00 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `nesting of @supports inside @font-face`.
<details><summary>The full IRC log of that discussion</summary>
<TabAtkins> Topic: nesting of @supports inside @font-face<br>
<TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/6520<br>
<TabAtkins> leaverou: A little background, in the TAG review request the current syntax is extending the format() syntax for 'src'<br>
<lea> https://github.com/w3c/csswg-drafts/blob/main/css-fonts-4/src-explainer.md#use-case-3-detectability<br>
<TabAtkins> leaverou: It hasn't been implemented yet; Chrome is keen to implement quickly<br>
<TabAtkins> leaverou: In the TAG we recognized the use-case, but were concerned about a new microsyntax when @supports alreayd exists<br>
<TabAtkins> leaverou: So was thinking about how we could utilize @supports, and posted this issue<br>
<chris> Explainer for current src descriptor https://github.com/w3c/csswg-drafts/blob/main/css-fonts-4/src-explainer.md<br>
<TabAtkins> leaverou: Two things. First, adding a new @supports query for detecting font tech.<br>
<TabAtkins> leaverou: Lets authors differentiate their CSS in other places; existing proposal only lets them use it when selecting font source.<br>
<TabAtkins> leaverou: Could imagine authors wanting different CSS for a monochrome vs color font<br>
<drott> q+<br>
<TabAtkins> leaverou: This also makes it much easier to programmatically detect, vs doing rule hacking and seeing if there is a syntax error<br>
<TabAtkins> leaverou: Google said they could add the font-tech queries in @supports easily<br>
<TabAtkins> leaverou: Second bit is to let @supports nest inside of @font-face, extending the Nesting proposal<br>
<TabAtkins> leaverou: But that would be a more substantial request<br>
<TabAtkins> leaverou: So proposal is just to add the @supports queries for now - it does the job, if a bit clunky. And in the future perhaps do the nesting thing.<br>
<Rossen_> ack drott<br>
<TabAtkins> drott: Good summary. I'd support font-tech queries in @supports<br>
<chris> q+<br>
<TabAtkins> drott: And am open to later improving it by integrating Nesting, but the immediate benefit is just feature detection, so the @supports queries works for me.<br>
<emilio> q+<br>
<TabAtkins> drott: I've made a syntax proposal for Conditional 4 to support this<br>
<Rossen_> ack chris<br>
<TabAtkins> chris: I wrote an explainer for it<br>
<TabAtkins> chris: [missed due to chop]<br>
<drott> 👍<br>
<TabAtkins> chris: TAG asked for an explainer; having written it, it was clear the only benefit of the existing syntax is that old browsers would parse without falling over<br>
<TabAtkins> chris: It has no other redeeming features. It's an ugly complex microsyntax and is hard to read<br>
<Rossen_> q?<br>
<TabAtkins> chris: I think using @supports makes sense even if we can't use it directly in @font-face<br>
<TabAtkins> chris: We've got some examples in the thread and I think it reads easily<br>
<TabAtkins> emilio: I like this<br>
<myles> q+<br>
<Rossen_> ack emilio<br>
<TabAtkins> emilio: Only question is if there's another place we need to parse this font stuff?<br>
<chris> q+<br>
<TabAtkins> emilio: To avoid the "specialized parser" thing that we try to avoid with @supports<br>
<fantasai> TabAtkins: while trying to avoid specialized parse is a general goal<br>
<fantasai> TabAtkins: we recognized there will be cases where we do<br>
<fantasai> TabAtkins: as long as we're carefully scoped wrt feature queries that are not just parsing-based, should be OK<br>
<TabAtkins> myles: One question - if an author uses @supports, is there a way to say "else"?<br>
<TabAtkins> myles: If there's not a way to do that... @font-faces join together to form a family, rather than overriding<br>
<Rossen_> q?<br>
<Rossen_> ack myles<br>
<TabAtkins> emilio: Can use "not"?<br>
<TabAtkins> myles: "not" is both "fails the query" and "doesn't understand"<br>
<TabAtkins> chris: Usual fallback is to put something normal outside, then override in a @supports<br>
<TabAtkins> myles: Right, that's problematic; if it's supported it'll define a combined family using both @font-face rules.<br>
<TabAtkins> myles: Author probably wants it to override<br>
<drott> q+<br>
<TabAtkins> myles: If they're careful they might override, like all same weight/etc, but if they didn't they'll both be present<br>
<lea> q+<br>
<chris> q+<br>
<TabAtkins> q+<br>
<fantasai> myles: and they will join together to form a family<br>
<fantasai> myles: if descriptors aren't identical, might end up using both fonts in the page instead of only the second one<br>
<chris> q-<br>
<TabAtkins> chris: we already have this thing where font faces can combine together into a family, that's be design<br>
<fantasai> TabAtkins: he's saying that conflicts with the author's design here.<br>
<TabAtkins> myles: Right, if you have the non-conditional outside and the conditional inside, that's brittle<br>
<emilio> TabAtkins: this is a general problem with a lot of things<br>
<emilio> ... we don't have an answer to negate a query, but there's a proposal for an "else" on conditional rules<br>
<dbaron[m]> some of these problems seem specific to @font-face inside @supports rather than @supports inside @font-face<br>
<lea> q?<br>
<fantasai> +1 dbaron[m]<br>
<emilio> ... if there's implementor interest I'd be happy to revive it<br>
<TabAtkins> https://tabatkins.github.io/specs/css-when-else/<br>
<Rossen_> ack TabAtkins<br>
<emilio> myles: I think there isn't a lot of sense to build the stopgap solution on something that doesn't exist yet<br>
<TabAtkins> myles: If the oracle delivered us some way of having an else attached to @supports tomorrow, that woudl solve the problem<br>
<chris> q+ to say format strings were a stopgap that lasted 2 1/2 decades<br>
<TabAtkins> drott: I think this is an improvement over the current proposed syntax<br>
<TabAtkins> drott: You're basing this on the concern on the likelihood of a typo; I think most will be coming from 3rd party fonts so that's not really a concern<br>
<Rossen_> ack drott<br>
<TabAtkins> drott: Second, in browsers where author expects font-tech(color) to work, "not" would work<br>
<TabAtkins> myles: I think it would help if after this call we could have an example of the fallback<br>
<chris> the issue already has such an example<br>
<TabAtkins> lea: There's a snippet in the issue that Chris posted<br>
<Rossen_> q?<br>
<Rossen_> ack lea<br>
<TabAtkins> leaverou: I think drott mentioned most points<br>
<TabAtkins> leaverou: Reminder that this isn't *ideal* but it can be done quickly, and when we go on to nesting it'll work without duplication<br>
<TabAtkins> leaverou: Also think ahving "else" in a conditional block would be super useful; it shouldn't hold this up tho.<br>
<drott> +1 for not blocking on an else block<br>
<TabAtkins> Agreed, fwiw<br>
<Rossen_> ack dbaron[m]<br>
<Zakim> dbaron[m], you wanted to react to lea<br>
<TabAtkins> But happy to lean on this to grab impl support ^_^<br>
<Rossen_> ack dbaron[m]<br>
<TabAtkins> dbaron[m]: My understanding of myles' concern is - I think a lot applies if we have @supports { @font-face{}}, but a lot of the proposal is doing @font-face { @supports{}}, and I don't think the interaction concerns apply in that case<br>
<Rossen_> q<br>
<TabAtkins> myles: Right. I have different feedback in that case, but the proposal is currently the first case.<br>
<lea> q?<br>
<TabAtkins> fantasai: First, given myles' example, I do have concern about allowing this without inline/nested supports, becuase of his mentioned concerns<br>
<lea> q+ to say that this problem actually exists today when defining font families, it's not new<br>
<TabAtkins> fantasai: Second, it seems the proposal is to add font-technology() function which include some features that could be part of a font format, but it's not clear to me how that relates tot he font format<br>
<drott> q+<br>
<TabAtkins> fantasai: What if the browser supports colorv1 in woff2, but not others. Would we need to tie the feature query to a font format?<br>
<Rossen_> ack fantasai<br>
<drott> q-<br>
<TabAtkins> chris: woff1 and woff2 are encodings of the same font tech (truetype)<br>
<chris> 1. stopgap 2. OM complexity inside @font-face 3. making other stylistic changes based on font support 4. unrelated to formats<br>
<Rossen_> ack chris<br>
<Zakim> chris, you wanted to say format strings were a stopgap that lasted 2 1/2 decades<br>
<TabAtkins> chris: The entire format string was a stopgap because we didn't have font mime types<br>
<TabAtkins> chris: So "stopgap" is a non-argument in my mind<br>
<TabAtkins> chris: If we do put @supports inside @font-face it complicates the OM; current proposal avoid that<br>
<TabAtkins> chris: Using @supports doesn't just allow switching font, it lets you vary other aspects of your style<br>
<TabAtkins> chris: Finally, the only reason supports were smuggled into format string is for parsing. But spec actually mandates OpenType and TrueType treated the same.<br>
<TabAtkins> chris: So the font technology is almost completely orthogonal to the format used<br>
<myles> q+ to respond to chris<br>
<drott> q+<br>
<TabAtkins> chris: So decoupling as this proposal does is a much clearner and nicer way<br>
<chris> q?<br>
<Rossen_> ack lea<br>
<Zakim> lea, you wanted to say that this problem actually exists today when defining font families, it's not new<br>
<myles> q-<br>
<TabAtkins> lea: The concern myles brought up about typos is already existant; when authors write a family they could already typo and have the wrong family happen<br>
<Rossen_> ack drott<br>
<TabAtkins> drott: as lea mentioned, the reason we brought to the TAG is it seemed helpful to get some time of feature detection for COLR v1, so I hope we can have CSS support for that at the same time<br>
<TabAtkins> Rossen_: I think the TAG feedback was clear - colr1 was gonna be a great addition<br>
<chris> s/was/is/<br>
<TabAtkins> Rossen_: Introducing new microsyntaxes is generally discouraged when we have existing feature-detect capabilities<br>
<TabAtkins> Rossen_: I appreciate you ahve some impl urgency on your end. Important to get what's gonna stick for the future right tho.<br>
<Rossen_> q?<br>
<TabAtkins> Rossen_: So not sure I'm hearing the solution that addresses the current user needs and the tech being proposed<br>
<chris> s/colr1/COLRv1<br>
<TabAtkins> Rossen_: With two minutes remaining, unsure if we'll have a resolution<br>
<TabAtkins> Rossen_: Propose we continue in the issue and bring this back next week for resolution<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-905712330 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 25 August 2021 17:01:03 UTC