- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 15 Sep 2021 19:02:01 -0400
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
CSS Nesting & Fonts
-------------------
- RESOLVED: Adopt if/else as next level of css-conditional (Issue
#6520: Nesting @supports inside @font-face / font tech
queries)
- RESOLVED: Accept the PR
https://github.com/drott/csswg-drafts/commit/62cfd95a5f52604c952e4aa37be6e4d6386f88f5
(Issue #6520)
- There are still some open questions and concerns that were
discussed on the call, but they will be raised as separate issues.
CSS Multicol
------------
- RESOLVED: Transition css-multicol-1 back to CR (Issue #6612:
New CR?)
CSS Backgrounds 3
-----------------
- RESOLVED: Add a note [this falls out from the computed value
definition] (Issue #6586: What is the serialization
"background-position: top right 10px"?)
CSS Values 3
------------
- RESOLVED: Serialize as url("") (Issue #6447: Serialization of empty
url() undefined)
===== MEETING MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2021Sep/0005.html
Present:
Rachel Andrew
Tab Atkins-Bittner
Christian Biesinger
Oriol Brufau
Dan Clark
Emilio Cobos Álvarez
Elika Etemad
Simon Fraser
Megan Gardner
Chris Harrelson
Daniel Holbert
Brian Kardell
Brad Kemper
Jonathan Kew
Daniel Libby
Chris Lilley
Ting-Yu Lin
Alison Maher
Morgan Reschenberg
Dominik Röttsches
Jen Simmons
Miriam Suzanne
Lea Verou
Regrets:
Rossen Atanassov
Scribe: fantasai
Scribe's Scribe: drott
CSS Nesting & Fonts
===================
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: I 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
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
fantasai: I think we had previous notes on this, can't find it
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.
fantasai: for @supports, you might want to query not only if it's
color, but you might want to query for format
fantasai: I would simplify the syntax of the font-technology function.
fantasai: In a way to remove the sub functions, and just have a list
of keywords, for example font-format-...
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
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 simpler supports
queries in @font-face rules
astearns: and remove fallback ability
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
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
<chris> this is its issue: https://github.com/w3c/csswg-drafts/issues/112
drott: I discussed this issue with jfkthame offline. I think he's
here?
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
flexibility 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
lea: the problem with that is that we don't want microsyntaxes
<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)
<TabAtkins> whereas `@support unknown-font-thing() {...} @else {...}`
would match one or the other, guaranteed.
<TabAtkins> Oh wait, sorry, I was wrong - @supports doesn't use the
unknown value.
<TabAtkins> We resolved on that a bit ago.
<TabAtkins> Unknown things are just false in @supports.
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 already
lea: which means this isn't a problem
myles: unicode-range is an orthogonal feature
myles: If author is trying to use fancy syntax that is / isn't
supported
myles: both @font-face rule and fallback will have the same
unicode-range
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`.)
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.
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 under the impression that Conditional started
with 1.
dbaron: I think conditional-3 is already advanced
fantasai: oh, I meant whatever's next
<drott> +1 to that.
RESOLVED: 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
astearns: Adopting PR will resolve the issue?
<drott> yes
lea: the bulk of it
astearns: And we can open new more tightly constrained 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 only give ability to do it wrong, people will
do it wrong
<dbaron> That request to implementers should be in the
spec .
lea: They can still do it right, it's just tedious
myles: Because @else is the solution to this problem, so one depends
on the other
<jensimmons> +1 to myles
fantasai: I am not sure I agree with this particular PR.
fantasai: I think the function should have identical syntax to what
we should have in src:.
fantasai: One question I have: font-technology - would this be
allowed to be queried in src:?
astearns: I think we should merge it in and take separate issues
chris: I edit both specs anyway
myles: But if we're making src less flexible than it is to day (in
the spec)
<drott> +1 to that, if we can have the font-technology PR
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 standardizing a big new feature
myles: so I think that's the best path forward
astearns: We've 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?
RESOLVED: 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
========
New CR?
-------
github: https://github.com/w3c/csswg-drafts/issues/6612
<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
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
<fantasai> +1
<florian> +
astearns: Any objections?
RESOLVED: Transition css-multicol-1 back to CR
<fantasai> \^_^/
<jensimmons> yay!! I know it's been a ton of work...
Backgrounds 3
=============
What is the serialization "background-position: top right 10px"?
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6586
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()
fantasai: We already did discuss this - that's the way the computed
value is the way it is.
fantasai: You could possibly map the values of varying percentages to
keywords.
fantasai: It's said that it's a length/percentage value per axis.
There's no way to distinguish if somebody specified calc()
of a value
fantasai: We had discussed this before: main concern would be: in the
future we would have logical keywords
fantasai: With that, the computed value for background-position would
become more complicated
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: 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: Works for me
RESOLVED: Add a note
astearns: no normative change, but we will explain why
CSS Values 3
============
Serialization of empty url() undefined
--------------------------------------
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
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: 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?
RESOLVED: Serialize as url("")
Received on Wednesday, 15 September 2021 23:08:16 UTC