- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 20 Feb 2025 18:38:07 -0500
- 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 Snapshot 2024
-----------------
- RESOLVED: Publish Snapshot 2024 from the current draft, as a Group
Note (Issue #11696: Finish up CSS Snapshot 2024)
CSS Rhythm
----------
- RESOLVED: block-step-size inherits, and does not activate step
sizing (Issue #1902: Inherit block-step-size)
- RESOLVED: Add a new "none" initial value to block-step-align; all
other values turn on step sizing (Issue #1902)
CSS Overflow
------------
- RESOLVED: Try option 2 [use the scrollIntoView() position of the
non-skipped ancestor of the marker for determining when
the marker is active] (Issue #11705: Should
::scroll-marker pseudo-elements within skipped
content-visibility: auto elements be discovered?)
CSS Values
----------
- RESOLVED: Specify this new parsing behavior for all substitution
functions, and some sort of spread-like thing (Issue
#11500: Short-circuit if() evaluation)
CSS Display
-----------
- There wasn't time to discuss all the questions in issue #11208
(reading-flow and mix of auto-flow and explicit items). The group
leaned toward having the ability to set a property which says
reading-flow:<stick-with-source-order> to answer the first
question.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2025Feb/0011.html
Present:
Adam Argyle
Tab Atkins-Bittner
Kevin Babbitt
Oriol Brufau
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Chris Harrelson
Anders Hartvoll Ruud
Brian Kardell
Brad Kemper
Jonathan Kew
Ian Kilpatrick
Roman Komarov
Vladimir Levin
Alison Maher
Eric Meyer
Jen Simmons
Gaurav Singh Faujdar
Alan Stearns
Miriam Suzanne
Bramus Van Damme
Sebastian Zartner
Regrets:
Rachel Andrew
Daniel Holbert
Noam Rosenthal
Josh Tumath
Lea Verou
Scribe: TabAtkins
Scribe's scribe: emilio
CSS Snapshot 2024
=================
Finish up CSS Snapshot 2024
---------------------------
github: https://github.com/w3c/csswg-drafts/issues/11696
SebastianZ: Trying to get a resolution to finish up snapshot 2024
SebastianZ: so we can publish it as a Group Note
SebastianZ: We're quite late this time
SebastianZ: Don't expect to add any changes anymore, I'll try to get
those changes into this year's snapshot
astearns: So proposed is to publish Snapshot 2024 from the draft
as-is, then continue working on 2025
SebastianZ: Yes
astearns: Concerns, question?
fantasai: Sounds reasonable, and if we realize we need to adjust
something in 2024 we can repub it
fantasai: That's why they have different shortnames, they can be fixed
astearns: objections?
RESOLVED: Publish Snapshot 2024 from the current draft, as a Group
Note
CSS Rhythm
==========
Inherit block-step-size
-----------------------
github: https://github.com/w3c/csswg-drafts/issues/1902
jensimmons: We talked about this not long ago.
jensimmons: We were debating if there should be one mechanism to set
the *size* of the block step, and another to actually
apply it or not
jensimmons: Previously we decided to keep it simple and together,
like line-height and margin you just say the one value
and it gives the size and turns on the feature
jensimmons: but thinking through how block-step-size works, we
realized that often an author will want to set
block-step-size to 1lh
jensimmons: If they set 1lh on the article, then what 1lh means is
gonna be different on each element
jensimmons: If you have a headline with one font size and one line
height, it'll be based on the headline lh size; same on a
paragraph is based on the paragraph lh
jensimmons: so you actually get different sizes
jensimmons: because the size isn't set in one spot and inherits, it's
set explicitly on each element
jensimmons: So it sounds like we do need block-step-size to inherit
so it can pick up one measurement, then turn it on/off
with a different property
astearns: So the proposal is block-step-align?
<TabAtkins> +1 from me
jensimmons: Yeah, Elika described it as block-step-size inherits and
sets the length, but has no other effect. Then
block-step-align doesn't inherit, and turns alignment
on/off.
jensimmons: Before block-step-align was like the alignment
properties, where to put the content within the
block-step range
jensimmons: so idea here is that we'd add "none" to block-step-align
as its initial value, and they'd change it from none to
auto/etc to actually trigger
<florian> makes sense to me
astearns: Do we really want the initial value to be none?
astearns: could it be 'auto' and if you don't want it to have an
effect, you change it to none?
fantasai: You don't want block-step to be on every descendant in
a tree
fantasai: you want it on specific element
TabAtkins: Agree. You want it on particular containers, not
necessarily their children.
jensimmons: You might set it on an article, and apply to all the
children, but not further down the tree
jensimmons: otherwise it's weird. you want it on the figure, but not
necessarily the figcaption
astearns: Okay. any other questions or concerns?
astearns: So first resolution is block-step-size inherits and does
not activate step sizing
astearns: Objections?
<TabAtkins> +1
RESOLVED: block-step-size inherits, and does not activate step sizing
astearns: Second resolution is to add a new "none" initial value to
block-step-align; all other values turn on step sizing
RESOLVED: add a new "none" initial value to block-step-align; all
other values turn on step sizing
CSS Overflow
============
Should ::scroll-marker pseudo-elements within skipped
content-visibility: auto elements be discovered?
-----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11705
flackr: It's common practice now to have content-visibility:auto on
your list items for long lists, so we skip painting for
offscreen
flackr: but if you have content in there that produces a scroll
marker, as you scroll you'll be adding/removing markers from
scroll-marker-group
flackr: Probably not what authors intend. So I'm proposing we find a
way to make this work.
flackr: 1) make it similar to find-in-page, we don't skip the
subtrees for finding scroll markers
flackr: 2) use the scrollIntoView() position of the non-skipped
ancestor of the marker for determining when the marker is
active, this lets us still skip layout
flackr: Finally, spec says put a bunch of containment on skipped
elements. Scroll markers are a bit of an exception - need to
specify they paint even if they're in a paint containment
flackr: Could just say they're contained and that's that, but I think
author expects it
TabAtkins: I agree about trying to work it out
TabAtkins: from author perspective the scroll marker is no longer "in
the subtree"
TabAtkins: having containment applied to it would be confusing
flackr: yeah, that would be the last point in my carveout
flackr: so you agree with me?
TabAtkins: yes
emilio: I'm a bit wary of introducing this kind of exceptions...
emilio: could make same argument about fixpos children. I think those
don't escape
emilio: I'm not opposed to try and make this work, I agree it would
be nice, I'm just wary of the implications
emilio: they tend to bite us back
astearns: That was my concern too. Is there anything else we'd need
to apply this to? Seems a little strange to have this
carveout just for scroll marker.
flackr: I think dialogs are similar
TabAtkins: That gets puts in the top layer, it escapes
TabAtkins: for those things, it's box-tree rewriting
TabAtkins: we do it not very often but when we do it does escape
TabAtkins: fixedpos is different
TabAtkins: because those don't escape in the layout tree
TabAtkins: also if you're a fixed pos you can move them around
without rendering effect
TabAtkins: same is not true of scroll markers
TabAtkins: so I'm ok w/ fixed-pos getting contained but
scroll-markers not being contained
andruud: Does this mean that style skipping for c-v is just defeated
for scrollable elements?
flackr: For scrollable containers that have an active
scroll-marker-group
andruud: So you'd know it on the scroller
flackr: Yes. We'd still be able to skip style in the normal case
andruud: Are you worried that style and layout are now linked a bit
through CQs and anchorpos?
andruud: You can't really know the style until you do layout if
there's a CQ
flackr: Yeah, in those cases I suppose we'd be requiring the layout
flackr: but it is contained to things in that scrolling container
emilio: Though arguably, setting this on the root is kinda a use-case
emilio: I think fixpos do get reparented in a way, we just say
contain:layout establishes a CB for them
TabAtkins: Yeah, a lot of things establish a CB for fixpos, they're
easily interrupted
emilio: I suppose this adds another weird case where we do styling
but don't fire transition events, etc
emilio: I do agree it would be nice to work, but will have a bunch of
side effects that might not be aware of right now
emilio: Don't want to object to trying to figure this out. Just think
there's gonna be quirky edge cases and side effects
astearns: So not hearing great enthusiasm, but not hearing objections
astearns: Supposed proposed resolution would be to take option 2, and
attempt to come up with a spec?
flackr: Yes, that's what I'm looking for. try to do it, see how it
works out.
astearns: Any objections to attempting option 2?
RESOLVED: Try option 2
flackr: And if it doesn't work out, we have option 1 which is easy to
explain. option 2 is just nice for authors.
astearns: Right, worth trying
CSS Values
==========
scribe: emilio
scribe's scribe: TabAtkins
Short-circuit if() evaluation
-----------------------------
github: https://github.com/w3c/csswg-drafts/issues/11500
TabAtkins: So... problem that showed up when we started thinking
about if() but it applies to other substitutions
TabAtkins: in most programming languages, the not taken branch isn't
ran
TabAtkins: and has no effect and gets ignored
TabAtkins: as currently spec'd that's not true for if()
TabAtkins: it's expected to fully resolve and then choose
TabAtkins: it's not great
TabAtkins: invalid variables, expensive things like custom functions
TabAtkins: having to run all of the branches to throw all but one of
them seems bad
TabAtkins: so we'd like to find a way to allow deferred evaluation
TabAtkins: so that it also applies to fallbacks and so on
TabAtkins: the proposal is to change how substitutions are parsed
TabAtkins: two grammars, early and late
TabAtkins: early grammar is super wide (<decl>)
TabAtkins: and punctuation to separate the structure
TabAtkins: so in if() you'd get : and ; to separate values
TabAtkins: that's what the initial parse uses
TabAtkins: not evaluating or applying any grammar to it
TabAtkins: then each function defines how it's executed with it's
late grammar
TabAtkins: so if it's true it resolves the condition and the if
body etc
TabAtkins: same would apply to other functions
TabAtkins: so attr() we could avoid evaluating the fallback
TabAtkins: I'd like to apply this universally
TabAtkins: maybe var() needs to unconditionally evaluate
TabAtkins: so might be compat fallout
TabAtkins: but for new functions I'd like to specify in this way
TabAtkins: so the gross structure is in the early parse and the
function controls how it's parsed
TabAtkins: that means vars can no longer supply the punctuation, e.g.
a custom function would not be able to expand into
arguments
TabAtkins: so we'd add syntax like the ... so that we expand it
during early parse
TabAtkins: by default variables would not resolve until requested
TabAtkins: so if you have a function like --foo(var(--var-1),
var(--var-2))
TabAtkins: you know there are two args
TabAtkins: specially for custom functions there are two arguments if
there are commas
TabAtkins: authors need to deffensively wrap in {}
TabAtkins: no longer the case now, authors can depend on a var that's
1 argument being 1 argument
TabAtkins: this actually solves a footgun that we were somewhat
worried about about comma-containing args
TabAtkins: most of the time shouldn't have an effect
TabAtkins: the implications are meaningful tho
TabAtkins: wanted to make sure that it makes sense to other folks
emilio: I guess that means cycles are discovered dynamically?
emilio: can get a bit weird
TabAtkins: Correct
emilio: Worried about things that can create a cycle on an else
branch, and theoretically could effect the condition
emilio: haven't thought too deep about it, but seems sketchy
emilio: other than that, think it makes sense
emilio: var() sub tends to get annoying, the more features we add the
slower it gets, nice to save some work
emilio: but I'm a bit wary about cycle detection
emilio: Are we supposed to check the variable names inside beforehand?
TabAtkins: yea, cycle detection becomes dynamic
TabAtkins: you don't do any checking
TabAtkins: this allows variable-variables
TabAtkins: because that'd be possible now
TabAtkins: for the more general thing of the dynamic cyclic graph
andruud: That's kinda the point of this, not sure what you're worried
about right now emilio
TabAtkins: I suspect he means "say the test for a branch uses a
variable and the body produces a cycle for the test you're
evaluating"
andruud: But that's the branch you take right?
TabAtkins: Right but it only becomes cyclic once you evaluate the
branch right?
andruud: You have that problem with if with the existing model don't
you
TabAtkins: Yeah they're all eagerly evaluated so you know cycles
before-hand
andruud: We solved the example you had for if
andruud: having a custom prop in an if counts for cycle detection
TabAtkins: Right that's the usage emilio is worried about
TabAtkins: the first usage "should've been cyclic"
TabAtkins: but the execution order gets you a defined behavior
emilio: Does that mean the order you perform prop substitution needs
to be well-defined?
emilio: right now if you have two rules that match with the same
var, ... I guess my question is when. the behavior is
different if you sub the first if() first, on whether this
makes a cycle or not
emilio: I suppose that means the whole thing is stateful on the set
of matched declarations
emilio: and we need to define really well whether we sub properties
that are overwritten or not, which currently we skip...
emilio: I think there's a way to make this work, details are just
confusing
emilio: but I think figuring out the spec is part of this issue,
don't need to solve on the call
astearns: Wanted to ask whether the state parsing is separated from
the spread function
TabAtkins: If you stick with current parsing there's no reason to do
spread
TabAtkins: so would be a no-op of a feature
astearns: Wondering whether variables with punctuation is something
we absolutely need to support or not
TabAtkins: Not about vars containing punctuation
astearns: I thought motivation for spread was getting punctuation for
what needs to go in which part of the parsing
kizu: +1 to almost everything
kizu: would be great to have this algorithm, wanted to use var(var(
for a long time
<TabAtkins> var(var(--propname))
<bramus> +1
kizu: only concern is if we are able to make the fallback not
executed I'm totally fine for if()
kizu: for current var() I think there would be many compat issues
kizu: but I think it's possible to use this behavior as a conditional
kizu: that could be a workaround for the conditions in general
kizu: meaning that this behavior could be use as a transpilation
target for if()
kizu: until we have if this could be used for that
kizu: that's the only case where I'd be a bit hesitant
kizu: It'd be nice to see if there are compat issues aside from my
experiments
emilio: I think Alan was asking about whether we can work on spread
after changing the parsing stuff
emilio: that seems possible unless we really... as long as we keep
doing the same thing for var()
emilio: I think it would be nice to have this work for var()
emilio: I think the place I've meaningfully seen commas be used is
things like colors
emilio: you can do `--foo: 1, 2, 3; color: rgb(var(--foo))`
TabAtkins: Right, this would only change behavior for custom
functions / var() / etc and other functions
TabAtkins: a bullet that I'm willing to bite
emilio: I agree, and think it takes most of the compat issues with
var() away
emilio: that gives me some hope that we can make var() work
TabAtkins: The compat issue here is if they are relying on
non-substituted fallback triggering cyclic-ness
TabAtkins: I suspect outside of experiments like kizu's it's not an
issue in practice
astearns: I'm a bit concerned about some library depending on kizu's
hacks and avoids defeating this
TabAtkins: andruud is working on this actively
TabAtkins: so we'd find out about such things soon
andruud: var() we need a use counter for first
andruud: so I'd do that separately (soon)
andruud: and we can resolve on doing it compat-permitting
kizu: I wonder if there'd be no other compat issues I could see
making this change for var() be tied to if() so that we can do
at the same time
kizu: so you can also implement this along @supports ... if()
TabAtkins: if anything if() would show up earlier than var()
kizu: seems fine then
kizu: other browsers can do if-first or at the same time as well
astearns: So proposal is to specify this for all substitution
functions and also the spread
TabAtkins: The spread syntax needs figuring out
astearns: With the usual caveats
astearns: so not a done deal
PROPOSED RESOLUTION: Specify this new parsing behavior for all
substitution functions, and some sort of spread-like thing
RESOLVED: Specify this new parsing behavior for all substitution
functions, and some sort of spread-like thing
CSS Display
===========
reading-flow and mix of auto-flow and explicit items
----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11208
TabAtkins: rachelandrew has started speccing reading-order
TabAtkins: which gets you tab-index-y behavior
TabAtkins: while doing so had a few questions that we wanted to run
by the wg
TabAtkins: Q1: Do we want reading-flow: <stick-with-source-order>?
TabAtkins: this might be needed because reading-order only works with
reading-flow container
TabAtkins: so if people want source order with some reordering
TabAtkins: so reading-order works for the children
TabAtkins: Di thinks it might be unnecessary
TabAtkins: I think it'd be useful
fantasai: I think it'd be a good idea to distinguish reading-flow:
{normal, source}
fantasai: but the initial value might not want to be just source order
fantasai: if we can avoid a double-opt-in would be nice
astearns: So you want reading-order != 0 to have an effect on
reading-flow containers
fantasai: Or cause things to become reading-flow containers
TabAtkins: That'd be confusing if you specify on a grandchild or so
for example
TabAtkins: don't think we want to make this work by default due to
the strict parent->child dependency
TabAtkins: I think it's worth the explicit switch
TabAtkins: and being a reading flow container has other implications
fantasai: Main one being how it scopes tab index right?
fantasai: it's already surprising that you have a weird side effect
fantasai: if that is not sufficiently significant for other aspects
of reading-flow let's not worry about it
fantasai: the order property doesn't require a double opt in
TabAtkins: The display value is the opt-in there
fantasai: That's probably true of reading order as well right?
TabAtkins: Not necessarily
fantasai: If we make it work on blocks would be great but I think we
should keep order and reading-order working similarly
astearns: I don't think we should do this now (source for
reading-flow)
astearns: Seems more theoretical, want to have a good use case for it
astearns: other than opting into this
astearns: fantasai's concern about the double opt-in makes sense to me
emilio: I have the feeling this could be potentially useful
emilio: but same gut feeling as Alan
emilio: if this works for blocks and things that are split, we have a
much bigger problem
emilio: well, complexity
emilio: not necessarily bad
emilio: I'd rather avoid adding it for now, if we decide it's useful
we can figure it out later
emilio: I'd be concerned about not having a switch on the container
emilio: because checking if you're a reading-flow container isn't
constant, you have to check all the children
emilio: so I think we'll want *some* opt-in on the container
emilio: I'd rather side-step discussion for now by not adding it
astearns: Let's check the other two questions
TabAtkins: Null decision was against fantasai's preference, is she ok
with it?
TabAtkins: the original q was: do we want to allow reading-order to
work on containers that are not asking for a special
reading-flow reordering value?
fantasai: Yes
TabAtkins: Sounds like people are leaning toward it being useful but
needing an opt in in the container
TabAtkins: But that was against your preference
fantasai: I misunderstood your original question, I don't think we
should ask the author to opt-in
TabAtkins: So that's opposite to what emilio was asking for
TabAtkins: We need to decide on that because it has compat
implications
astearns: And we're out of time
astearns: will leave the agenda tag to get back to it soon
Received on Thursday, 20 February 2025 23:38:40 UTC