- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 5 Sep 2025 06:53:35 -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 Text Decor
--------------
- RESOLVED: Change the definition to 'must do nothing'. and make the
computed value remain (Issue #12015: What to do with
`blink` value in `text-decoration`?)
CSS Grid 3/Masonry
------------------
- RESOLVED: Change initial value of item-tolerance to 'normal' (Issue
#12111: Make `item-tolerance` initial value `normal`)
CSS Overflow
------------
- The group discussed the options in github for issue #12176 (Giving
::scroll-marker-group a name (and optionally text))
- There was disagreement about if this type of labeling is the
scope of CSS or the scope of HTML. :before and :after allow
the labeling so there is a precedent, however a11y guidance
is away from that use case so it's unclear if it's a path
that should be followed.
- General questions about scroll markers being in CSS were also
discussed with this as another example of how this property
blurs the lines between CSS and HTML.
- Discussion will return to github with examples added to
hopefully make the issue less abstract.
- RESOLVED: line-clamp: <integer> with a height constraint clamps by
height or by lines, depending on what comes earlier,
pending compat issues (Issue #12041: Can you line-clamp
by both a number of lines and a height at the same time?)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2025Sep/0000.html
Present:
Jake Archibald
Tab Atkins-Bittner
Andreu Botella
Oriol Brufau
Keith Cirkel
Emilio Cobos Álvarez
Elika Etemad
Robert Flack
Diego Gonzalez
Hoch Hochkeppel
Daniel Holbert
Jonathan Kew
Chris Lilley
Alison Maher
Romain Menke
Eric Meyer
Tim Nguyen
Florian Rivoal
Alan Stearns
Miriam Suzanne
Josh Tumath
Sebastian Zartner
Regrets:
Rachel Andrew
Kevin Babbitt
Yehonatan Daniv
Noam Rosenthal
Lea Verou
Scribe: JoshT
CSS Text Decor
==============
What to do with `blink` value in `text-decoration`?
---------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12015
florian: title is a bit misleading. blink value no longer blinks. but
for compat needs to stay
florian: do we want to switch def from saying it may do nothing to
say it must do nothing?
florian: and how does computed value behave?
florian: firefox doesn't do anything special. or safari and chrome
where computed value drops blink value
florian: I hear safari and chrome going to match firefox
florian: so we probably want to switch to how it has no effect and
how there is no simplification of the computed value
ntim: for second issue, no strong opinion.
ntim: on the side of dropping it because since it does nothing, it's
reasonable to make it compute to none
ntim: but no strong opinion. deprecated. who cares. :D
astearns: and engines seem to be converging
PROPOSED: change the definition to 'must do nothing'. and make the
computed value remain.
RESOLVED: change the definition to 'must do nothing'. and make the
computed value remain.
CSS Grid 3/Masonry
==================
Make `item-tolerance` initial value `normal`
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12111
<alisonmaher> https://github.com/w3c/csswg-drafts/issues/10882
alisonmaher: two issues related to the issue
alisonmaher: proposal to use 0 instead of 1em for initial value
alisonmaher: may be less confusing for authors to see jumps
alisonmaher: argument against 0 is that it's not as accessible. less
than 1px causes jumps in dom order
alisonmaher: so proposed to keep 1em and see author feedback
alisonmaher: column-gap has the same default
alisonmaher: leave as 1em for now and use normal as initial value and
compute to 1em
oriol: agree that if we go for 0 for masonry, computed value should
be normal
oriol: 1em for masonry and otherwise 0
oriol: preference still defaulting to 0 for masonry.
oriol: I agree 1em makes more sense. but preference is it may cause
confusion
oriol: no one of the values in masonry libraries does this
oriol: providing a value that is small but not 0 may fail the
expectations of authors
oriol: not sure if 1em will work well in general. something other
than 0 may be good. 1em may be a random choice
oriol: have preference for 0 but not objecting to 1em. if we go for
0, may not need normal value
astearns: with the other issue about whether the default is 1em or
1lh, we can discuss separately for masonry. but making the
default value 'normal' allows us to have that discussion
for other layout modes that may need a different value
oriol: masonry is strange if we say that the normal behaviour will be
0 because it will always be 0. but we can work out how to
resolve this later
fantasai: I agree with oriol that it would be weird
fantasai: but if we have a none 0 value, it should be normal.
<TabAtkins> +1
fantasai: me and TabAtkins agree initial value should be 1em, to
match row-gap
astearns: putting aside what it computes to, can we resolve that the
initial value is 'normal' for now?
RESOLVED: change initial value of item-tolerance to 'normal'
CSS Overflow
============
Giving ::scroll-marker-group a name (and optionally text)
---------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12176
flackr: when using CSS scroll markers, we implicitly create a
::scroll-marker-group
flackr: for presentation and a11y tree, the element doesn't have a
name to say what type of thing it's containing. maybe slides
or pages or items
flackr: it's good practice and visually desirable to have a label
flackr: I wanted to get some consensus on what path we should follow
here
flackr: I listed possible options.
flackr: without major syntactic changes, we could add the content
before the pseudo on the scroll-marker-group
flackr: but wanted to get group's thoughts
fantasai: when you're at the point where you need labels, you should
probably use HTML
<astearns> +1 fantasai
fantasai: when this was just a decorative thing, that seemed like it
could be in css.
fantasai: once it has content, it seems like it needs to be in the
content
TabAtkins: I disagree with fantasai
TabAtkins: we already have the alt property to add alt text ::before
and ::after
TabAtkins: we encourage adding content in the dom
TabAtkins: but this labeling serves the same purpose
TabAtkins: this might only apply in certain media queries and
therefore be stylistic
TabAtkins: I think simply labeling things is appropriate
astearns: while I agree with the alt text comparison, I wonder if
it's just that sort of thing. is there anywhere else in CSS
where we apply an aria-label
flackr: this is wherever the content property applies
astearns: is it a label or more like a role?
astearns: do we need ways of setting roles for a11y affordances?
PaulG: the examples of tabs would be a tab list and not just a group
PaulG: so there are different roles for different collections of items
PaulG: content is also problematic for accessibility, like with
translations
PaulG: so we tell people to avoid it
PaulG: there are multiple issues. could we see examples with the role?
PaulG: I suspect it will get complicated without a lot more hinting
flackr: this is not about setting the role. aria has examples of
using a tablist role with a label
flackr: this is just a label that is a friendly name for the user to
explain it. we are exploring changing tablist roles with a
different property in a different issue
flackr: this would be similar to the aria-label property
JoshT: haven't read the issue yet, but TAG recently got back to you
about this
JoshT: anything they mentioned that is relevant to this?
flackr: this specifically, not sure. tabs-or-links resolution from
the other issue (about changing the role and interaction
behavior) was directly in relation to some of the TAG feedback
flackr: I think this might have come up a bit as well. I'm trying to
align the things that you should do to make your site a11y
aligned, as easy as possible
flackr: so being able to give a more contextually meaningful label
seemed like a nice thing for devs to be easy to do
florian: This is a passing thought. whether this should be done in
CSS or HTML...
florian: this seems like another case for cascading attributes
TabAtkins: I don't think that's the case here. these are CSS
generated and that would only work if you have the markup
<fantasai> +1 to cascading attribute sheets being useful for many of
these kinds of cases, and also probably not relevant to
this case
florian: so it's adjacent but not quite right
keithamus: Concerned about the recurring theme with scroll markers.
The question of why it isn't in HTML.
keithamus: this is the case again. If you supply a label with CSS for
scroll makers, why not every element?
keithamus: does the aria spec need to be updated to mention stuff
about CSS?
keithamus: does the a11y tree get more complex as a result?
flackr: you can already set a content value
keithamus: that's limited in scope
keithamus: one property on pseudo-elements. this isn't a suggestion
to allow content in a pseudo-element
flackr: this is
astearns: well in three of your four options
flackr: yes. we have a pseudo-element and we want to give it
pseudo-content
<PaulG> CSS pseudo element content, either :before or :after, must
only be used for decorative purposes. If you insert
meaningful content using a :before or :after pseudo element,
it is in violation of success criteria 1.3.1.
<PaulG> arguing that this is the same thing, is going to cause issues
astearns: as PaulG mentioned, the a11y folks don't like us doing that
astearns: I wonder, should we take the issue back to consider whether
the use case should be addressed in HTML?
TabAtkins: I think your question is, 'should we be doing scroll
markers in css at all?'
TabAtkins: I don't know what is the more specific use case you might
be targeting?
TabAtkins: how could we do that in markup without the whole thing
being in markup
PaulG: you could point to an element with content in it
ntim: Keith's question is legit
ntim: we had discussions about adding event listeners onto the
elements, and now labels
ntim: will we end up needing slotting inside pseudo-elements?
ntim: I think a boundary makes sense. we need to find a boundary
<fantasai> +1 to figuring out where the boundary is
kizu: someone mentioned on one of the threads about whether we can
connect a HTML template to a pseudo-element
kizu: let's say we have a pseudo-element that provides something as
content
kizu: then define the template in HTML which can be translated
kizu: one common case is adding icons. or adding more complex content
kizu: something we never did before but could be explored
kizu: and could be dynamic
florian: on the HTML vs CSS discussion, it feels CSSy still. this is
the presentation, not the content of the document
florian: so having the whole thing or a chunk in CSS does make sense
florian: if we have building blocks on both sides, that may work too.
this is not pure content
florian: I'm kind of sorry I pushed the discussion in that direction
florian: are we going into abstract theoretical purity things
florian: but if this helps us find a better path, maybe that's right
<TabAtkins> +1
keithamus: I don't think it's too abstract. I would have also
raised it
keithamus: there are common problems here with solutions today in HTML
keithamus: the scroll-marker-group, is there more than one?
flackr: no
keithamus: so this could be a slotted element
keithamus: it could be supplied to you if you want it fully
decorated. but if you want to change the role or whatever,
you could add a new HTML element into your container and
that acts as the element that is slotted in
keithamus: it would be just like ::detail-summary. that would point
to the detailed content of the summary
keithamus: I think scroll markers could also fit that pattern
keithamus: I think it solves the general problems that this design is
pointing towards
<ntim> (::details-summary does not exist anymore, ::details-content
does though)
florian: I am unsure. yes somewhat, but it bakes into the markup
assumptions about how we will present the whole thing which
is a smell as well
keithamus: I guess I'm curious what presentation assumptions having
an element in the dom makes
florian: maybe I misunderstood what you meant, but depending on when
you use scroll-marker or -group at all, you might not need
that element
florian: you may have completely different presentation of the
content that doesn't need these things at all
florian: but if you do need them and they're not baked into the
markup, you can't
florian: or otherwise you have it and you need to adjust your markup
TabAtkins: this is related to how most UI frameworks have a container
type.
TabAtkins: in CSS, it is purely presentational and you can turn it off
TabAtkins: that's the idea here too, where a styling choice can
affect whether you have scroll markers
TabAtkins: it is theoretically possible to have a pattern in HTML
that has scroll markers
TabAtkins: if it is something that can optionally generate scroll
makers, then the presence/absence of it is CSS dependent
TabAtkins: most of the questions like architectural decisions are
the same
TabAtkins: we're trying to avoid the situation where if we were to
add markup for scroll markers, that would automatically do
scroll makery stuff and you can't meaningfully turn it off
keithamus: we can have different semantics here. we could make it
conditional even based on UA styling
keithamus: and that will make it affect the a11y tree
keithamus: I'm concerned that we're extending this concept in ways
that will create more burdens when we could just have an
element on the page and influence the a11y tree normally
keithamus: if someone wants to change any property for it, the
solution already exists
fantasai: there are a number of scroll markery things we don't expect
to generate in CSS. like a ToC where the content of the
heading is the link. that would need to be done in the HTML
fantasai: there is a set of use cases for scroll markers that we've
already decided belong in HTML
fantasai: I think going back to ntim's question, where do we draw the
line for what use cases are in HTML?
florian: there is a tension here about what is a natural fit for the
capabilities of the language
florian: what is an appropriate decoupling of content and CSS?
florian: they are overlapping
florian: I maybe lean towards decoupling with presentational things
being in CSS more often than not
florian: it's presentationy and you may want to turn them off or on
fantasai: to the extent that the more something is coupled with the
content, the more it belongs in HTML
fantasai: also, would be useful if this issue had more concrete
examples of what we mean by a tablist. they're normally
labelled with something
fantasai: that would be useful.
fantasai: and we don't seem to have a consensus here. we should
probably move on
flackr: I think that's fine to wrap up.
<flackr> https://github.com/w3c/csswg-drafts/issues/8892
flackr: I want to point out there's a similar issue for selecting
content from pseudo-elements
flackr: I think part of this is dev ergonomics
flackr: I can try to distill this down. I don't know if we're getting
anywhere but can bring back to issue
flackr: it's basically just a label for your scroll markers. I can
put examples in the issue
florian: it may help focus
Can you line-clamp by both a number of lines and a height at the
same time?
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12041
andreubotella: [shares slides]
andreubotella: when we looked at line-clamp, this was not the
approach we would take in other browsers
andreubotella: you can have a fragment. the first fragment has a
forced breakup. if you move the height so it breaks
before the line where it breaks, the content moves
into the second fragment
andreubotella: but does the line clamp still apply?
andreubotella: when I was prototyping this, we understood it to be
clamping by lines or height but not both at the same
time
andreubotella: I didn't realize that this was not the agreed approach
until in April F2F
andreubotella: I implemented this recently and have no problem with
it being in the spec
PROPOSED: line-clamp: <integer> with a height constraint clamps by
height or by lines, depending on what comes earlier
andreubotella: height constraint means height, max-height, etc.
andreubotella: could be a constraint through the intrinsic layout
andreubotella: we accidentally shipped this behaviour in Chrome 140
and it was reported as a regression by two devs
andreubotella: we reverted the change and have added use counters for
line-clamp with height constraints
andreubotella: we hope to have useful data in December
andreubotella: I asked those devs what their use cases were
andreubotella: for one, their use case would not be affected by this
change
andreubotella: it is possible we might need to not do this for the
-webkit-line-clamp. we will know in December
florian: In general, I support proposal
florian: if you have ten lines, you ask for four, you cut off at
three, I think this is better
florian: if we are constrained by compat, I would be sad but OK
having a difference between -webkit- and non-prefixed
florian: if the breakage is bad, we can do a difference in behaviour
<Kurt> https://issues.chromium.org/issues/436345865#comment23
fantasai: I agree with florian. I had some questions
fantasai: if only one line fits, we should make that line doesn't get
clamped
fantasai: it seemed like in one case, they had a line height of 1em
and a line clamp of 3 lines and a max-height of 3
fantasai: in theory, there should be no conflicts between these two
unless you have substantial content
fantasai: there are often small difference in line height which can
create a small amount of overflow not visible to the author
fantasai: so we might need some slack when working out whether to
push over a line to the next fragment
andreubotella: do you expect a difference between just line-clamp or
with height as well when calculating slack
fantasai: not sure. maybe we do that. if it's something that's weird
that we have to do for web compat, maybe we do have the
difference for the -webkit- prefixed version
fantasai: it might end up being something reasonable
florian: I can't see how we make it work. there is not clamp by
height.
florian: the height you set is with regular height properties or the
layout system
florian: so I don't think we can give slack to the actual height
florian: you could let content overflow just a little bit
florian: I was wondering if instead of clamping or sizing, could this
be about what we have in the css inline layout spec
fantasai: yes could be related. we will have to see
fantasai: if we get a lot of cases where this is an actual problem
and the maths doesn't work out
PROPOSED: line-clamp: <integer> with a height constraint clamps by
height or by lines, depending on what comes earlier
RESOLVED: line-clamp: <integer> with a height constraint clamps by
height or by lines, depending on what comes earlier,
pending compat issues
Received on Friday, 5 September 2025 10:54:10 UTC