- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 11 Jun 2025 19:41:16 -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.
=========================================
Announcing pointer-animations-1 editor's draft
----------------------------------------------
- The editor's draft was published at
https://drafts.csswg.org/pointer-animations-1/ .
Review and issues are welcome.
CSS Anchor Position
-------------------
- The proposal for styling differently based on fallback selected
from @position-fallback was added to issue #8171 (Detecting
active @position-fallback). There were some questions to refine
it further and, when ready, it will be added to Anchor Position 2.
CSS Overflow
------------
- RESOLVED: Add :target-before and :target-after (Issue #11600:
Selecting ::scroll-marker based on relationship to scroll
target)
CSSOM View
----------
- RESOLVED: Use the writing mode of the target element (Issue #11796:
scrollIntoView spec text ("determine the scroll-into-view
position") disagrees with browser behavior on which
writing-mode(s) to use to determine sides)
CSS Borders
-----------
- RESOLVED: The option will be called bevel (Issue #12232:
corner-shape `angle` vs `bevel`)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2025Jun/0004.html
Present:
Tab Atkins-Bittner
David Awogbemila
Kevin Babbitt
Justin Breiland
Oriol Brufau
Kurt Catti-Schmidt
Stephen Chenney
Emilio Cobos Álvarez
Yehonatan Daniv
Robert Flack
Simon Fraser
Mason Freed
Paul Grenier
Daniel Holbert
Jonathan Kew
Ian Kilpatrick
Roman Komarov
David Leininger
Rune Lillesveen
Alison Maher
Eric Meyer
Cassondra Roberts
Noam Rosenthal
Alan Stearns
Miriam Suzanne
Josh Tumath
Lea Verou
Sam Weinig
Sebastian Zartner
Regrets:
David Baron
Chris Lilley
Bramus Van Damme
Scribe: JoshT
Announcing pointer-animations-1 editor's draft
==============================================
ydaniv: editors draft published.
ydaniv: ready for review, comments, issues, questions
ydaniv: constructive ones of course!
<kizu> https://drafts.csswg.org/pointer-animations-1/
astearns: thank you. yes please start adding issues
fantasai: what is necessary before taking it to FPWD?
astearns: we can incubate things as editors drafts. not terrible if
it takes a while
ydaniv: would be helpful to get a review from the group, initial
notions. specific parts like:
ydaniv: the ranges, if it's right. the way it's specified now.
ydaniv: the subject. there is a new range that you can center.
ydaniv: and the different range names
ydaniv: would be helpful to get some feedback, whether it's worth
prototyping
ydaniv: if there's no big issues, maybe we can move to FPWD and
prototype
<PaulG> Initial thoughts from an APA perspective: there MUST be an
accessibility concerns section. If this is used by default,
it will frustrate, annoy, or harm users with disabilities.
Developers should use an opt-in approach with this. (based on
my first glance)
astearns: if there are issues where you are particularly seeking
feedback, you can open your own or add a note to the draft
astearns: there must be an a11y concerns section. please add that or
open an issue to do so
flackr: it's hard for me to know how feasible the spec is. we could
go to FPWD but we don't know yet if we can implement what
we've written
flackr: risk of going to FPWD too early
florian: I think that's OK. if this is a promising direction, then
it's good to go to FPWD
florian: and we might discover it's not feasible, but I don't think
we need to wait for [prototypes]
astearns: this is only an introduction. please raise issues if
something is weird on first read
fantasai: this draft connects with css-animations-2 and maybe
scroll-animations
fantasai: those specs haven't been updated in two years. flackr, do
you think you have time to update them?
flackr: I want to but can't promise time to do so.
fantasai: maybe a plan to get them updated in the next three months
or so. scroll driven animations implementing in WebKit,
should probably be CR soon
fantasai: will be hard to cross link if we don't update
CSS Anchor Position
===================
Detecting active @position-fallback
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8171#issuecomment-2922342543
futhark: we can have fallback positions with @position rules
futhark: to position based on available space
futhark: there is desire to style differently based on which fallback
is chosen
futhark: to do so with container queries
futhark: I have made an explainer. got positive feedback from the TAG
futhark: the next step is to get a resolution and feedback. resolve
to work on it?
futhark: and to what level to add it to?
fantasai: this is super needed. I think concerned from usability PoV,
fallbacks being numbered is not great
futhark: explainer came to a different conclusion. chrome impl uses
numbers for simplicity
fantasai: for position-area values, I think we want to ask 'are you
in this mode or the other mode'. relative to the position.
<lea> What if we name them? `@try top { ... } @try bottom { ... }` etc
fantasai: so if my dropdown is in the top and then bottom, I don't
want to index to what order it's in
fantasai: with position-area, you've got the mapping with logical and
physical
fantasai: you want to say if it's inline-start, I want to query if
it's left or right
<emilio> Is it well defined what happens if you do cycles? Or does
the new anchor type also imply size containment or so?
futhark: we discussed should we map to try and names. if we map to
position-area, should it match a query for position-area
fantasai: I think we should query not the fallback, but the region.
map between logical and physical, or the name of a position
try
fantasai: and then you could add a flip block or flip inline
fantasai: and that would be easier to use and get you what you want:
to query the physical location
astearns: could you have more than one fallback in a particular
direction
fantasai: you query which one is active
fantasai: together if you have four items to try, I can query the
same way the first and the third position. I think it
should be queried based on details of the position
fantasai: like anchor area colon, position: block-start, if I have
specified that or the fallback, whatever that is
fantasai: the position try values would be their own named custom area
fantasai: that's why I use the name of the position try rule
lea: are there any more use cases than arrows?
lea: do you just need to know where the element is positioned?
lea: what you really want is how the element is positioned
lea: otherwise it's too specific to anchor positioning
lea: we should look at the ergonomics of how we make the arrows. with
this API, what does it look like to make arrows? it might look
awkward
miriam: I'm curious about the details, whether it involves
containment, but I can take it to an issues
futhark: we need style containment for counters.
TabAtkins: response to lea. needs to be tied to position try because
you don't know where the thing you're putting the arrow
on is
TabAtkins: for a tooltip, that needs to be flush
TabAtkins: needs to be tied to the styles used. could experiment for
other stuff. but for this use case, this design is what's
required
fantasai: I think this proposal connects really well with the tether
proposal
fantasai: to make them easier to do
<lea> Makes sense. Speaking of use cases, there's also transitions:
you want a different transition depending on relative position
(e.g. growing from the top or from the bottom)
astearns: we can open up issues to discuss these things. can we wait
until we've discussed the things that come up in the issues
fantasai: should go in anchor-positioning-2.
Properties & Values API
=======================
Figure out what to do with font-relative lengths
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9517
TabAtkins: the deal here is that if you have registered custom
properties. we resolve unit math.
TabAtkins: if you have an em, this now depends on the font-size
property
TabAtkins: I have proposal to add constraints to length type custom
properties
<fantasai> what constraints?
TabAtkins: not yet complete. number typed ones could also get this
from algebra
TabAtkins: this doesn't require any resolutions
TabAtkins: I need to a: extend this to apply to all typed custom
properties
TabAtkins: b: rewrite to use the new dependency mapping property that
is in all the new CSS specs
TabAtkins: will just be a mechanical transform, but I think there's a
solution. just need to take care of it now
fantasai: I don't understand why it was brought up to the WG if not
going to even explain what we're doing
TabAtkins: was brought up by oriol. I'm just acknowledging that it is
being worked on
<oriol> I didn't remember adding this to agenda, happy to wait for
Tab's edits
astearns: so we'll take it off the agenda and keep the issue open.
will bring it back when Tab has done some work
CSS Overflow
============
Selecting ::scroll-marker based on relationship to scroll target
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11600
flackr: there is one issue: target past and future to refer to the
target current marker
flackr: it wouldn't solve the other problem of styling the thing
targetted. I don't know if we have a proposal for that yet
TabAtkins: I don't like the name past and future. would prefer before
and after
TabAtkins: but we are saying yeah to it and no one commenting on it
otherwise
TabAtkins: do we want to resolve to do it?
fantasai: I can see why that makes sense. but we do have 'current'
which pairs with past and future
TabAtkins: I think current works on various axis
TabAtkins: I think before, current and after are reasonable adjectives
florian: it doesn't feel like a different axis.
TabAtkins: there is no time in 'steps'.
fantasai: should we go back and look at other places where we use
these terms?
TabAtkins: the pseudo-class for highlights API uses it as well.
<schenney> Specifically ::search-text:current
astearns: no strong opinion either way. would like to use before and
after consistently
fantasai: currently used for time axis, so maybe we should revisit
usage in the highlights api
<schenney> Nobody has implemented past/future in this context, so no
problem changing it.
TabAtkins: should be brought up in separate issue
astearns: resolution to add target-before and target-after?
TabAtkins: match the other targets in the scroll marker group before
or after the currently targeted one
florian: are we talking about a pseudo-class before and after?
TabAtkins: yes
florian: I think this is confusing having :before and :after
TabAtkins: it's :target-before and :target-after
astearns: would anyone like more time to consider this?
astearns: anyone who would object?
astearns: names can be bikeshedded
fantasai: I'm OK but Tab can you open issue about highlight API?
TabAtkins: yes
RESOLVED: add :target-before and :target-after
CSSOM View
==========
scrollIntoView spec text ("determine the scroll-into-view position")
disagrees with browser behavior on which writing-mode(s) to use
to determine sides
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11796
emilio: This is about what the axis for scrollIntoView is
emilio: should align on what browsers do, which I think makes sense
emilio: otherwise it's not clear which axis you are targeting from a
single....
emilio: the axis of a scroll container doesn't make sense
<smfr> seems fine
astearns: you are suggesting we change the spec to match what is done
by browser engines?
emilio: yes, chrome, safari and firefox
emilio: IIRC, interpreting the block and inline axis relative to the
writing mode
dholbert: scroll me to a position I'm on on the inline axis
dholbert: you might have multiple scrollers vertically in one and a
different direction in another
dholbert: these could end up doing different things in different
ancestors
dholbert: so map it to the physical axis using the writing mode of
the element
dholbert: and all scrollers work regardless of writing mode
astearns: is this mostly an edge case?
astearns: or are there use cases for elements whose writing mode is
orthogonal to the scroller?
dholbert: if you have children with a mix of writing modes and you
call the fn, you might expect them to do different things
regardless of the child
dholbert: but if no one does that, no content depends on that
fantasai: I think it's reasonable for content to have a mix of
writing modes. like Japanese magazines. sidebar might be
horizontal but headline vertical
fantasai: mix of writing modes in more complex layouts in Japanese,
but authors not taking advantage of that yet on the web
fantasai: common in magazines
emilio: I think the point is no one can depend on the spec behaviour
because it's not implemented anywhere
fantasai: then that means it's reasonable to change the behaviour
fantasai: it's weird because the right thing to do to is to base of
the writing mode of the container
dholbert: as soon as you have scrollers with a mix of writing modes,
it gets bizarre
dholbert: then it'll be horizontally aligned in one and vertically
aligned in another
dholbert: it's chaos. the proposal is to center on the axis being
scrolled into the view
dholbert: disregarding the writing mode of the parents
fantasai: could we take the writing mode of the nearest scroll
container and use it for all of them
dholbert: could also work.
dholbert: but if you're interpreting center on different axis, as
long as we decide on a single writing mode to use, that
addresses it
emilio: on the other hand, that's weird with overflow: hidden
emilio: I think, can you specify these in physical directions as well
with scrollIntoView?
emilio: if you know the axis to align to, that deals with the mixed
writing mode
emilio: I think what browsers do is the least bad option, TBH
dholbert: I don't see physical axis in the API
<oriol> https://drafts.csswg.org/cssom-view/#dictdef-scrollintoviewoptions
doesn't have physical
emilio: maybe we should add physical properties
emilio: can be a separate issue
<fantasai> +1 to adding physical axes
emilio: I will open an issue for that
astearns: option 1: change spec to use nearest scrolling container.
not implemented.
astearns: option 2: or use the writing mode of the target element.
maybe change things in the future once we have a better
understanding of content that needs better handling
fantasai: seems a reasonable way forward. should add the physical
keywords.
fantasai: both reasonable but option 2 for now
astearns: proposed resolution is scrollIntoView will interpret block
and inline axis in terms of the target element
astearns: with note in spec to use the nearest scroller at some point
if we work out a use case to do that
<iank> could be a separate issue with new keywords if that usecase is
valid.
dholbert: I'm mixed on the note. I think emilio's point about
overflow:hidden makes it intractable
fantasai: we have overflow: clip now
astearns: we could add a keyword to opt into the new behaviour
astearns: any objections?
RESOLVED: use the writing mode of the target element
astearns: I don't think we have enough info of the use cases to
change it
astearns: emilio will open an issue on the physical properties
emilio: maybe worth a separate issue on the proposal for a different
behaviour. I agree
CSS Borders
===========
corner-shape `angle` vs `bevel`
-------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12232
noamr: This is about diagonal line version of corner shape
noamr: in a zero value
noamr: angle and bevel
noamr: I prefer bevel because it's consistent with canvas
noamr: also, when I think of angle, it makes me think we'll specify
an angle like 90deg
noamr: also, I don't have a strong opinion, but it ties up a loose
end in the spec
smfr: I feel somewhat strongly that bevel is better
smfr: shaving the corner off something
lea: I feel moderately strongly about angle. better for non-native
speakers
lea: and corner-shape is used for shapes different to rectangle with
corner shaved off, including making diamond shapes
SebastianZ: I weakly prefer angle over bevel
SebastianZ: but we resolved changing it to angle, maybe through an
initiative from Una. but didn't see reasoning behind it
<fantasai> could also do 'straight', but maybe that's had to spell?
<fantasai> round | straight | notch | scoop
<fantasai> round | bevel | notch | scoop
<fantasai> round | angle | notch | scoop
<fantasai> round | diagonal | notch | scoop
noamr: I want to suggest third option: diagonal
noamr: diagonal corner
<lea> +1 for finding a third option, though no idea what that would
be :P
<lea> straight?
<smfr> straight was already proposed for "square" so that's confusing
<lea> fair
astearns: four options. I personally don't like angle. Like what
angle?
astearns: diagonal makes it clear it is a diagonal angle
astearns: leaning towards that. maybe because it's a new suggestion
<lea> +1 to diagonal
<fantasai> POLL: In the context of round | notch | scoop, should we
take a) bevel b) diagonal c) angle d) straight e) chamfer
<TabAtkins> And in the uncommon case, it's still clearly stretching
between the corners of some rectangle, which is also
correct
<florian> FWIW, I prefer bevel
<davidleininger> design tools use bevel right?
dholbert: if it's a square, it can mean connecting a line from one
corner to the other
<kizu> +1 to diagonal, slightly long, but ok-ish
TabAtkins: that makes sense. this is connecting two corners of a
region
<iank> slant ?
<lea> strong -1 to chamfer
<fantasai> +1 slant
dholbert: it's about two opposite corners
noamr: it is the diagonal of the square that defines the corner
<lea> slant seems okay too
florian: slant is not the worst
<TabAtkins> I don't think people would be assuming that about all the
other values - using 'round' doesn't mean the entire box
is round. It's clearly the shape of the one corner.
<SebastianZ> Also strong -1 on chamfer, even when that's used in many
3D tools.
<jfkthame> +1 bevel
smfr: bevel already exists in canvas
smfr: so I'm a little surprised how we're not going with what already
exists in svg and canvas
<ydaniv> +1
<TabAtkins> +1 to bevel, fwiw
<dholbert> +1 bevel
<kurt> +1 bevel
<smfr> `stroke-linejoin="bevel"`
<davidleininger> +1 bevel
astearns: poll on bevel vs diagonal?
<fantasai> POLL: In the context of round | notch | scoop, should we
take a) bevel b) diagonal c) angle d) straight e) chamfer
f) slant
astearns: any other options?
<emeyer> A
<davidleininger> A
<dholbert> a
<miriam> a
<schenney> a
<noamr> a
<jfkthame> a
<futhark> a
<florian> a
<JoshT> a
<SebastianZ> c
<smfr> a
<iank> A
<ydaniv> a
<kbabbitt> a
<fantasai> a, b/d/f
<astearns> a
<castastrophe> A
<TabAtkins> a
<kurt> a
<oriol> a
<kizu> a
<lea> b, c, d, f
astearns: clear winner of bevel, shall we resolve?
RESOLVED: the option will be called bevel
Received on Wednesday, 11 June 2025 23:41:50 UTC