- From: Dael Jackson <[email protected]>
- Date: Wed, 13 Nov 2024 19:49:12 -0500
- To: [email protected]
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
Publications
------------
- RESOLVED: Publish new WD of View Transitions 2
- RESOLVED: Republish Pseudo 4, move glazman to former editor
- RESOLVED: Publish new WD of Nesting
CSS Snapshot
------------
- RESOLVED: Add new category, shorthanded as "reliable CR" (Issue
#9770: Add specs to Official Definition)
- RESOLVED: Add MQ4 and Scroll Snap to "reliable CR" (Issue #9770)
- RESOLVED: Move Grid 1 and 2 to "reliable CR" (Issue #9770)
- Spec editors are asked to post their opinions of where those specs
should be placed in the snapshot so that the group can do a bulk
set of resolutions in the near future.
CSS Values
----------
- RESOLVED: Accept proposal to use type(<syntax>), add string, and
add units as keywords (Issue #11035: attr() and forwards
compatible parsing)
CSS Shapes
----------
- RESOLVED: Accept the changes to the shape() grammar (Issue #10649:
`curve to` keyword `using` seems a bit off)
CSS Backgrounds
---------------
- RESOLVED: Using 'border-area' in the background shorthand (and
omitting origin) defaults the origin to border-box (Issue
#11167: Default background-origin for `border-area` in
shorthand)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2024Nov/0007.html
Present:
Rossen Atanassov
Tab Atkins-Bittner
Kevin Babbitt
Oriol Brufau
Stephen Chenney
Emilio Cobos Álvarez
Yehonatan Daniv
Stephanie Eckles
Elika Etemad
Robert Flack
Simon Fraser
Paul Grenier
Jonathan Kew
Daniel Holbert
Roman Komarov
Chris Lilley
Alison Maher
Romain Menke
Cassondra Roberts
Noam Rosenthal
Gaurav Singh Faujdar
Miriam Suzanne
Josh Tumath
Munira Tursunova
Lea Verou
Sebastian Zartner
Regrets:
Rachel Andrew
Scribe: TabAtkins
Administrative
==============
F2F Scheduling
--------------
<fantasai> -> https://app.rallly.co/invite/ShjWRuGtqnQG
Rossen: Reminder about the poll for the Winter f2f
fantasai: I think we should be able to close the poll next Wednesday,
we have a lot of answers
fantasai: Leading candidates are feb 6 and march 13 weeks
<fantasai> ... and feb 20th
Publication Requests
--------------------
github: https://github.com/w3c/csswg-drafts/issues/6900#issuecomment-2461115768
ChrisL: Bot takes off agenda+ when we discuss one, so we'd missed
a few
Rossen: First is View Transitions 2, new WD
<fantasai> https://drafts.csswg.org/css-view-transitions-2/#changes
fantasai: I think for a bunch of these, there's been enough changes
to make sure everyone's on board
<Rossen> https://github.com/w3c/csswg-drafts/commits/main/css-view-transitions-2/Overview.bs
Rossen: here's the change log
<fantasai> -> https://drafts.csswg.org/css-view-transitions-2/#changes
<ChrisL> +1
<fantasai> +1 to publishing
<TabAtkins> +1 to publish
RESOLVED: Publish new WD of View Transitions 2
Rossen: Next is Pseudo 4
<fantasai> -> https://drafts.csswg.org/css-pseudo-4/#changes
ChrisL: dglazman is listed as an editor and he's no longer in the WG
Rossen: Think we should just move him to former editor as we repub
fantasai: Change log isn't as long as it looks
fantasai: 8 items
fantasai: Changes are defining "element-backed" and "fully-stylable"
pseudo-elements
fantasai: A bunch of reworking of what properties apply to highlight
pseudos and how they cascade/inherit
fantasai: added search-text and details-content
szager: I think I had some open PRs...
fantasai: I believe I merged them
fantasai: I'll handle publication
Rossen: Objections to republishing?
RESOLVED: Republish Pseudo 4, move glazman to former editor
<schenney> Big thanks for this one.
Rossen: Nesting - link to changes in IRC
<ChrisL> https://drafts.csswg.org/css-nesting/#changes
[discussion on the last two bullet points of changes list being
confusing, since they affect each other]
Rossen: Objections to publishing?
<fantasai> [should merge them so that the changes list reflects diff
against last WD]
RESOLVED: Publish new WD of Nesting
CSS Snapshot
============
Add specs to Official Definition
--------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9770
Approach
++++++++
fantasai: High-level comment. Reason for the snapshot was because the
status of our specs didn't always reflect the actual
stability
fantasai: We'd have a WD that's basically a Rec, etc
fantasai: Was confusing, people didn't know stability
fantasai: What we ended up with in the snapshot is 3 lists, I think
I'm gonna propose 4 lists
fantasai: We've got "official definition", that's the list of "these
are (basically) Recs". some actually Recs, others are same
stability level, just waiting on some bugfixes or minor
issues
fantasai: usually blocker is missing an impl report
fantasai: Then we have two lists, one is "these are pretty stable,
maybe not enough impl experience, but not really changing"
fantasai: and "spec is a mess but impls are shipping and roughly
interoperable"
fantasai: Poster child is Transitions & Animations
fantasai: tons of issues, but people were shipping and they were
widely used
fantasai: So we have Rec-level, CR-level with limited implementation,
and CR-level implementation with limited spec
fantasai: Might want a fourth list of "spec is pretty stable, largely
implemented, largely reliable for use"
fantasai: probably a lot of our specs should be there
fantasai: So I propose we add this new list as the second list (in
order) in the snapshot
florian: Although it's more things, I do think it's simpler overall.
Too many things that don't fit well in any of our three
categories
<dbaron> does this mean there are now 2 axes rather than 1?
ChrisL: I think it makes sense to go through what Sebastian has done,
then go through the new category. Would rather see that in an
ED and then we can move around
florian: I might be opposed to some of the moves, because it's the
wrong place; the right place will be the new category
fantasai: Yeah that's why I brought it up too
dbaron: Does this new category mean we're classifying on 2 rather
than 1 axis? if so, what?
fantasai: We've always been categorizing, just missing this quadrant
fantasai: How stable is spec, how stable is impl
florian: We had "both great", "impl good, spec bad", and "spec good,
impl not". didn't have "both good (but not done)"
fantasai: Rough interop was "we have interop but spec doesn't reflect
that"
fantasai: we just need one where we have interop and spec does
roughly match
dbaron: So we had a category for "impl 1, spec 1", "impl 1, spec 0",
and "impl 0, spec 1". this new one is "impl 1/2, spec 1/2"
fantasai: Roughly, yeah. (quibble on the exact numbers, but idea is
right)
<fantasai> 4 categories: REC-like, reliable spec + implementation,
low-experience CR, shipping + badly specced
<fantasai> A) REC-like; B) reliable spec + implementations; C)
low-experience CR; D) shipping + badly specced
Media Queries 4
+++++++++++++++
Rossen: So it fits the model. My proposal is we go through the list
of specs we have currently here.
SebastianZ: first is MQ4, current is CRD, last published 2021
SebastianZ: lots of tests for this spec, interop is very good
SebastianZ: 98%
SebastianZ: but still some open gh issues
florian: I suspect it's really good in terms of syntax, but MQs are
notably hard to test
florian: I suspect there are still quite a few media features that
are good ideas but not particularly tested or implemented
florian: I'm unsure, for example, of overflow-block/inline, unsure
about how close reality is for the hover/pointer ones
SebastianZ: We'd need to check on that, I was just collecting data
around open issues and tests
SebastianZ: didn't check every feature in those specs
florian: I know for a long time we were lacking impl and coverage for
some features. we might have improved, just not sure where
we are now.
ChrisL: I noticed mq4 doesn't have wpt annotations, that would have
helped
florian: For MQ syntax we should have this, no question. but many
media features are basically not testable in an automatic
manner
florian: so not just lacking annotation, lacking *tests*
florian: It's "run this on a device with these characteristics, and
see if it works"
dbaron: In theory we might eventually want to show that there *is*
some impl or device that does each value
florian: I know we weren't there for a long time, might have gotten
there while I wasn't looking
florian: Also I'm listed as a co-editor, and I don't dislike that,
but I'm no longer sponsored for it
florian: I just suspect that until we can properly audit, we can't
move it.
florian: suspect it's good but can't show it
fantasai: We *could* move it into the new category, reliable spec +
impls
florian: Maybe. parts of it at least
fantasai: I'm fine either way
SebastianZ: two options, one is to defer it, and add wpt tests so we
can see what's covered and what still needs coverage
SebastianZ: other is to add it to the new list
SebastianZ: no strong opinion
Rossen: Just saying that having 98% interop on what's already tests
is great
fantasai: But if it's just testing parsing that's not much
Rossen: If there are missing tests, that's on us
Rossen: If I'm being a neutral observer, it seems like a spec that's
moving along well
Rossen: Whatever's put in a test case impls are doing, that's great
florian: I don't know if that's useful, the tests aren't a bar *we*
set, they're mostly written by the impls
florian: Passing a lot of tests without evaluating coverage, I don't
know if it's saying anything useful
florian: Recently we almost pushed Scrollbars to rec, everyone had
super high test rates despite Safari not implementing it *at
all*
Rossen: I get that, but if you're an editor and not seeing enough
coverage, we can say that and outline what parts aren't
covered
florian: For MQ4 I'm saying this was the case a few years ago, last I
checked. If somebody fixed it more recently I dunno.
Rossen: So I'm looking at Sebastian as someone who's looked at this
more recently
SebastianZ: I didn't check all the features, I checked a few in each
spec
SebastianZ: That's why I put it on the list to add it to the official
definition
fantasai: I think unless we have some evidence that the behavior is
implemented correctly (not just parsing and OM), we can't
reasonably put it in rec-like section
florian: I just checked - some features that didn't have tests before
still don't
Rossen: So are we moving at all? or leaving it?
florian: We could move it to the new bucket, it has some sections
that are stable but some that aren't. So either leave it or
put it in the new bucket
Rossen: So here's an example of a spec which'll have the new bucket
SebastianZ: Let's still continue on this one
Scroll Snap
+++++++++++
fantasai: Next is Scroll Snap, I think this is meaningfully
implemented everywhere. Not 100% interop, and some minor
issues.
fantasai: I'd say this should move either into the "reliable CR"
section, and probably next year if we resolve the remaining
issues we can put it in "reliable Rec" section
Rossen: So scroll snap should move to "reliable CR" new bucket?
Approach
++++++++
Rossen: We have two candidates already, let's just resolve on the new
bucket
ChrisL: Let's
Rossen: Anyone objecting to adding this new bucket?
fantasai: I'll call it "reliable CR" as shorthand, work on wording
later
<fantasai> A) REC-like; B) reliable spec + implementations; C)
low-experience CR; D) shipping + badly specced
SebastianZ: No objection, just wondering if some specs in A would fit
into B instead
Rossen: We can see what goes in it once we have it
RESOLVED: Add new category, shorthanded as "reliable CR"
Rossen: With that, we'll add MQ4 and Scroll Snap to "reliable CR".
objections?
RESOLVED: Add MQ4 and Scroll Snap to "reliable CR"
Scrollbars 1
++++++++++++
florian: I'd argue Scrollbars 1 goes in "reliable CR" too. Very small
spec.
florian: Like I mentioned, Safari has great pass rates but they're
going down as tests are reviewed and made to actually fail
when not supported
ChrisL: So we don't know how well it's implemented?
florian: There are impls, and the key aspects do work in chrome and
firefox
florian: Details are little more iffy, many have been recently fixed.
test suit needs a little work
florian: Better than a CR with no impl, but not Rec. We could leave
it where it is if we're not sure.
fantasai: Seems to have a usable level of interop
florian: There are corner cases, but the core of it works in two
browsers
Rossen: Any objections to moving it?
RESOLVED: Move Scrollbars to "reliable CR"
CSS Grid 1 & 2
++++++++++++++
fantasai: Grid 1 and 2 should also move to "reliable CR"
<TabAtkins> Agreed
fantasai: Spec needs an update, that's on me. after that it's very
stable, we have very few issues against Grid.
Rossen: I think that sounds reasonable. Objections?
SebastianZ: Just wondering, we have 12k tests on this spec, 92%
interop
SebastianZ: Don't you think that verifies it to go official?
fantasai: I'll propose doing that as soon as I publish an update,
spec is out of date now. If I get that before end of year
we can move it
Rossen: Objections?
RESOLVED: Move Grid 1 and 2 to "reliable CR"
Rossen: Are there more to discuss before we move on?
florian: a bunch
fantasai: we should triage and come back with a batch resolution
SebastianZ: I'd like the editors of the specs to post their opinions
CSS Values 5
============
scribe: fantasai
attr() and forwards compatible parsing
--------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11035#issuecomment-2471871211
TabAtkins: We switched attr() to use type definition syntax, similar
to variables
TabAtkins: But working through that, we lost some abilities
TabAtkins: for example, saying the attr is a number representing px
values
TabAtkins: It started to get too complicated for common cases
TabAtkins: For grammar ambiguity reasons, we suggest to wrap in
type() function
TabAtkins: and end up with a lot for simple cases.
TabAtkins: Suggestion is to keep the <syntax> argument, but wrapped
in type()
TabAtkins: but for two cases we have an easier way to specify
TabAtkins: for default behavior of treating attr value as a string,
we introduce a keyword (string) so you can say so
explicitly
TabAtkins: and secondly, add all units as keywords, which parse as a
number and attach that unit
TabAtkins: this does slightly reduce the power of the syntax compared
to before, since can't mix this behavior with other values
TabAtkins: but I think it's OK, not a high-value use case right now;
can evaluate later or add to <syntax> production
TabAtkins: but instead of type(<number px>) can just write px, much
simpler
TabAtkins: so proposal is
<TabAtkins> 1. Add type() wrapper around <syntax>
<TabAtkins> 2. Introduce string keyword for explicitly indicating
string parsing
<TabAtkins> 3. Add all units to attach to a <number>
<kizu> +1 to the proposal
<lea> I don't understand the proposed options
<TabAtkins> attr(foo type(<length>))
<TabAtkins> attr(foo string) (deffault behavior)
<TabAtkins> attr(attributename [ type(<syntax>) | string | <unit> ],
fallback)
<TabAtkins> attr(foo type(*))
lea: Can you parse in a token stream?
TabAtkins: Yes, use * just like in custom properties
<ydaniv> +1
lea: What's without the proposal?
<TabAtkins> attr(attributename <syntax>, fallback)
TabAtkins: Wanted to wrap type() because <syntax> would make parsing
complicated if we add anything in the future
<florian> wfm
lea: Could we use keyword instead of type()?
TabAtkins: Using type() because that's what we do in custom functions
TabAtkins: Thought about using 'as' but consistency is good
lea: No way to use 'as' in functions? presumably want to know where
the syntax terminates
TabAtkins: Yes, and in some cases if you want to accept several
keywords...
TabAtkins: Having type() wrapper makes it clearer
<lea> +1
<TabAtkins> attr(foo type(one | two | three))
<oriol> +1
<fantasai> wfm
Rossen: Anyone else? Any objections?
RESOLVED: Accept proposal to use type(<syntax>), add string, and add
units as keywords.
CSS Shapes
==========
scribe: TabAtkins
`curve to` keyword `using` seems a bit off
------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10649#issuecomment-2426552611
<fantasai> Summary at
https://github.com/w3c/csswg-drafts/issues/10649#issuecomment-2471826022
smfr: Proposed syntax for the shape() function
smfr: We've talked about this before, it's a tweak
smfr: Settled on using `with` for the control points. If you specify
two control points, separate with a slash.
smfr: Big addition is using keywords for absolute points, like `curve
to top left`, it feels very natural
smfr: hline/vline also take those keywords
smfr: and new addition, can specify the control points are relative
to the start or end of segment, using "from start" or "from
end" syntax
smfr: Had an open question - arbitrary order of control points and
destination points?
smfr: so you could say `curve ... with ... to...` or `curve ... to
... with ...`
<fantasai> full proposed grammar at
https://github.com/w3c/csswg-drafts/issues/10649#issuecomment-2426552611
Rossen: This feels a lot better than the basic shapes syntax before
<fantasai> +1 to the proposal and +1 to allowing reordering
<TabAtkins> +1 to me, I've reviewed all the changes
<noamr> +1
smfr: There's a chunk of wpt already. spec doesn't reflect arbitrary
ordering yet, I'll fix that
Rossen: Objections?
RESOLVED: Accept the changes to the shape() grammar
CSS Backgrounds
===============
Default background-origin for `border-area` in shorthand
--------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11167
fantasai: In the bg shorthand if you specify a single keyword like
'border-box', it sets both clip and origin to that keyword
fantasai: but 'border-area' keyword is only valid for clip, not origin
fantasai: want to clarify that in that case, origin defaults to
border-box
<TabAtkins> +1 to this from me
<kizu> +1, makes sense
<oriol> +1
Rossen: objections?
<fantasai> background: ... border-area;
<emilio> A bit unfortunate that it's different from background: ...;
background-clip: border-area
<emilio> But yeah
RESOLVED: Using 'border-area' in the background shorthand (and
omitting origin) defaults the origin to border-box
fantasai: Second, do we want some way to make things default if you
specify the longhand?
fantasai: Argument for, it's unfortunate/confusing to get it set to
the "wrong" value
fantasai: argument against, it's not something we're currently doing
<fantasai> for other values of background-clip (though maybe we
should have)
Rossen: Okay, will leave that part of the discussion
Received on Thursday, 14 November 2024 00:49:44 UTC