– DRAFT –
Cascading Style Sheets (CSS) Working Group Teleconference

Nesting @supports inside @font-face / font tech queries

github: https://github.com/w3c/csswg-drafts/issues/6520

chris: Basic problem is that we need a way to ensure that only one of the possible options works

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

chris: so this has been paired with another issue

chris: It seems we need to discuss together

lea: Looks like primary problem with using @supports is that pattern

lea: of older code being unwrapped, but wrapping new code in @supports

lea: but that doesn't work well with @font-face

lea: because the second rule doesn't override the first rule

lea: they combine to form a single family

lea: although normally only second font is used

lea: if browser encounters character not in the second, it will download the first to check if it is there

lea: so for this we would need an else condition

lea: so that we never have both @font-face rules in effect at the same time

lea: There's a proposal from Tab to combine feature queries and media queries, and has else

lea: Tab suspects it's easy to implement

lea: if this can be implemented together with font-technology(), that would be nice

lea: concern that if implement without it, we'll have this problematic pattern

<Zakim> chris, you wanted to add that the existing format overload does have the "only one wins" characteristic

chris: Overloading the format string does have this benefit of combining the conditionals properly

chris: if we don't rapidly converge, we'll be stuck with that

astearns: So you're concerned to get if/else quickly so that practice doesn't ossify into bad syntax

chris: people will just ship what's in the spec now

myles: I thought we would remove the complicated resource grammar

drott: I spoke to implementers, to Anders and Rune who are familiar with our CSS code

drott: They have no immediate concerns with the when/else proposal

drott: Which brings my question of timing

<chris> 0/ to no concerns!

drott: I'm also supportive of removing the syntax in the spec now

drott: but eager to have something to enable font tech feature testing atm

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

astearns: Is it possible to have a font-tech syntax in the @font-face that would not handle the conditional with fallback?

drott: Current feature in spec is encapsulated in src descriptor

drott: in the format() function

drott: Authors can order it by most advanced tech, and then the UA will pick the one that it supports

drott: In current proposal, without @else we have an accumulation of fonts into the family

<lea> astearns: https://drafts.csswg.org/css-fonts-4/#font-face-src-parsing

<lea> ^ that is the current syntax

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

astearns: no fallback, just make this font face if the tech is supported

drott: You could use different families

lea: If you don't want fallback, that's fine. You just make an @font-face

astearns: so wanted to remove things from spec, remove the current syntax

astearns: in favor of clearer if/else

astearns: but people still want conditional on font

astearns: and it would be nice to have that font tech

chris: we need to do both

chris: for a solution

<drott> fantasai: I think we had previous notes on this, can't find it

<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.

<drott> fantasai: for @supports, you might want to query not only if it's color, but you might want to query for format

<drott> fantasai: I would simplify the syntax of the font-technology function.

<drott> fantasai: In a way to remove the sub functions, and just have a list of keywords, for example font-format-...

fantasai: ....

drott: I think you did post it somewhere, I had updated my pull request to flatten it...

lea: I think that was my proposal to flatten from color() to color-

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

chris: so if woff5 comes along, we can also put that in this new shiny syntax

<drott> fantasai: it should be the same function, for format and font technology

<chris> I don't really like calling it font-format

lea: If I understand correctly, a format should also have been a condition in @supports

<chris> yes exactly lea

lea: if designing today that's how we would do that

lea: only reason we have format function is that it's legacy

<chris> we can't get *rid* of the format legacy though, so it has to remain in the spec

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

lea: whereas what fantasai is saying is to have only format() function, and have it allowed both in src and @supports

astearns: So we're looking for a way to express simper supports queries in @font-face rules

astearns: and remove fallback ability

<drott> fantasai: I think we're not aiming to remove fallback

chris: The things that drott proposed, it would be helpful to allow that as a direct query in @supports conditions

myles: I think adding that should be blocked on having some way of solving the problem that jfkthame described

astearns: ?

lea: No way to do else, so authors will need to negate their queries

lea: and it would get very verbose and complicated

myles: not even sure if it's possible

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"

chris: So need a resolution on proposal, but also how do we move forward on Tab's draft

chris: Can we adopt it as an ED?

myles: We should split this font-specific issue

myles: one piece blocked on else rule and one that isn't

myles: and discuss else rule in its own CSSWG issue

drott: I discussed this issue with jfkthame offline. I think he's here?

<chris> this is its issue: https://github.com/w3c/csswg-drafts/issues/112

drott: In our question, jfkthame expressed some flexibility regarding timing

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

drott: I consider @supports an upgrade path

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

myles: either one is reasonable to me

lea: which part is blocked on what?

myles: If we want to keep the unimplemented features of the format() in src, we wouldn't need to be blocked on else

<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)

lea: the problem with that is that we don't want microsyntaxes

<TabAtkins> whereas `@support unknown-font-thing() {...} @else {...}` would match one or the other, guaranteed.

lea: Important point from the issue drott raised hasn't be raised yet

lea: else is syntactic sugar for negation

lea: but another way to work around is to use unicode-range

lea: drott mentioned that most font-face rules are generated, and have unicode-range alreay

lea: which means this isn't a problem

myles: unicode-range is an orthogonal feature

<TabAtkins> Oh wait, sorry, I was wrong - @supports doesn't use the unknown value.

myles: if author is trying to use fancy syntax that is / isn't supported

<TabAtkins> We resolved on that a bit ago.

myles: both @font-face rule and fallback will have the same unicode-range

<TabAtkins> Unknown things are just false in @supports.

myles: so the problem still applies

lea: Problem is if the character is not included in the range

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

myles: in that case the browser will download both fonts serially

drott: Should have unicode-range identical to CMAP

<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`.)

<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.

<drott> fantasai: If that's the case, we can ship src: first - ship @supports version later.

lea: There's another unexplored option

lea: what if we had an inline conditional function that does supports queries

lea: A supports() or supports-if() function to put inside any value

astearns: I think it would be a good idea to write down what you're suggesting, Lea

astearns: but getting a proliferation of options, unsure we can get to resolution on anything specific today

astearns: I think we can resolve at least that we would like to work on the if/else syntax

TabAtkins: Adopt as an ED in the WG? Currently draft in my personal repo

<lea> +1 to working on @else proposal

<jfkthame> +1

astearns: resolution would be to adopt, yes

fantasai: so that would be css-conditional-3?

TabAtkins: sure

drott: potentially add any resolution, then idea would be to have a font-tech function to combine with that?

<TabAtkins> I also was udner the impression that Conditional started with 1.

dbaron[m]: I think conditional-3 is already advanced

<drott> +1 to that.

fantasai: oh, I meant whatever's next

<drott> sorry, fantasai, I did not capture what you said.

Resolution: Adopt if/else as next level of css-conditional

astearns: So question of current font-technology draft and reworking them with existence of if/else in mind

astearns: so take back to issue to determine what changes, if any, need to be made

chris: I don't see a dependency there

chris: I think we can adopt PR as-is

<drott> +1 as well

lea: +1

lea: this is something useful immediately

<TabAtkins> +1

<drott> yes

astearns: Adopting PR will resolve the issue?

lea: the bulk of it

astearns: And we can open new more tightly constrianed issues

astearns: So proposed resolution?

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

<drott> https://github.com/drott/csswg-drafts/commit/62cfd95a5f52604c952e4aa37be6e4d6386f88f5

myles: the @else rule should make it clear that it works with this new query inside @supports

myles: either explicitly or implicitly

myles: And i'd ask implementers not to implement font-technology() without @else

myles: because if you oonly give ability to do it wrong, people will do it wrong

lea: they can still do it right, it's just tedious

<dbaron[m]> That request to implementers should be in the spec.

myles: because @else is the solution to this problem, so one depends on the other

<jensimmons> +1 to myles

<drott> fantasai: I am not sure I agree with this particular PR.

<drott> fantasai: I think the function should have identical syntax to what we should have in src:.

<drott> fantasai: one question I have: font-technology - would this be allowed to be queries in src:?

<drott> s/queried/queries

<drott> s/queried/queries/

astearns: I think we should merge it in and take separate issues

chris: I edit both specs anyway

<drott> +1 to that, if we can have the font-technology PR

myles: but if we're making src less flexible than it is to day (in ths spec)

fantasai: happy to do so, as long as we can work on it and not just ship what's in the PR

<chris> @drott I see the PR on your fork repo but not the one on the csswg repo

myles: I think it's OK to resolve this, I think fantasai's idea about making them match makes sense to me

myles: I think making them match gives drott a path to implementing that doesn't rely on us standadizing a big new feature

myles: so I think that's the best path forward

astearns: we're not got to solve everything today

astearns: so let's merge the PR and file more issues

<drott> +1

<lea> +1

<chris> +1

astearns: any objections?

Resolution: Accept the PR

<chris> :)

myles: Can we add a note to the PR to say "don't implement this yet, implement this other thing first"

astearns: open an issue

multicol

<rachelandrew> https://docs.google.com/document/d/1VH00m6Kye7GyagkHFrOLh4MsR9HAj2XN_qqg209IOUE/edit?usp=sharing

rachelandrew: We've been doing a bunch of work from css-multicol-1, took it from CR to WD to work on it

rachelandrew: That's my notes on preparing to take back to CR

rachelandrew: I've had horizontal review from everyone except security, who hasn't responded since 12 May

<TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/6612

rachelandrew: but don't expect any issues

rachelandrew: obviously we have wide implementation of this spec already

rachelandrew: after CR need to sort out test suite

rachelandrew: There's a column which details the larger changes that I don't think have tests yet, but need to check since browser vendors have been doing work

rachelandrew: so would like to get approval to move to CR

+1

<florian> +1

<rachelandrew> will do

astearns: any objections?

Resolution: Transition css-multicol-1 back to CR

^_^/

<jensimmons> yay!! I know it's been a ton of work...

css-background-3

github: https://github.com/w3c/csswg-drafts/issues/6586

<drott> chris: > @drott I see the PR on your fork repo but not the one on the csswg repo I'll turn it into a PR visible on the CSSWG repo.

smfr: Spec allows specifying a corner and an offset from that corner

smfr: spec doesn't specify

smfr: WebKit serializes as inputted

smfr: Gecko serializes calc()

<drott> fantasai: we already did discuss this - that's the way the computed value is the way it is.

<drott> fantasai: you could possibly map the values of varying percentages to keywords.

<drott> fantasai: it's said that it's a length/percentag value per axis. there's no way to distinguish if somebody specified calc() of a value

<drott> fantasai: we had discussed this before: main concern would be: in the future we would have logical keywords

<drott> fantasai: with that, the computed value for background-position would become more complicated

<drott> fantasai: i don't have a strong opinion on it because of what we plan for in the future.

fantasai: spec is clear, in the "computed value" line

<emilio> I agree this falls from the "Computed Value" definition

TabAtkins: Since it confused some people, maybe a note to highlight that this information is lost would be helpful

smfr: I just wanted to follow link to where it's clear...

TabAtkins: as a combination of lengths and percentages, you'd have to use calc()

dbaron[m]: other principle is use most backwards-compatible syntax, and at least in Gecko calc() predated the background-position extended syntax

astearns: Suggest closing issue by adding a note to css-backgrounds-3 and maybe also values and units

smfr: wfm

Resolution: Add a note

astearns: no normative change, but we will explain why

Serialization of empty url()

github: https://github.com/w3c/csswg-drafts/issues/6447

smfr: CSS Values talks about empty URLs and how we avoid normal behavior of resolving against stylesheet URL

smfr: empty treated as involved

smfr: and we introduced "about:invalid" as a URL

smfr: which is what Gecko serializes

smfr: ??? serializes the resolved URL which is wrong

smfr: but I think empty URLs serialize as such

TabAtkins: That was my intention, and I'm happy to adjust spec to make it clearer

smfr: Also do we serialize as url() or url("")

TabAtkins: I think completely empty URL, is that even valid?

fantasai: it is valid, just tested

<drott> fantasai: it is valid, i just tested

TabAtkins: That would be a serialization nobody uses

TabAtkins: so I lean toward url("") because at least one browser is doing that currently

emilio: Who?

TabAtkins: whoever is passing that test

emilio: smfr updated the test to use empty string

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

TabAtkins: nevermind, nobody passes that

smfr: Test expect everything becomes quoted

TabAtkins: let me see if CSSOM specifies anything

TabAtkins: yes, CSSOM expects all URL functions to contain a string

<emilio> https://drafts.csswg.org/cssom/#serialize-a-url

TabAtkins: regardless of whether inputted with or without quotes

<TabAtkins> https://drafts.csswg.org/cssom/#serialize-a-url

TabAtkins: so for consistency, empty url() should also serialize with quotes

astearns: so proposed resolution is to make this test valid, using quoted empty string?

emilio: before we resolve, I wanted to make an argument for url()

emilio: if you consider invalid URL not a URL

emilio: but I'm fine

astearns: If you're fine with the explicitly quoted empty string, I think it makes much more sense, it's consistent

astearns: any objections?

Resolution: 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