- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 7 Aug 2025 19:32:26 -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 Color Adjust
----------------
- RESOLVED: Republish Color Adjust
Add a `::interest-hint` pseudo element to interest invokers
-----------------------------------------------------------
- RESOLVED: Pursue this functionality in HTML. Close this issue.
(Issue #12437)
CSS Anchor-Position
-------------------
- RESOLVED: All percentages (insets, sizes) resolve against the
effective containing block (no inconsistency) (Issue
#10861: Introduce "document containing block" for some
purposes?)
- The solution for issue #12371 (Define precisely when anchor recalc
points happen, and which offsets it captures) is potentially
editorial and needs to be investigated a bit further.
Directionally, the proposal is anchor positioned boxes
recalculate layout for all changes that might affect their
size/position except scrolling except for special recalculation
points.
Web Animations
--------------
- RESOLVED: Make Animation Trigger related things readonly (Issue
#11918: Should AnimationTrigger properties be readonly?)
CSS Multicol
------------
- RESOLVED: Adopt syntax 'columns: [<column-width>||<column-count>]
[/<column-height>]? (Issue #12050: `columns` shorthand
with `column-height` and `column-wrap`)
- RESOLVED: Shorthand 'columns' also resets column-wrap (if it
exists) (Issue #12050)
CSS Env
-------
- RESOLVED: Don't use env() for this. Use an @page descriptor roughly
as proposed by dholbert; work out details in the issue.
(Issue #11395: Expose unprintable areas via CSS)
Pseudo/Page Floats/Inline
-------------------------
- RESOLVED: Accept Elika's bullet points in the last comment:
https://github.com/w3c/csswg-drafts/issues/8842#issuecomment-2762607744
(Issue #8842: Float and first-letter pseudo-element
interaction missing from the latest specs)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2025Aug/0000.html
Present:
Rachel Andrew
Tab Atkins-Bittner
David Awogbemila
Kevin Babbitt
Oriol Brufau
Kurt Catti-Schmidt
Emilio Cobos Álvarez
Sam Davis
Yehonatan Daniv
Elika Etemad
Javier Fernandez
Robert Flack
Mason Freed
Diego Gonzalez
Hoch Hochkeppel
Daniel Holbert
Roman Komarov
Una Kravets
Chris Lilley
Alison Maher
Eric Meyer
Florian Rivoal
Alan Stearns
Miriam Suzanne
Lea Verou
Sam Weinig
Sebastian Zartner
Scribe: fantasai
Administrivia
=============
<fantasai> Several people missed the gap breakout. Check out the
minutes.
<fantasai> Survey is out wrt masking prefs for TPAC
<fantasai> Paris F2F is soon! REGISTER IN THE WIKI
<TabAtkins> https://wiki.csswg.org/planning/paris-2025
<fantasai> Tab is trying to make reservations.
astearns: Even if you're not in person, please register your
availability in the wiki for virtual participation.
Color Adjust
============
scribe: emilio
scribe's scribe: fantasai
Publication
-----------
github: https://github.com/w3c/csswg-drafts/issues/6900#issuecomment-3145806082
alisonmaher: we we wanted to republish color adjust
fantasai: what's changed?
alisonmaher: removal of special handling of system colors
alisonmaher: emulation support for forced-colors
alisonmaher: updated the properties that apply
alisonmaher: and changed the fallback logic
<ChrisL> https://www.w3.org/TR/2025/CRD-css-color-adjust-1-20250812/#changes
astearns: questions / concerns?
RESOLVED: Republish Color Adjust
Add a `::interest-hint` pseudo element to interest invokers
===========================================================
github: https://github.com/w3c/csswg-drafts/issues/12437
masonf: re. interest invokers, we have some props to control the
delay, pseudo classes (open issue)
masonf: the idea here is to add a pseudo-element as a `<button>` with
invokers, only for interestfor and when the element has
`content`
masonf: this is generically useful but specially useful for
touchscreens
masonf: so you can just tap on it
masonf: should be styled like a button
masonf: tentative name is `::interest-hint` or `::interest-button`
masonf: number of open questions
masonf: one is name
masonf: another is what kind of pseudo-element is it (tree abiding,
fully stylable, something else?)
masonf: should there be a way to put it before the originating
element rather than ::after
masonf: some others after prototyping this
masonf: this is a button that can be originated by a button
masonf: so button-in-button which is a no-no in a few questions
masonf: another is focusability
masonf: similar to those there's a question about how to handle click
of them
<fantasai> ::interest-button seems clearer, ::interest-hint feels
like it could be the hint card
masonf: because of all these questions
masonf: maybe this is an html feature
masonf: so you have a button with a toggleinterest command or so
masonf: not sure how much time we have to dig into it
astearns: may be better to start with html?
emilio: Was going to ask about that, this feels like a feature that
is more generically useful.
<lea> +1
<lea> (to emilio)
emilio: A pseudo-element for this feels oddly specific, especially if
conditional on the element. What triggers creation, is it all
elements, only elements that can trigger a popover, something
else?
emilio: Feels like an HTML solution that can toggle interest feels
more generic to me, and less open questions.
lea: agree with emilio, this feels overfit to me, I'd rather expose
the right primitive to authors rather than special-casing that
particular interaction
TabAtkins: having tried to implement, it's very difficult to get right
TabAtkins: don't want to put the burden on authors
TabAtkins: bikeshed specs do it badly
TabAtkins: so fixing it properly seems worth it
lea: agree it should be easier, not sure we should special-case it
for interest invokers like that
lea: but yeah let's figure out what's making it so hard
TabAtkins: the difficulty is that there's tons of things that can
interact with this transient interest
TabAtkins: plus all the a11y tree interactions
TabAtkins: not sure there are primitives that we could make much
easier
TabAtkins: for something that's so common and so useful
TabAtkins: it's worthwhile to special-case
masonf: command/commandfor feels pretty easy for an author
masonf: the ua could know the right relations from that
masonf: so should be easy
masonf: almost dropped the issue from the agenda, seems like the
prevailing sentiment is that it belongs in html
<TabAtkins> (My big fear is that when we try to genericize these
sorts of interactions too much, we run into the issues
that CSS Toggles had - they're just *too* generic, and
actually need pretty specific handling to do right.)
lea: related, we have a parallel issue to make ::tooltip stylable
lea: many of these use cases are covered by that
lea: also we see over and over that any ua-generated ui needs to be
customizable
lea: I understand the pseudo makes it styleable but limits what you
can do
lea: e.g. can't do inline svg
lea: if we add this feature I can see many cases that it should serve
but shouldn't
lea: that's why I suggested decomposing it
<fantasai> +1 to emilio / lea / masonf
masonf: should we resolve on this not being in CSS?
astearns: would like to see html solution, but you file it?
masonf: anyone would object against this?
<fantasai> PROPOSED: Pursue this functionality in HTML
<masonf> +1
RESOLVED: Pursue this functionality in HTML. Close this issue.
CSS Anchor-Position
===================
scribe: fantasai
scribe's scribe: TabAtkins
Introduce "document containing block" for some purposes?
--------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10861#issuecomment-3014425000
TabAtkins: If you have an abspos that has its CB generated by a
scroller, right now, it's CB is like the ICB -- a
viewport-sized box anchored to the origin
TabAtkins: This is not great in many case, so we had adopted a
proposal to adopt a CB approximating the scrollable area
TabAtkins: Ian and I thought that percentages should still resolve
against this new CB
TabAtkins: fantasai thought that was weird and inconsistent so
thought we shouldn't do that, and be consistent
TabAtkins: Ian and I reviewed, and couldn't remember why we wanted
width/height to resolve against the scrollport when the
rest of the CB is the entire scrollable area
TabAtkins: So we're ok with resolving on all percentages resolving
against the effective containing block
RESOLVED: All percentages (insets, sizes) resolve against the
effective containing block (no inconsistency)
Define precisely when anchor recalc points happen, and which offsets
it captures
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12371
TabAtkins: We have a concept in anchor positioning where we can't
always track the exact position of the anchor, because if
it is in different scrolling context then that can get
janky
TabAtkins: So we define specific points in time when we do go and
look for the actual scroll offsets to get accurate
positions for layout
TabAtkins: We remember those, and if you scroll after that, you lose
the connection
TabAtkins: There's one spot that Emilio thought should add, a
recalculation point, is when your anchor references change.
TabAtkins: Agree that's a missing point
TabAtkins: If there's more here, I would agree with Emilio, but at
the minimum we should add anchor reference changing as a
scroll recalculation point
astearns: Further question on whether you need to recalc when the
layout changes.
TabAtkins: That should be implicit in the spec already... only scroll
positions that we don't live-respond to
fantasai: I think my question is should we be defining this in the
opposite direction?
fantasai: so we say what we don't pay attention to (scrolling) rather
than what we do (several things)
fantasai: lots of things to include that you might want to respond
to. mainly we just want to say that it doesn't respond to
scrolling.
fantasai: if you change the layout of the anchor itself, that
recalcs the anchor box - positioned element might need to
resize, etc.
fantasai: if the CB changes, etc.
fantasai: I'm assuming all of these things make it become invalid,
otherwise your layout wont' make sense
TabAtkins: Layout changes are definitely intended to already be
captured live. If spec doesn't make that clear, I'll
clarify
TabAtkins: I can consider flipping the definition, but do what to be
careful about what we require things to do.
TabAtkins: Right now allow list where you definitely remember changes
is a good approach... but a lot of the things you listed
should be implied.
TabAtkins: but can take a resolution on that and make sure spec
reflects it
fantasai: So what are the exceptions that you don't do relayout for?
TabAtkins: You don't respond to scroll positions, except as defined
where you refresh those anchors.
TabAtkins: Layout refreshes everything. Should invalidate everything.
But as long as layout isn't changing, we should only
respond to scrolling at particular spots as defined.
fantasai: [explains why the spec is confusion]
TabAtkins: Ok, sounds like I should clarify the spec.
PROPOSED: Anchor positioned boxes recalculate layout for all changes
that might affect their size/position except scrolling except for
special recalculation points.
TabAtkins: Need to think about it a bit, but I think that's probably
right.
TabAtkins: Let's come back if anything more than editorial changes is
needed.
Web Animations
==============
Should AnimationTrigger properties be readonly?
-----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11918
flackr: If we make the objects you get from JS for AnimationTrigger
writeable, then it requires introducing complexity of knowing
when to take changed values from style vs when author has
overwritten and need to take that.
flackr: So proposal is to make them readonly
flackr: This way if you get a CSS trigger, we will always track
updates to style
flackr: and don't need to track whether developer has changed
behavior through JS object
flackr: Follow conventions for modifications to animations
<kbabbitt> +1
<ydaniv> SGTM
astearns: Seeing agreement in the issue. Anyone with concerns?
<TabAtkins> +1
astearns: Proposed to make these properties readonly
flackr: applies to class of trigger-related things
RESOLVED: Make Animation Trigger related things readonly
CSS Multicol
============
`columns` shorthand with `column-height` and `column-wrap`
----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12050
rachelandrew: Need to decide what to do with 'columns' shorthand and
new properties
rachelandrew: Syntax we're proposing is in my last comment on the
issue -- should we add column-height, and how do we
represent it unambiguously
<TabAtkins> Looks good to me. Always unhappy having to use a /, but
it's needed here.
fantasai: LGTM, with Oriol's fixes
florian: Seems fine to me. If we need column-wrap property...
probably should cascade together?
fantasai: we could say that if column-wrap exists, it's reset-only by
the longhand
astearns: If it goes to the shorthand, can extend it later
rachelandrew: yes
astearns: if we do need it in the shorthand, we can put it in after
column-height probably
florian: I don't think the proposal says you reset colum-wrap right
now, is that okay?
fantasai: We can resolve on both.
rachelandrew: I'm okay for now, yes.
PROPOSED: Adopt syntax 'columns: [ <column-width> || <column-count> ]
[ / <column-height> ]?
<TabAtkins> +1
<florian> +1
<kbabbitt> sgtm
PROPOSED: Shorthand 'columns' also resets column-wrap (if it exists)
<florian> +1
astearns: Any objections?
RESOLVED: Adopt syntax 'columns: [ <column-width> || <column-count> ]
[ / <column-height> ]?
RESOLVED: Shorthand 'columns' also resets column-wrap (if it exists)
CSS Env
=======
Expose unprintable areas via CSS
--------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11395
TabAtkins: Proposal to add new env() variables for the unprintable
area of the page
TabAtkins: They will be zero on a normal screen display
TabAtkins: But when printing, they would show how far you need to be
to ensure stuff is printed
TabAtkins: There seems to be overall agreement that this is fine.
Some amount of fingerprinting concern, but since only
shows up when you're printing less concern.
dholbert: Last few comments between me and Morten is that we don't
want to use environment variable
dholbert: because you can't know that when preparing, depending on
how it gets printed
dholbert: If you tell them there's a half-inch margin, and they are
printing onto some other size of paper and are scaling
things down
dholbert: then you are in the unprintable area
dholbert: so I suggested a different approach
dholbert: which is to clamp the margins
dholbert: But exposing the numeric value is potentially a footgun
florian: I followed why an env() variable wouldn't be appropriate.
Didn't follow what you're proposing instead.
florian: There are cases where unprintable area differs on which side.
florian: It's not generally knowable what it is. But sometimes it is
florian: Would your proposal allow for that?
dholbert: Yes
dholbert: Simple way is to use the largest unprintable as if it's the
distance on all sides
dholbert: so can have a simple keyword for that
dholbert: or could ask for per-side behavior
dholbert: I suggested 'enforce-safe-margin' descriptor, that UA could
take into account after it knows the requested page size
and the output paper size
<fantasai> ->
https://github.com/w3c/csswg-drafts/issues/11395#issuecomment-3029150700
dholbert: Idea is to floor the author's specified margin with
whatever info we get from the printer
dholbert: Author could choose whether to apply same increase to all 4
sides, or each individually, or add it into already
requested margin
dholbert: Morten and I are not sure that we can know each side
surely, because e.g. for duplex printing might not know
dholbert: So might be a printer-specific detail.
florian: In general case that we won't always know, but in some cases
we can
florian: If you don't know, should assume they're all the same
astearns: sounds like we do prefer the descriptor over env(). Should
we resolve on using a descriptor and take it back to the
issue?
PROPOSED: Don't use env() for this. Use an @page descriptor roughly
as proposed by dholbert; work out details in the issue.
RESOLVED: Don't use env() for this. Use an @page descriptor roughly
as proposed by dholbert; work out details in the issue.
<fantasai> +1 thanks dholbert !
<dholbert> \o/
Pseudo/Page Floats/Inline
=========================
Float and first-letter pseudo-element interaction missing from the
latest specs
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8842
<fantasai> ->
https://github.com/w3c/csswg-drafts/issues/8842#issuecomment-2762607744
fantasai: some issues needed to be clarified, and some unclear details
fantasai: but I think we should say that if initial-letter is
anything but normal, we ignore float
fantasai: otherwise, if float is on the ::first-letter, behavior is
impl-defined. And deprecated.
fantasai: I think that should address most concerns.
<TabAtkins> (sounds good to me)
florian: when you say impl-defined, how broadly do you mean this? "it
must work, but impl defined how it works" or "whether it
does anything at all is impl defined"?
fantasai: the latter, no real requirements at all on it
fantasai: if we defined this today, we would not make float work
florian: probably true. it is working on browsers today though, with
some differences, right?
fantasai: yeah, so that's a web-compat decision they can make about
what they want to continue to do. but otherwise we want to
move people to initial-letters
kizu: sounds good. some small context
kizu: a case initial-letter doesn't cover that float does is
shape-outside.
kizu: wonder if we could define shape-outside to work with
initial-letter. common for it to have ascenders/descenders that
you want to wrap text around
kizu: this is I think where we had interop issues, if you used
initial-letter + float + shape-outside, it didn't correctly
work everywhere
fantasai: shape-outside is defined, I think, to interact with
initial-letter in the spec, I think?
kizu: hm, I'll look again, it might have not been there a while ago
astearns: I recall adding something for this...
fantasai: [reads from the spec about shape-outside]
kizu: I'll do more tests and see what we have today
astearns: so proposed resolution is to follow what's outlined in the
last comment of this issue?
<fantasai> See If the value of shape-outside is not none,
shape-outside is used instead of the glyph outline.
<fantasai> In both cases, shape-margin is applied to expand the
outline, and the resulting outline is clipped by the
initial letter’s margin edges.
<fantasai> https://www.w3.org/TR/css-inline-3/#initial-letter-wrapping
astearns: concerns? objections?
<TabAtkins> +1
RESOLVED: Accept Elika's bullet points in the last comment
Received on Thursday, 7 August 2025 23:32:58 UTC