- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 26 Mar 2025 19:14:32 -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 Sizing
----------
- RESOLVED: When aspect-ratio is non-initial, then min-size:auto
serializes as 'auto' in gCS() (rather than being censored
to 0) (Issue #11716: Resolved value of min size
properties doesn't round-trip)
CSS Values
----------
- RESOLVED: Accept the proposal for changing random caching as stated
in the issue (Issue #11742: Maybe min, max and step
should not be part of the random-caching-key)
- RESOLVED: Go with element-shared for now, keep renaming issue open
because many people are unhappy with it (Issue #11742)
CSS Display
-----------
- RESOLVED: Initial value of reading-flow is "normal" (Issue #11396:
Initial value of `reading-flow`)
- RESOLVED: Add 'source-order' value applying also to block
containers (Issue #11396)
- RESOLVED: No change to the default behavior for reading-flow and
dense grid for now, because there's no proposal (Issue
#11396)
- The question as to if reading-order should work by default that is
included in issue #11396 will remain open while Apple consults
their accessibility team.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2025Mar/0025.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins-Bittner
Kevin Babbitt
Oriol Brufau
Keith Cirkel
Yehonatan Daniv
Elika Etemad
Robert Flack
Simon Fraser
Paul Grenier
Daniel Holbert
Brian Kardell
Jonathan Kew
Roman Komarov
Vladimir Levin
Alison Maher
Cameron McCormick
Gaurav Singh Faujdar
Alan Stearns
Miriam Suzanne
Josh Tumath
Bramus Van Damme
Sam Weinig
Scribe: TabAtkins
Admin
=====
<astearns> https://github.com/w3c/csswg-drafts/issues?q=state%3Aopen%20label%3A%22Async%20Resolution%3A%20Call%20For%20Consensus%22
astearns: A number of async issues, take a look
astearns: f2f meeting next week, make sure you're in the wiki whether
you're in person or virtually
astearns: lmk what time of day you'll be around virtually, so I can
arrange the agenda to suit
<fantasai> -> https://wiki.csswg.org/planning/newyork-2025
astearns: I'll be working on the agenda this afternoon
astearns: so availability will be useful very soon
astearns: Next is another availability poll for a Summer meeting in
Europe.
<astearns> https://app.rallly.co/invite/3lTXIzw6dXxW
CSS Sizing
==========
Resolved value of min size properties doesn't round-trip
--------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11716
oriol: Summarizing last time...
oriol: min-height and min-width have initial value of 'auto' but for
back-compat gCS() returns 0 on all elements except flex and
grid items
oriol: However, Sizing 4 added a new effect to 'auto', when you're
using aspect-ratio
oriol: so it's not equivalent to zero on those elements
oriol: so my proposal was that if aspect-ratio had a non-initial
value, gCS() would stay as 'auto' rather than becoming 0
oriol: Ian wanted to time to check on stuff, he just said he's okay
with this special-casing, not sure if he means the proposal
TabAtkins: I read his comment as meaning your proposal, yeah
weinig: Is there a known compat concern with just returning auto
always for min size properties?
weinig: do we think it'll actually break sites?
oriol: Not sure
oriol: Possibly the editors that said it originally have an idea. but
changing that seems riskier.
oriol: so not suggesting changing that for now, can do another issue
to investigate
dbaron: I think changing a behavior that's small-integer number of
years old is much less scary than changing a 20yo behavior
weinig: fair enough, just wanted to mention it
fantasai: yeah, because this affects the initial value, which is what
you'll usually get back for it, and for a property that's
20+ years old
fantasai: we didn't do a compat analysis, but we suspected there
would be a problem
astearns: So the proposed resolution is that when aspect-ratio is
non-initial, then min-size:auto serializes as 'auto' in
gCS() (rather than being censored to 0)
dholbert: in both axises, right?
oriol: yes
RESOLVED: When aspect-ratio is non-initial, then min-size:auto
serializes as 'auto' in gCS() (rather than being censored
to 0)
Should `aspect-ratio: <ratio>` obey `box-sizing` on replaced elements
with auto preferred sizes?
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11093
oriol: I closed this issue, I think it's done
CSS Values
==========
scribe: fantasai
scribe's scribe: TabAtkins
Maybe min, max and step should not be part of the random-caching-key
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11742#issuecomment-2707697957
TabAtkins: The random() functions currently, by default, are
maximally random.
TabAtkins: two axes controlling how they resolve
TabAtkins: 1. Which property they're in, and what index in the
declaration
TabAtkins: 2. whether same across all elements or different
TabAtkins: can change either of these
TabAtkins: Force same across properties/instances by applying custom
ident
TabAtkins: or force same across elements by using special keyword
TabAtkins: some opposition from oriol about the way that the element
sharing was phrased
TabAtkins: He preferred previous model where elements shared by
default, and opt out
TabAtkins: Since then several people commented preferring that
starting with maximal randomness is better
TabAtkins: so my proposal is to adopt the proposed model, and then
address naming question
oriol: My concern is that when you provide the keyword, not clear
that you would share across instances but not across elements
oriol: In our other properties with custom elements, you get same
behavior for same custom ident
oriol: I worry it could create some confusion
oriol: But I think if you provide random() with no parameter,
maximizing randomness is better
fantasai: One option is that "no parameters" is maximum randomness,
using a custom ident gives you global correspondence, and
using custom-ident+a keyword gives you shared in an
element, but different across elements
TabAtkins: Yes, that would be a "per-element" keyword, discussed
already
TabAtkins: I don't like that because it breaks independence of
omitted chunks
TabAtkins: omitting all params shouldn't be different from the
behavior of omitting each individually
TabAtkins: We usually adhere to that model, so I prefer to stick to
that model.
TabAtkins: Specifying peels back specific aspect of randomness.
TabAtkins: rather than doing an inversion as soon as you specify
anything
fantasai: I don't mind either way, just saying this is another
possible syntax model.
astearns: So should we resolve on this model of maximal randomness?
RESOLVED: Accept the proposal for changing random caching as stated
in the issue.
TabAtkins: We need to name the share-randomness-across-elements
keyword
TabAtkins: some options were `element-shared` and `all-elements` ...
other suggestions in issue
<fantasai> Proposal is at
https://github.com/w3c/csswg-drafts/issues/11742#issuecomment-2707697957
<fantasai> Suggested keywords
https://github.com/w3c/csswg-drafts/issues/11742#issuecomment-2708387121
astearns: Do we have existing keywords related to this idea?
<bkardell> +1
fantasai: I think I agree with Tim on match-element being confusing,
it doesn't really convey... we're not matching this value
to this element, like it does in VT
fantasai: it's "this function should match across all elements",
different concept
astearns: should we resolve on 'element-shared'?
fantasai: element-shared sounds weird
<bkardell> I think I disagree all elements sounds more obvious
<TabAtkins> straw poll: 1) element-shared, 2) all-elements, 3) both
of these suck, I have a better idea
<TabAtkins> 1
<schenney> 1
<ydaniv> just "shared"?
<astearns> 1
<bkardell> 1
<Kurt> 1
<fantasai> 2, but I wish I could pick 3
<miriam> 2
<alison>maher 1
<bramus> 1
<ydaniv> 1
<oriol> Maybe 3) shared-across-elements? Or 2)
<vmpstr> (abstain)
<kizu 2>
<dbaron> 1 (weakly)
<smfr> more like "global"?
<dbaron> (what about across-elements?)
<fantasai> +1 dbaron
<oriol> Not clear if across-elements is varying across elements or
caching across elements
<kbabbitt> match-across-elements ?
fantasai: match-elements ?
TabAtkins: too close to v-t-n: match-element
ydaniv: by-property?
PROPOSED: Go with element-shared for now, keep renaming issue open
because we're all unhappy with it
<dholbert> (I'm not particularly enthusiastic about either of the
options but I don't have a better suggestion )
<emilio> (same as dholbert)
RESOLVED: Go with element-shared for now, keep renaming issue open
because many people are unhappy with it
CSS Display
===========
Initial value of `reading-flow`
-------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11396#issuecomment-2715874704
TabAtkins: reading-flow changes the order that elements will show up
in a11y tools to better match visual layout
TabAtkins: reading-order applies to children, and explicitly reorders
TabAtkins: This can help opt things out of visual reordering
TabAtkins: After some discussions about what needs to be done here,
we have 4 points
TabAtkins: 1. Initial value should stay as normal.
TabAtkins: 2. Adding a 'source-order' value, which has no effect on
reading-flow normally, but creates reading-flow container
side-effects: allows reading-order, and applies tabindex
scoping
TabAtkins: 3. 'source-order' applies to block containers as well as
flex/grid
astearns: let's pause there
astearns: Any concerns about resolving on initial value of
reading-flow as normal?
RESOLVED: Initial value of reading-flow is "normal".
astearns: proposed to add 'source-order' value that will also apply
to block containers
RESOLVED: Add 'source-order' value applying also to block containers.
TabAtkins: Next batch of questions was about defaults.
TabAtkins: 1. Suggestion that perhaps dense grids could automatically
opt into an appropriate reading-flow value by default
TabAtkins: But suggestion to not do that
TabAtkins: so suggested to resolve not to have an effect on dense
grids
fantasai: We raised this issue because dense grids are a case we
might want to have automatic behavior
fantasai: but also some concerns with that
fantasai: it would apply the tab-index scoping behavior by default,
which might not be expected
fantasai: though that's a bit more of an edge case, since positive
tabindexes are strongly discouraged (due to bad effects)
fantasai: the other aspect is, Tab when you suggested we should apply
one of the visual reordering modes to dense-packed grids by
default, the pushback wasn't about not doing anything, it
was that it would reorder everything in the grid, not just
the auto-placed items
fantasai: so if an author was placing key items and auto-placing
around those, it would be harmful to switch the entire grid
into a naive visual scan of the grid
fantasai: so if we're going to do something by default it needs to
have a lesser effected
fantasai: something that wouldn't break layouts that are using
explicit placement with auto placement
fantasai: so I don't think we necessarily shouldn't do anything for
dense packing, but we shouldn't use one of the existing
values by default
TabAtkins: You're suggesting a new value not discussed as a default.
That's concerning, would like default value to be
well-thought-out
TabAtkins: I suspect problem space, while potentially useful, is
complex.
TabAtkins: naive visual scan is simple to talk about and understand
TabAtkins: More complicated behavior, would want to be much more
deliberate in designing
TabAtkins: So prefer to go with no special behavior
fantasai: That is what this issue was for discussing.
TabAtkins: We want to be shipping this soon, and issue was open since
December
TabAtkins: so we want to close the issue with no change.
TabAtkins: So, Elika, are you objecting to the default behavior for
dense grids being nothing special?
fantasai: I think we should still think about it, but it shouldn't
block shipping
TabAtkins: Unsure about changing later, but if we're sticking with no
special behavior for now it's fine with me
fantasai: sounds like we should just move on then, and leave the
issue open
TabAtkins: We want a resolution for no change.
<TabAtkins> But without prejudice
scribe: dholbert
TabAtkins: This isn't leaving the issue open; I'd like to resolve it,
but without prejudice
astearns: So no change to the spec, are you ok with that fantasai?
fantasai: I think this is an open issue, we shouldn't close it. We
should keep thinking about this
TabAtkins: I'm proposing we resolve on no-change-for-now
fantasai: A resolution of no-change means the wg has decided they
don't want to make a change
TabAtkins: That's not the proposed resolution. I'm suggesting we
close the question, not closing the issue
TabAtkins: Maybe we resolve no-change-for-now- because there's no
proposal. I'm fine with that
PROPOSED: No change for now, because there's no proposal
RESOLVED: No change to the default behavior for reading-flow and
dense grid for now, because there's no proposal
TabAtkins: Last point on this issue:
TabAtkins: whether or not reading-order works by default.
TabAtkins: Per spec right now, reading-order only works on children
of reading-flow containers (those with non-default initial
value)
TabAtkins: Now that we have source-order (which just makes something
a reading-flow container), you can take any flex/grid/
block and turn on reading-flow for it, and the only
effects are tab-index scoping & allowing reading-order to
work on its children
TabAtkins: Apple proposes that we let reading-order work by default
*and* opt the element's parent into being a reading-flow
container
TabAtkins: (presumably w/ source-order value)
TabAtkins: we prefer not doing that
TabAtkins: Objections: 1st from emilio: because you need to know
whether things are a reading-flow container for various
purposes, it's annoying to have that depend on the children
TabAtkins: 2. more important from me personally: because there are
side-effects, and they might be unwanted, I don't like
being a parent being implicitly opted in for something
that might be variable across a page or between pages (if
you have multiple similar containers and only some of them
have a reading-order child)
TabAtkins: or if the child's reading-order gets toggled on/off (and
has side effects on parents)
TabAtkins: I don't think it makes sense for a11y order to be toggled
by this implicit behavior
TabAtkins: Also, the dependence on a parent/child relationship here
is relatively rare in css
TabAtkins: where that happens in CSS, it's extremely tied together -
grid parent/grid-child, etc
TabAtkins: that doesn't feel like the case for reading-order
TabAtkins: I'd prefer having reading-flow be opted in before
reading-order turns on
TabAtkins: It's possible that an author sets one and then never tests
it. The failure case is that the page works the same as it
does today
TabAtkins: the perf and the unpredictability of container creation
make me lean towards no-to-implicit-creation
<emilio> +1
fantasai: We discussed this with our a11y folks and they raised
various questions that we haven't finished digging into
fantasai: and those might invalidate some parts of Tab's argument
fantasai: So I'd object to taking a resolution either way for now
TabAtkins: Any details? This feels analogous to other parent/child
relationships across aria where opting in is important
fantasai: One of the questions is should we even have these [...] Is
this tab-index scoping behavior, on-the-whole, better or
worse than not having that automatic tab-index scoping
behavior
fantasai: if it's worse, then some of the premises of Tab's arguments
are invalid
TabAtkins: I think we adopted the tabindex scoping behavior on the
recommendation of w3c a11y folks, so that part feels like
it should be fine
TabAtkins: I'm ok leaving this open to wait for your feedback
<PaulG> I'll make sure APA knows about it
Rossen: No resolution on this one for now then. we'll await feedback
from fantasai and team
CSS Scroll Anchoring
====================
anchoring within contenteditable elements
-----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11748
vmpstr: [starts describing]
[we realize there's 1 minute remaining, plan when to actually
discuss it]
Received on Wednesday, 26 March 2025 23:15:04 UTC