- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 4 Jun 2025 20:01: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.
=========================================
CSS Shapes
----------
- RESOLVED: Move shape() to css-shapes-1 and ask for wide review on
that and maybe path() and add noamr as editor to
css-shapes-1
Scroll Anchoring
----------------
- RESOLVED: When selecting a viable priority candidate (e.g.
contenteditable), run the regular selection algorithm
scoped to that element instead. (Issue #11748: anchoring
within contenteditable elements)
CSS UI
------
- RESOLVED: Define shorthand interest-delay for interest-delay-start
+ interest-delay-end (Issue #9236: Add "show interest"
and "lose interest" hover delays to CSS)
- RESOLVED: Add a normal keyword as initial value to match platform
conventions (Issue #9236)
- RESOLVED: Start with single value, add a note about possibility of
needing alternative values for e.g. keyboard/touch (Issue
#9236)
CSS Color
---------
- RESOLVED: Revert change to make all gradients interpolate in OKL by
default (Issue #7948: What if gradients with legacy
colors *also* interpolated in Oklab by default?)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2025Jun/0000.html
Present:
Tab Atkins-Bittner
Kevin Babbitt
David Baron
Justin Breiland
Yehonatan Daniv
Elika Etemad
Robert Flack
Simon Fraser
Mason Freed
Paul Grenier
Daniel Holbert
Brad Kemper
Vladimir Levin
Chris Lilley
Alison Maher
Florian Rivoal
Noam Rosenthal
Jen Simmons
Alan Stearns
Lea Verou
Samuel Weinig
Regrets:
Rachel Andrew
Andreu Botella
Oriol Brufau
Brian Kardell
Ian Kilpatrick
Roman Komarov
David Leininger
Romain Menke
Miriam Suzanne
Josh Tumath
Bramus Van Damme
Scribe: fantasai
Scribe's scribe: kbabbitt
CSS Shapes
==========
FPWD of css-shapes-2 or porting shape() to css-shapes-1
-------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6900#issuecomment-2930919526
noamr: Time for a WD that includes the shape() function
noamr: There are other things in shapes-2 that are not ready for WD,
so proposal is to move shape() to css-shapes-1 and publish a
WD of that
noamr: Then it can live happily with the rest of the basic shapes
fantasai: Seems reasonable
fantasai: Shapes 1 is currently CR
fantasai: by moving it in maybe it will get published
fantasai: probably want to publish WD in ?? review
fantasai: try to move it back into CR
ChrisL: Want to drop from CR?
fantasai: Adding new feature, seems appropriate
astearns: Didn't drop for path()
astearns: but either way is fine by me
ChrisL: Dropping the whole draft to WD is a signal we don't want to
send, but it is a new feature
astearns: Can we put the feature in and ask for wide review just the
new feature?
ChrisL: Would be fine
fantasai: I think we can do that
astearns: Move shape() to css-shapes-1 and when ready ask for wide
review on that and maybe path()
astearns: any objections?
RESOLVED: Move shape() to css-shapes-1 and ask for wide review on
that and maybe path() and add noamr as editor to
css-shapes-1
Scroll Anchoring
================
anchoring within contenteditable elements
-----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11748
vmpstr: For scroll anchoring we have priority candidates
vmpstr: Here there are two, which are [missed]
vmpstr: Algorithm says if one of the candidates are viable, keep it
stable within the viewport
vmpstr: viability includes intersecting viewport, among other
conditions
vmpstr: There was a case with a large div with editable content
vmpstr: algorithm takes the whole element as the anchor
vmpstr: If content is inserted higher in the element, and cursor is
lower, then the whole element starts shifting around because
the whole element is the anchor
vmpstr: I'll discuss some of the solutions proposed
vmpstr: One is to change the algorithm to say, instead of just
picking the priority candidate as the candidate, pick it as
the starting point from which we run the rest of the algorithm
vmpstr: the rest of the algorithm picks the first fully visible thing
on the screen
vmpstr: So you would ...
vmpstr: For small elements like text boxes, there's no effect
vmpstr: for contenteditable, it means the content actually on screen
is anchored
vmpstr: as if the content editable element was not focused
vmpstr: That's what I'm proposing, and I think it's a fairly small
change
vmpstr: Rob proposed instead to anchor to the cursor whenever we have
that on the screen
vmpstr: There are cases where that's better, e.g. inserting an image
and want cursor to stay in place
vmpstr: I tried prototyping, but lots of cases where it looks weird
vmpstr: e.g. the document starts scrolling to make the cursor stay in
place
vmpstr: so not saying we shouldn't do that, but maybe we treat this
as two separate issues
vmpstr: and fix the priority candidate issue first, and then see if
we want cursor as another priority candidate
astearns: First solution, said that for small elements no effect
astearns: but if you are starting at and then looking down into its
children to see which element is the first one that is
fully in view, and the element itself is slightly off-screen
astearns: are we going to be changing the anchor selection there,
where we aren't going to take something that doesn't have
any of its elements fully on screen?
vmpstr: Algo is more sophisticated than what I descried. It does pick
first element that intersects viewport, but searches further
for fully on screen
vmpstr: if no such element, takes the partial one
flackr: I do think that what Vlad is proposing here is an improvement
flackr: I'm surprised we don't choose focused elements that are not
contenteditable as priority candidates
flackr: but for contenteditable, there is a strong expectation that
you continue to see the cursor
flackr: the weirdness that Vlad saw seems like a weirdness we could
address
flackr: but happy to take Vlad's solution for now and iterate later
fantasai: Want to make sure I understood
fantasai: If contenteditable is the primary candidate then we
fantasai: I think if we have contenteditable and ?? then scope to
contenteditable element
[agreement that this is the desired algo]
dholbert: Does this account for if the contenteditable is off-screen,
e.g. picked a field at top of article, and then scrolled
down and reading the article
vmpstr: We only pick a candidate that's viable, which includes
intersection with the viewport
smfr: Your contenteditable might just contain a wall of text, no
elements. Then how do you keep the insertion point in view?
vmpstr: It would be no worse than today, where whole contenteditable
is anchored
vmpstr: that might be better addressed by anchoring to the cursor
smfr: I think we do need to solve that
flackr: Happy to open up a separate issue to anchor to the cursor
flackr: Would love to look into those degenerate cases, I think they
can be fixed
smfr: Is the scroll anchoring algo triggered by typing, or by content
changes elsewhere?
vmpstr: Some affordances to user interaction, e.g. if user action
causes a change then algorithm wouldn't trigger in the
same way
vmpstr: this is my understanding, but not sure
vmpstr: so typing would be a part of user action, not included
smfr: Maintaining visibility of insertion point is finely tuned, and
don't want scroll anchoring messing with it
vmpstr: Agreed
astearns: I think resolution is minor improvement, where if
contenteditable has focus and is viable anchor, we will run
anchor selection scoped to that contenteditable element
vmpstr: If there is a viable priority candidate, then run selection
algorithm scoped to that priority candidate
astearns: So not limited to contenteditable
vmpstr: Right, other priority candidates include find-in-page
selection
astearns: and flackr will post an issue wrt active cursors
PROPOSED: When selecting a viable priority candidate (e.g.
contenteditable), run the regular selection algorithm
scoped to that element instead.
RESOLVED: When selecting a viable priority candidate (e.g.
contenteditable), run the regular selection algorithm
scoped to that element instead.
CSS UI
======
Add "show interest" and "lose interest" hover delays to CSS
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9236
masonf: This relates to the interesttarget HTML feature, which is
about hover triggering, longpress triggering, etc.
masonf: For both mouse and keyboard, there's a need for a delay,
between trigger and causing the popover to show
masonf: We've discussed a few times before
masonf: Current proposal is to have longhands and shorthand
masonf: for setting show and hide delays separately
masonf: That feels decided, but some open questions
masonf: One is naming -- current is interest-target-show-delay
masonf: it's kinda long, and maybe needs to be more general than
about this attribute
masonf: There's also a desire to have different delays for e.g. hover
vs focus
masonf: most natural way seems to be two values, but that's a question
masonf: third one is about defaults
masonf: some discussion about wanting show delay to be zero so it's
immediate
masonf: certainly for debugging it's easier, you can add delay if
it's too fast
masonf: but for hide, desire to be slower, because you need time to
move from target to popover without dismissing the popover
masonf: also desire for keywords like 'normal' to set values if you
don't particularly care
masonf: so interested in feedback
flackr: wrt naming, could just consider interest-delay*
flackr: could be interest-delay-start / interest-delay-end as
longhands
flackr: wrt defaults, I'd like to align with platform features that
have same intended use case
flackr: but maybe that's hard
TabAtkins: Don't have a strong opinion about names
TabAtkins: for delays, going with 'normal' and recommend that to
match platform conventions
TabAtkins: nonzero for exit
TabAtkins: Wrt different delays for different modes, could extend in
the future
TabAtkins: can make those a comma-separated list of category and delay
masonf: I agree about different delays being extensible
masonf: but what about shorthand, since it has two values
TabAtkins: Give it a specialty syntax branch for setting all value,
and different syntax for comma-separated stuff
smfr: Wanted to bring up matching platform behavior, flackr brought
up, it's important
smfr: I think people with movement disorders, these delays are very
important, so I think we should get accessibility review
smfr: We should allow platform settings to impact these values,
unsure about details
smfr: and I'm concerned about web authors making content inaccessible
because they choose values that are too short for some users
masonf: +1 to accessibility review
masonf: but last one was discussed in list -- even if author has
provided specific values, browser would be able to multiply
the value or impose a minimum delay
fantasai: For TabAtkins comment about shorthand, the way we combine
lists ... if we go with list syntax we would just have both
values and comma separator
fantasai: not a problem re: making a shorthand
fantasai: Regarding should we have 2 different values or not - I
think we might need to
fantasai: We should probably ask a11y review folks to answer the
question of whether we need that
fantasai: Delays for different types of interactions
fantasai: For the normal value - I think it seems like there's going
to be at least 2 different concepts of normal you'd want to
convey
fantasai: one being I have a popup menu of something which is
immediate, and other would be on-hover menu
fantasai: a tooltip menu
fantasai: a tooltip is not instant and shouldn't be instant
fantasai: 2 categories: things that should be instant and things that
should only come up on a delay
fantasai: so we might want 2 different keywords for that purpose
fantasai: if not more
flackr: Unfortunately I think the way we're handling this for touch
doesn't match the expectations for instant, e.g. for
long-press on touch, that doesn't match the menu case of "I
want to access a submenu". Maybe it's a different feature
flackr: The whole interest concept seems to be designed around
tooltip case, rather than menu case
fantasai: In that case initial delay of 0 is not the right thing,
right?
flackr: I agree? :)
masonf: The menu use case is different... this feature is definitely
focused more on hovercards and tooltips, so that's definitely
a question
masonf: To address a few things I heard, I think normal can pretty
easily address fantasai's last comment wrt hovercard vs
tooltip
masonf: We already have different behavior -- called plain tooltips
and rich tooltips
masonf: hovercard vs tooltip
masonf: we could very easily key off of that, and set delays
appropriately
masonf: Wanted to ask follow-up question -- normal or auto?
<TabAtkins> +1 to normal
<TabAtkins> this isn't computed based on other styles, which is what
we usually use "auto" for
<TabAtkins> normal being "platform defaults" is consistent with our
usual usage
<fantasai> +1 TabAtkins
fantasai: Would probably go with normal assuming this is something
you expect to be normal
fantasai: if this is the normal delay, calling it normal makes sense
astearns: I think normal could handle different delays depending on
context, and then authors have tools to set specific delays
if they want something different
ydaniv: Agree with flackr wrt menus, but also they usually have
non-zero end delays
ydaniv: different use case
ydaniv: one thing mentioned was keyboard and mouse, not so much mouse
as much as hover
ydaniv: with touch there's usually expectation for much shorter
delays, unless doing longpress
masonf: The names mouse and keyboard aren't in the name, they're
positions in the list
masonf: longpress is operating-system defined, don't want it to get
in the way of it
masonf: Wanted to see if we could get resolutions ...
masonf: didn't talk much about naming, maybe get resolutions on that
and normal default value?
<masonf> interest-hide-delay interest-show-delay and interest-delay
astearns: interest-show-delay + interest-hide-delay = interest-delay?
fantasai: normally we have the shorthand be a prefix of the longhand
rather than other way around
fantasai: though it sounds a bit awkward
masonf: interest-delay-show?
flackr: interest-delay-start/interest-delay-end
RESOLVED: Define shorthand interest-delay for interest-delay-start +
interest-delay-end
astearns: Proposed to add a normal keyword to match platform
conventions
masonf: What would the spec say?
astearns: Can we say that it matches normal platform conventions, but
has a minimum delay for exit if the platform convention
does not?
masonf: There are some cases where you want instant
astearns: I think we can say it matches platform conventions, but I'd
like a little bit of investigation as to what those
conventions are
astearns: and if they are configurations by the user
astearns: just to know what we're linking up to
kbabbitt: I'm wondering if in appearance:base we want to define
consistent values for all UAs, not sure
fantasai: I think no
masonf: None of the built-in controls have a hover triggered thing
fantasai: appearance:base is largely about appearance, don't think it
should interfere with interaction modes
fantasai: most people care about it looking the way they want
masonf: Would agree with that as well
kbabbitt: That's fine
RESOLVED: Add a normal keyword as initial value to match platform
conventions
masonf: Last question was about whether to have one or multiple
delays for different modes
astearns: Since we do have an easy extension point, I would prefer to
have the single pair of values for now
astearns: and then if we determine that's not viable first step, then
we can add
masonf: I think I agree as well, because in single value we'll get
more info on use cases for different modes
fantasai: I think that it's fine to start with spec like this
fantasai: I think we should do a11y review before we decide it's what
we want to settle on
fantasai: syntax is extensible but if we decide we need 2 categories
with different defaults
fantasai: that's a behavior change we'd need to know about up front
fantasai: if people think getting existing default is resonable
that's fine, if not we need something else
fantasai: [missed]
fantasai: but we should definitely get that review and investigation
fantasai: before we decide this is a good first level
astearns: Let's add a note to the spec that we're considering have
separate settings for e.g. keyboard/touch to make sure
that's part of any review that this feature gets
PROPOSED: Start with single value, add a note about possibility of
needing alternative values for e.g. keyboard/touch
RESOLVED: Start with single value, add a note about possibility of
needing alternative values for e.g. keyboard/touch
CSS Color
=========
What if gradients with legacy colors *also* interpolated in Oklab
by default?
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7948
ChrisL: Unfortunate situation that we took a resolution, but no
browsers updated and WPTs test the current behavior
ChrisL: Two options
<jensimmons> What is the "reasonable proposal"?
<jensimmons> Can you summarize?
ChrisL: 1. we get implementers to say they're interested in doing
this -- because so far we get people who are not happy with
the proposed behavior
ChrisL: 2. we revert the resolution to match implementations and WPT
ChrisL: The thing we already have agreement on, and spec said for 18
months, is that all interpolation happens in OKLab unless you
override
ChrisL: this means all interpolation changes, possibly for the
better, but in any case it changes
ChrisL: I'd like us to either really do that, or really not do it
weinig: Implementing what's in the spec is easy. Most browser add
additional checks for new vs old colors.
weinig: One challenge is that it will be a perf regression, at least
for WebKit, to use OKL, since sRGB is much more optimized
weinig: so gradients will regress a little bit without special
graphics backend. So that's one concern.
weinig: Another concern is changing websites
weinig: That might be OK, but a bit hesitant to change all gradients
that have ever existed on the Web
smfr: Agree with Sam's performance concerns, and concern wrt legacy
behavior
smfr: Especially those that expect pixel-perfect behavior
smfr: e.g. iCloud docs
smfr: so I think this does need to be opt in
weinig: No gradient will ever be pixel perfect, because by definition
have dithering
weinig: but intention perfect
weinig: keynote document on mac, gradient renders different on mac
and on web because we change interpolation
weinig: that would be unfortunate
ydaniv: Although this is probably for the best, things like this
could trigger CI failing when they update browser versions
and suddenly screenshots and test tooling break randomly
everywhere there's a gradient
ydaniv: I'm not sure how much that is a problem
ydaniv: sometimes happens because things change, but something to note
weinig: Because gradients are this weird thing, they already break
screenshot-based CI because they often have random or
hardwired-specific dithering
weinig: so all the places where could change, this is one with
wiggle room
weinig: so if people have error bars, this might expand past
<TabAtkins> Tho, again, screenshot tools that allow specifying
color-shift bounds can work fine with dithering, but
won't work with changing the interpolation space.
<TabAtkins> WPT, for example, lets you specify that pixels can be
within an RGB unit or two of the reference.
lea: I've never seen gradients that expect pixel perfect rendering
really use sRGB. Even before in oklab was an option, they'd
insert intermediate color stops to control interpolation, so the
difference would be minimal.
lea: designers who want that insert color stops to ensure the
interpolation curve
jensimmons: I was surprised to hear that we decided to change default
color space for gradients
jensimmons: Surely there are designers and developers who don't care
that much
jensimmons: also user gets new device, renders differently, or uses
new browser
jensimmons: but certainly many designers obsess over the details and
spent hours choosing the gradient ...
jensimmons: seems like CSSWG typically doesn't change out from how
web works
jensimmons: so was surprised about resolution. Don't know if it's a
good idea or not.
astearns: We resolved on this because it seemed like an improvement
that could be ok with web-compat
astearns: but new behavior is fully accessible as an opt-in, right?
astearns: so we should probably resolve to revert this decision
<smfr> I tested Keynote on the web. It happens to use SVG, so it has
an SVG gradient, but with just 3 stops. If it had used CSS
this would have affected behavior
fantasai: I don't quite remember but is there a way for author to opt
in whole page at once?
ChrisL: Has to be each individual gradient
ChrisL: People keep suggesting it but folks say that wouldn't work
because...
fantasai: That means we don't have a proper opt-in
fantasai: requiring authors to do it for every gradient seems
obnoxious
fantasai: the improvement that's available is unlikely to be worth
that level of effort
ChrisL: The gradients they can opt in are ... the ones that work how
they want, they don't have to do anything with
fantasai: If we think this is an improvement for all gradients, we
should make it easy for authors to opt in
lea: We can still have a global setting. Having different
interpolation spaces for different use cases is possible, just
not a single property with a single value
florian: I don't have statistics, but the point made by Lea makes
sense to me
florian: People who obsess over their gradients would use
intermediary color stops, and would therefore be minimally
affected by this
florian: On the other hand, argument from smfr about having things on
and off the web look the same in both cases ...
<smfr> I just disproved that apps add lots of color stops to control
the rendering
dbaron: wrt global opt-in, if we thought global behavior change was
good, then having global opt-in would make sense
ChrisL: global being problem was about all types of interpolation
<lea> e.g. color-interpolation-gradient
<florian> +1 to dbaron
lea, dbaron: we could have a global opt in that only affects gradients
astearns: Should we resolve to revert?
ChrisL: I'd like to discuss an additional point next week
astearns: Ok, let's do that and then continue with this discussion
astearns: proposed that we revert the change that says that gradients
interpolate in OKL by default. Any objections?
RESOLVED: Revert change to make all gradients interpolate in OKL by
default
Received on Thursday, 5 June 2025 00:01:49 UTC