- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 30 Jul 2025 19:28:38 -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 Values & Snapshot 2025
--------------------------
- RESOLVED: Add CSS URL to "Safe to Release pre-CR Exceptions" of
2025 Snapshot. (Issue #12539: Add CSS URL modifiers to
the 2025 snapshot)
- Before deciding on issue #12482 (Add CSS `random()` function to the
2025 Snapshot) the group will get wide review on random().
CSS Text Decoration
-------------------
- RESOLVED: If multiple values are omittable in serialization, but at
least one is required, choose the first one in grammar
order unless constrained by compat. (Issue #12486:
Clarify expected computed value for `text-decoration` and
similar shorthands (can we omit resolved `currentColor`?))
- RESOLVED: If a <color> value is omittable when computed to
currentColor, then it is omittable even though the
resolved value is not the 'currentColor' keyword (because
colors are absolutized), unless constrained by compat.
(Issue #12486)
CSS Anchor Position
-------------------
- RESOLVED: When only one auto inset, 'normal' alignment with
position-area resolves to the alignment that attaches to
the non-auto edge. (Issue #12512: More intuitive
alignment defaults when using one-sided insets)
- There was broad agreement that the current behavior mentioned in
issue #10258 (Handling popover default styles) was confusing and
needed to be fixed. There are concerns that the proposal may not
be compatible and may make styling difficult. Discussion will
return to github to investigate further.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2025Jul/0015.html
Present:
Rachel Andrew
Rossen Atanassov
Kevin Babbitt
Tab Atkins-Bittner
Oriol Brufau
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Chris Harrelson
Daniel Holbert
Mason Freed
Ian Kilpatrick
Roman Komarov
Romain Menke
Eric Meyer
Tim Nguyen
Miriam Suzanne
Lea Verou
Sebastian Zartner
Regrets:
Jonathan Kew
Chris Lilley
Josh Tumath
Scribe: ydaniv
CSS Snapshot 2025
=================
Add CSS URL modifiers to the 2025 snapshot
------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12539
fantasai: wanted to check modifiers are stable enough to be able to
add to snapshot exceptions list
fantasai: now or later on the year
Rossen: any feedback?
Rossen: seeing one on the issue
Rossen: if not we can resolve on the proposal
<TabAtkins> +1
Rossen: no objections so far
<Rossen> PROPOSED: Add CSS URL to "Safe to Release pre-CR Exceptions"
of 2025 Snapshot
RESOLVED: Add CSS URL to "Safe to Release pre-CR Exceptions" of 2025
Snapshot
Add CSS `random()` function to the 2025 Snapshot
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12482
fantasai: same question for the random() function
fantasai: probably we want to get a wider review first on
fantasai: so I think it would be good to know if other have concerns,
and bring them up soon, or if we're happy with that function
fantasai: would like a wide review first
Rossen: any opinions on this one?
<TabAtkins> +1 again
SebastianZ: any issues?
fantasai: we should probably get wider review
fantasai: wanted to raise attention
fantasai: after we get feedback from authors
Rossen: I feel like you got that
Rossen: let's follow up with the wider review and go from there
fantasai: ok
CSS Text Decoration
===================
Clarify expected computed value for `text-decoration` and similar
shorthands (can we omit resolved `currentColor`?)
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12486
fantasai: text-decoration, like background and other shorthands
accepts color and other values
fantasai: when we serialize color we actually return the resolved
color, not currentColor
fantasai: so serializing the currentColor of text-decoration, we
actually need to compute and serialize
fantasai: it's not backward compat and not adding useful information
to serialize the color value
fantasai: so we're proposing that text-decoration color is
currentColor, which is the initial value, it does not
serialize the color just the text-decoration-line value
oriol: wanted to mention that on another issue I saw similar things,
it's other shorthands as well
oriol: would like a more general resolution, that there are minimal
possible possibilities we could choose from
oriol: so in we do not include color if it's the initial value
emilio: we discussed similar things for shorthands, like margins,
where we do want the resolved value
emilio: it's a bit inconsistent for length and not color
emilio: not super concerned, but a bit weird
fantasai: emilio do you have an example?
emilio: like computedStyle.inset from shorthand, you get the computed
and serialize
emilio: and in text-decoration it's not the initial value
<oriol> I think emilio is talking about
https://github.com/w3c/csswg-drafts/issues/11382
fantasai: 2 things here: 1. when there are multiple possibilities,
then we <missed>
fantasai: then we keep the first grammar term and skip the others
fantasai: 2. there are some cases where the initial value, omittable,
is not the resolved value because it's further computed
than the actual one
fantasai: so do we still omit it? is it still omittable?
fantasai: I think for colors it's nicer to omit them, when it's an
initial value
fantasai: I think it makes sense to follow the example oriol mentioned
fantasai: I think to adopt it as a principle
fantasai: I think we want to audit it, to make sure we don't make
special exceptions
fantasai: I don't know if following this rule will get us into
backward compat issue for older shorthands, e.g. background
fantasai: for text-decoration we should resolve that, to omit
text-decoration-color
lea: so what is the proposal?
fantasai: when text-decoration-color is currentColor it's omitted in
favor of text-decoration-line
<florian> +1
<lea> +1
lea: assuming it's entirely about the shorthand, and longhand would
yield computed?
fantasai: yes
lea: would it roundtrip correctly?
fantasai: it'll round-trip better than with the behavior of
serializing out the resolved color
lea: there are some weirdness around :visited, right?
fantasai: won't talk about that
<lea> yeah, strong +1
Rossen: seeing +1's starting to add up
oriol: small point, proposed text, that if text-decoration-line is
set to initial value, but text-decoration-style is set to
value other than initial then it could be -style, right?
fantasai: correct
<fantasai> This is a good clarification
Rossen: can we get a resolution?
florian: more about the generalization stuff
florian: we should resolve
Rossen: any objections?
florian: there is text, but the generalized one is awkward
florian: in this case it's in grammar order, but do we want to be
specific? or generalize?
fantasai: to make t-d we need to generalize
fantasai: we need to make sure that it's backwards compat, when there
are multiple ones, we pick the first one in the specified
order
fantasai: a computed value of currentColor that is the initial
value <missed>
<ntim> (web compat is relevant here since Safari doesn't ship the
proper shorthand so far)
<fantasai> PROPOSED: If multiple values are omittable in
serialization, but at least one is required, choose the
first one in grammar order unless constrained by compat.
Rossen: any objections?
Rossen: hearing none
<fantasai> PROPOSED: If a <color> value is omittable when computed to
currentColor, then it is omittable even though the
resolved value is not the 'currentColor' keyword (because
colors are absolutized), unless constrained by compat.
<florian> +1
RESOLVED: If multiple values are omittable in serialization, but at
least one is required, choose the first one in grammar
order unless constrained by compat.
RESOLVED: If a <color> value is omittable when computed to
currentColor, then it is omittable even though the resolved
value is not the 'currentColor' keyword (because colors are
absolutized), unless constrained by compat.
Rossen: anything else on this one?
Rossen: moving on
CSS Anchor Position
===================
More intuitive alignment defaults when using one-sided insets
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12512
TabAtkins: we know old absolute positioning works
TabAtkins: single length made it act as if your specified you're
hanged, and added some magic
TabAtkins: we no longer resolve auto's
TabAtkins: with anchor positioning
<fantasai> They resolve to zero, rather than to remaining space
TabAtkins: if you were using that old magic, it's now broken
TabAtkins: you'll get shrunk
TabAtkins: fantasai suggested we restore that using the normal
alignment keyword, so if you're doing normal alignment
TabAtkins: it will restore the old behavior
TabAtkins: my opinion, don't care much, only that it works physical
and logical
TabAtkins: so having normal handle this is fine, iank is also fine
with this, happy to accept
<miriam> +1
iank: had one thought, that alternate solution is to only coerce, if
insets are 0, so if you set one inset it will stick to the edge
TabAtkins: that would be directly restoring the old behavior
TabAtkins: that means that everything anchor related won't work,
would like to retain 0's behavior
TabAtkins: because your contain block fits inside you can't rely on
containing block calcs
iank: fair enough
TabAtkins: this is related to other topic, we would like to preserve
the ability to override things
iank: I don't like the difference between 1 and 2 values specified
iank: I don't like the fact that if you don't specify position-area
you get one behavior, and otherwise a different one
iank: but maybe that's fine
fantasai: we could consider making the alignment work similar to
inset, resolve to 0
iank: we had compat concerns here
Rossen: sounds like we have a proposal, anything else?
<TabAtkins> Though this restores the *visible behavior* to be similar
between position-area:none and not-none
<TabAtkins> it just changes the way some keywords resolve
<fantasai> PROPOSED: When only one auto inset, 'normal' alignment
with position-area resolves to the alignment that attaches
to the non-auto edge.
TabAtkins: yes, correct
Rossen: objections?
RESOLVED: When only one auto inset, 'normal' alignment with
position-area resolves to the alignment that attaches to
the non-auto edge.
Handling popover default styles
-------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10258
<Rossen> https://github.com/w3c/csswg-drafts/issues/10258#issuecomment-3099281092
TabAtkins: dialogs and popovers in default UA stylesheet are
positioned in screen-centered ways
TabAtkins: this is done by using auto margins to cause centering,
it's reasonable
TabAtkins: we want popovers to be usable with anchor positioning
TabAtkins: so ideally you should be able to set position-area and it
works
TabAtkins: but default UA styles with non AP doesn't allow it
TabAtkins: has some interference here
TabAtkins: confuses everyone
TabAtkins: fantasai and I worked on a solution here, a new keyword
for this case, based on whether you're using anchor
positioning or not
<fantasai> To clarify: new keyword for the alignment properties
<fantasai> see
https://github.com/w3c/csswg-drafts/issues/10258#issuecomment-3099281092
TabAtkins: if you're not centers you, and if you are using AP it acts
like normal, which acts like a proper direction
TabAtkins: AFAWCT it should reproduce anchor positioning behavior
correctly, and you just need to set position-area
TabAtkins: masonf said it SGTM
<masonf> +1 the defaults are a footgun
TabAtkins: ntim had a concern with naming
TabAtkins: I think it's probably ok, but open to suggestions
lea: A margin keyword seems very overfit to me. Lots of use cases for
branching styling based on whether the element is anchored or
not, that cannot be done via the anchor() fallback. What about a
new boolean `<condition>` that can be used in `if()` and
`@container`?
<fantasai> It's not a margin keyword
TabAtkins: won't work, we can't rely on outside info here
TabAtkins: it's about whether if you're using AP or not
fantasai: it's not a margin keyword it's a keyword on the alignment
properties
lea: it says why it's not a good idea, but still have concerns with
overfitting
TabAtkins: agree, let's make it work somehow, this trips everybody
TabAtkins: also think that this isn't an unreasonable for things that
aren't dialog in general
lea: I completely agree we need to solve this
lea: just about direction
<chrishtr> +1 to strong evidence that it's confusing a lot of people.
I've heard this confusion many times now
iank: I'm a little bit worried about compat here
iank: even when we first changed it to center, when we didn't have
alignment keyword, we ran into compat problems
iank: it's a gut feeling this will be problematic, maybe introduce a
new property?
iank: or another syntax to ignore margins?
TabAtkins: trying to avoid a simple behavior switch, those are not
great design
TabAtkins: I think it might be not web compat
TabAtkins: that's the best design we've come by so far
TabAtkins: if you're not screwing with margin behavior too much this
will work and preserve right behavior
iank: don't know
TabAtkins: there are good and bad paths based on what you're doing
iank: people use dialogs in all sorts of ways
iank: worried...
iank: people set alignment properties, would like to try another
solution
TabAtkins: I suspect some of directions you suggest would be just
as bad
iank: maybe
iank: a lot of devs feel like the align properties should feel like
auto margins
kizu: a few things about naming, for popover it would be better, when
you anchor it starts doing what it should
kizu: q is how do we determine it? is it when there something in the
insets?
kizu: also think there's a second problem with try options
kizu: very often you position something, you click on it and it's not
there
kizu: right now to replicate common libraries you need to do a lot
kizu: so we should have a solution for people to not care about it
TabAtkins: so naming for popover over dialog, you need to set <missed>
TabAtkins: you also have to reset margin auto to 0
TabAtkins: second, when you use position area
TabAtkins: we probably want to expand the definition to different
things, will expand on separate issue
TabAtkins: also third issue, separate
lea: I think my main issue is that this is a conditional value which
hardcodes the condition and the value so they can neither be
customized, nor repurposed to branch off other styles/
properties. E.g. a library may want to apply different container
styles for anchorless "floating" popovers vs anchored ones. If
later we or authors want to vary different styles we have to
pile more API surface on. Even if the condition is not around
anchored vs non-anchored I wonder if there might be _some_ type
of `<condition>` we can use. Even if the condition itself is
overfit to this problem, at least that decouples it from the
property and value that is being branched.
TabAtkins: the condition we're worrying about is not whether you're
using it or not
TabAtkins: we can't style based on other styles
<iank> (because position-area is high priority we could coerce
margins to zero at that stage)
lea: both features work around it by IACVT
<fantasai> iank, that could maybe work... I wonder if it would be
better to do that to a new margin keyword so 'auto'
behaves as expected otherwise? But maybe it's not worth it.
TabAtkins: can we move back to issue?
Rossen: we are at time
Received on Wednesday, 30 July 2025 23:29:10 UTC