=========================================
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
---------
- The group discussed the possible ways to address the fingerprinting
issue raised in issue #10372 (Mitigating fingerprinting for
AccentColor/AccentColorText)
- A focus of the conversation was if tainting the color so it
paints correctly but doesn't return an exact value could
address this issue. The potential path forward would be
tainting by propagating a computed color plus an additional
bit.
- Concerns were expressed that if the group couldn't figure out
how to get AccentColor/AccentColorText to paint correctly
then the feature itself would not have value.
CSS Conditional
---------------
- RESOLVED: Change 'direction' to 'scrolled', discuss keywords later
(Issue #12623: Disambiguate scrollable/direction when
along axis/towards edge)
Web Animations/CSS Animations
-----------------------------
- There wasn't disagreement with the proposal raised in issue #12652
(animation-trigger CSS syntax) to have the event or action be
optional in the new trigger() property. However, there was still
a lot of discussion on the broader syntax and bikeshedding so a
resolution on this specific question felt premature.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2025Sep/0005.html
Present:
Rossen Atanassov
David Awogbemila
Kevin Babbitt
David Baron
Kurt Catti-Schmidt
Yehonatan Daniv
Elika Etemad
Robert Flack
Mason Freed
Hoch Hochkeppel
Brian Kardell
Jonathan Kew
Alexander Kyereboah
Chris Lilley
Alison Maher
David Marland
Romain Menke
Florian Rivoal
Noam Rosenthal
Alan Stearns
Miriam Suzanne
Josh Tomath
Munira Tursunova
Bramus Van Damme
Lea Verou
Luke Warlow
Sam Weinig
Jason Williams
Regrets:
Oriol Brufau
Emilio Cobos Ãlvarez
Roman Komarov
Sebastian Zartner
Scribe: fantasai
Scribe's scribe: noamr
CSS Color
=========
Mitigating fingerprinting for AccentColor/AccentColorText
---------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10372
kyerebo: Issue is, we have AccentColor styling for setting form
controls
kyerebo: accent-color: auto uses the system accent color
kyerebo: Recently trying to ship AccentColor keyword, should respond
to system color
kyerebo: But keyword, because values can be computed and used by
script, there was a privacy issue
kyerebo: We can't be exposing this for accent-color: auto
kyerebo: Considering mitigations in Chromium, such as limiting to
installed web apps
kyerebo: But problem is that authors may expect them to resolve to
the same value
kyerebo: Should we also restrict `accent-color: auto` then?
kyerebo: That's the question.
<ChrisL> Authors would be astonished if they resolved differently, I
think
kyerebo: If we don't restrict it, then `accent-color: auto` will use
a different value than AccentColor
kyerebo: which would return a system default
kyerebo: But if we do restrict it, then a regression of sorts because
web apps can no longer match the system accent color
weinig: Did we investigate tainting for colors, similar to images?
weinig: So that if the color is e.g. mixed or whatever, would taint
the mixed value
weinig: And tainted value would not be discernible from script
weinig: One way to do that would be providing a fake value
weinig: but would need more complex due to things like color-mix() or
canvas().
weinig: If you use tainted AccentColor with canvas, can no longer
read the bits
weinig: This is what we do with origin-tainted images
kyerebo: We did consider returning a different value than what is used
kyerebo: but we resolved previously that system colors should compute
to themselves
weinig: Problem is that colors these days don't exist in a vacuum
weinig: you can have color-mix() or relative colors, or use colors in
<canvas>
weinig: Would have to consider all of these together
lwarlow: My thoughts on this are that, if we can't expose the system
accent color because fingerprinting is too bad
lwarlow: I don't think that should result in accent-color: auto being
less capable
<dbaron> +1 to lwarlow
lwarlow: Realistically, if approach is "provide a fake color, always
use blue", we might as well not ship accentcolor
lwarlow: Exposing a system color and then never making it do the
thing it's meant to do seems wrong.
lwarlow: On the other side of things, in an ideal world, rather than
make it lie, would make it paint correctly and do some kind
of tainting to not expose the color
lwarlow: There's still -webkit-focus-ring which exposes this color in
Chrome on MacOS
lwarlow: If we go down the "don't expose these colors", then we need
to actually follow through on that.
alisonmaher: I believe we did roll that back on Chromium.
alisonmaher: so that it's no longer exposed.
lea: Tainting is not that simple, because not color itself, but
color-mix(), color-extract(), relative colors
lea: color-extract() lets you grab a color component and use it in
e.g. variables etc.
lea: I don't have a strong opinion on what to do, but
lea: having accent-color use one color and AccentColor another, this
is bad
lea: I think it's ok if exposed in some contexts and not others, as
long as page has one accentColor
lea: What if it's UA *MAY* expose the accent color or system color?
lea: But should be hard requirement that these are the same color
lea: less critical for canvas. Most UI doesn't combine canvas and CSS.
lea: but between built-in components and web components, should be
able to depend on accent color being the same
lea: Also, wrt can we just not expose as a system color
lea: built-ins also need to access it through appearance:base. Their
style needs to be expressible in CSS.
dbaron: My read of current situation is that computed values of
system colors compute to color values.
dbaron: we didn't have to do it that way, but been that way for a
long time
dbaron: also means that tainting is easier to implement and describe,
but also more destructive
dbaron: if what we're tainting is a computed value that's just a
color, then what you're propagating is a color + flag about
whether it's tainted
dbaron: One of the problems there is that you can't expose anything
useful in getComputedStyle()
dbaron: I see the problem with both main alternatives brought up
originally
dbaron: It's bad to break existing accent-color: auto; feature but
also the inconsistency is bad
dbaron: We could have had alternative path of storing system colors
as system color keywords. That would have made tainting more
complicated but more useful.
<alisonmaher> This was the original issue that was discussed:
https://github.com/w3c/csswg-drafts/issues/5710
florian: This exact problem is why I pushed back against accent-color
property affecting AccentColor keyword
florian: because it makes it more desirable to use it more often
florian: In some browsers, the color you see is different from
AccentColor
florian: I think dbaron's suggestion about tainting by propagating a
computed color plus an additional bit is the most promising
path forward -- just saying you don't use the system accent
color at all is probably not reasonable, even though it
would bring consistency
dholbert: Premise is that developers shouldn't use accent color or
read it
dholbert: If you're using the color, and user has similar shade of
blue, maybe you want a different color for some other
purpose so you don't have unreadable content
dholbert: There are good reasons to have this info
lwarlow: Is it actually really that big of a deal if the accentColor
keyword doesn't match what color the system colors render
with?
lwarlow: That's status quo
lwarlow: For appearance:auto, browsers can do whatever they want
anyway
lwarlow: If they really wanted consistency, they could just set
accent-color and then they'll match
lwarlow: Status quo is that it doesn't match. I don't think we should
expose it if it doesn't match.
lwarlow: wrt not exposing due to appearance: base ... ideally all
those styles should be explainable with CSS
lwarlow: but could it resolve when it's in a UA stylesheet and not in
author style sheet?
lwarlow: Though currently no appearance:base style uses AccentColor
anyway
weinig: I really think that coming up with some definition, probably
in a color spec, of codifying concept of a tainted color and
how it behaves is the way forward
weinig: I don't expect this to be the last time we run into this
weinig: wrt existing system colors resolving to a specific rgb value,
those system colors are deprecated because of that behavior
weinig: maybe the right way forward is to come up with a function
that always has a tainting behavior, for things that actually
want to match the system
weinig: and the absolutely-resolving system colors can just be legacy
behavior
weinig: But experiment of having color + taint bit is a good
experiment to see what the cost would be
weinig: that's the only solution if we actually want to match system
colors anywhere
<dbaron> (curious if weinig was proposing that the "new" system color
type would be part of the computed value -- that's also a
bit more complicated since it requires that multiple other
things that contain color values be part of the computed
value representation -- which I think they don't have to
today)
lea: wrt status quo, AccentColor wasn't broadly supported so not much
status quo
lea: Multiple accent colors would be unacceptable to authors
lea: they'd have to set accent-color as a boilerplate always
lea: But you'd need to taint not just colors but also other things
given color-extract()
lea: could make it not-tainted in certain contexts, e.g. installed
web apps
lea: authors should be able to detect if a value is tainted
lea: and there should be a reasonable default behavior
lea: for where breakage could make things unreadable
fantasai: A reason why the resolve to absolute is to avoid the
complexity of maintaining all the channels of color, when
mixing them
fantasai: very similar to currentcolor
fantasai: this was for simplicity of implementation, not having to
maintain channels
<ChrisL> Yes that was exactly the reason
<weinig> I think we have gone way past that complexity at this point
fantasai: in terms of default, if we were going to paint it it should
have a default (blue or other)
<lwarlow> +1
fantasai: we shouldn't taint derived numbers; if someone does
something complicated they should use a real color and not
a tainted system color
<lea> just to reply to fantasai re: doing weird things: the primary
value of accentcolor is for different parties to communicate.
If you can handshake, you can just use a CSS variable. So the
web component doing "weird things" does not control the
page-level accent color
Rossen: Time to switch topics. Next steps is continue engage on the
issue
CSS Conditional
===============
Disambiguate scrollable/direction when along axis/towards edge
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12623
noamr: We're currently using `scrollable` to say having the ability
to scroll vertically or horizontally
noamr: and then we are using `direction` for most recent scrolling
direction
noamr: It felt that something was not totally finished in the naming
noamr: There's a few suggestions in the issue
noamr: Not super opinionated, but needs some work
fantasai: miriam has suggested "scrolling" and "scrollable"; I think
it kind of works
fantasai: if it's now vs. recent if can be scrolling/scrolled
fantasai: keywords for the scrolling direction can also use forward/
backwards rather than x/y, or up/down/left/right rather
than edges
moonira: Just saw your comment, you mentioned scrollable as having
none | x | y | block | inline
moonira: Do you mean changing those values as well, and remove values
like top/bottom/etc?
fantasai: Wasn't clear to me from Noam's comment about whether we
were including the sides or not
moonira: Scrollable is shipped, so prefer not to change that one, but
for direction sounds great
moonira: If everyone is ok with Elika's proposal, can we decide to go
with `scrolled` for last direction and use the keywords from
that proposal?
<flackr> fantasai's proposal sgtm
moonira: Just want to make some progress here
<noamr> +1 to scrolled
Rossen: Any additional opinions, or should we go with `scrolled` for
last direction and keywords from the proposal?
<JoshT> +1
<fantasai> 'x-forward' vs 'x forward'
<fantasai> which style do we want?
fantasai: there were independent proposals; up/down/left/right
doesn't embed a direction but back/forward doesn't
flackr: what's that?
fantasai: physical axis with logical direction
fantasai: we do this for position-area, background-position
fantasai: the q is whether to have it space separated or hyphenated
<flackr> I like hyphenated because up/right/down/left already have
axis in them
<Rossen> x-scroll would be closer to overflow-x
fantasai: question is whether to use pre-combined hyphenated or
combinable space-separated
miriam: Haven't thought through it, but prefer space-separated
combinable
<djmarland> What would "left backward" do?
noamr: I suggest we resolve on `scrolled` as the descriptor, and we
can ponder the additional keywords
PROPOSED: Change 'direction' to 'scrolled', discuss keywords later
RESOLVED: Change 'direction' to 'scrolled', discuss keywords later
fantasai: Ok, let's come back to that though. It's confusing about
whether scrolling towards or from the specified edge, so I
think directional keywords would be better (in one form or
another)
Web Animations/CSS Animations
=============================
animation-trigger CSS syntax
----------------------------
github: https://github.com/w3c/csswg-drafts/issues/12652
DavidA: At the F2F, we discussed the syntax for animation-trigger,
and we came up with a trigger() function
DavidA: accepts name of the trigger, triggering action/event, and the
behavior triggered
DavidA: But some concerns about expressing the action there
DavidA: what we came up with was rather than having 3 parameters, we
make the event or action optional, and then you only have to
specify the name of the trigger and the resulting behavior
DavidA: one of the changes is, previous proposal used high-level
names, apart from name of trigger could give a set of names
local to that trigger
DavidA: which the animation-trigger can refer to
DavidA: Dropping that high-level name as well
DavidA: When you omit the event from the trigger function parameter,
then the behavior specified is associated with all the
actions or events that were specified on the trigger
DavidA: So, proposal we look to get on today is making that event
parameter optional
DavidA: Some more recent comments on issue
DavidA: wrt specifying events on the user of the trigger
DavidA: I think this change goes a little bit more in that direction,
because it makes the event optional
DavidA: Author can define event on the trigger and just associate
with the target
DavidA: exception to that is, with exit action or event of the
timeline trigger
DavidA: which is main difference between an event trigger and a
timeline trigger
DavidA: we think that treating that exit action as part of special
case is good, reflects how timeline triggers are different
from event triggers
fantasai: I agree, making the event optional helps us go in that
direction
fantasai: the timeline trigger and event triggers have more
similarities than we think
fantasai: a timeline has a concept of entering/exiting. some DOM
events have the same pairing, like key/mouse/focus
fantasai: in/out relationship between a bunch of event pairs
fantasai: "it starts animating when hovering and stops animating when
no longer hovering"
fantasai: this should be very similar to timeline triggers.
fantasai: no objection to making events optional but concerns about
overall design
DavidA: You still get ease of expressing that in this case
DavidA: Let's say for a mouse over vs mouse out
DavidA: You would simply be able to define two triggers on a source
element, and name one of them --mouse-over and the other
--mouse-out
DavidA: and on the target you would specify the behavior by binding
--mouse-over and --mouse-out to start and end animations
DavidA: Making a comparison to you and Tab's original proposal, you
specify roughly the same thing
DavidA: We wouldn't assume that because you specify mouse out also do
something on mouse over
DavidA: So I think we're still making it as easy to describe that
case, but without forcing a start and end concept on event
triggers
DavidA: that fundamentally applies to timeline triggers, but not
necessarily to event triggers
ydaniv: I agree with fantasai that timeline trigger is something
important, and usage should be trivial and important to solve
ydaniv: specifically view timelines
ydaniv: something that we don't want to over-complicate, and make it
trivial to get right
ydaniv: I had some concerns in the issue about event triggers but
also timeline triggers
ydaniv: I also don't understand why we expose enter and exit there,
and have 3 arguments for timeline triggers and 2 for event
triggers
ydaniv: seems like something to resolve before we agree on it
ydaniv: I had another proposal
[tries to find it]
ydaniv: Something proposed before by flackr, that we use something
like event-trigger function and timeline-trigger function,
instead of generic trigger function
ydaniv: then each can have its own arguments
ydaniv: I had some suggestions about event trigger
ydaniv: first of all, event-trigger should only take name and list of
events
ydaniv: what fantasai says, that some of them are paired, like
pointer enter and leave
ydaniv: we should probably somehow generalize that into either
higher-level events or generalize the usage inside the
trigger somehow
ydaniv: regarding timeline triggers, I suggested also using only two
arguments so that you only reference a name and give it a
behavior
ydaniv: if you want exit behavior, separate with a slash
ydaniv: I didn't see any specific comment about whether this is
something acceptable or not
ydaniv: but I do want to make it easier than exposing enter and exit,
where you can specify something that doesn't make any sense
ydaniv: enter-pause, and exit-reset, I don't think there's any use
case for it
<flackr> I don't think that we should actively try to avoid allowing
specifying things that don't make sense, we should prefer to
keep the model as simple as possible
<ydaniv> my proposal:
https://github.com/w3c/csswg-drafts/issues/12652#issuecomment-3228775877
DavidA: Having event-trigger and timeline-trigger have different
number of args ... we're trying to keep the syntax the same
DavidA: You just write the name of the trigger and the behavior
DavidA: In the exit case, you have to specify exit events
DavidA: that's an opposite of enter, that's a weird thing about
timeline triggers
DavidA: whereas for events, they are each independent conceptually
DavidA: One thing about a trigger function now, instead of
event-specific or timeline-specific
DavidA: we can always add a more specific trigger function
DavidA: having trigger() doesn't prevent that
ydaniv: I agree it doesn't prevent it, but I think if we do have a
single generic function, it should be done right.
ydaniv: current proposal, I see stuff that is a bit funky to me
DavidA: other point, this thing about pairing behaviors that don't
make sense
DavidA: you wouldn't have an incentive to do it
DavidA: you can always write nonsensical things in JS
DavidA: I don't see that as a drawback of this proposal
DavidA: Even writing something like enter pause, exit reset
DavidA: Maybe one of the things in Tab and fantasai's original
proposal, mixing timeline and event triggers
DavidA: that's one thing we get from this
DavidA: with behaviors we want to specify, not every combination
makes sense
DavidA: but not incentivized to combine random things
flackr: Listening to this discussion, one idea was maybe both event
triggers and timeline triggers could have concept of entering
and exiting
flackr: so animation syntax would always have enter and exit action
flackr: event triggers that only specify enter actions never remain
active, so they can trigger multiple times
flackr: I should probably write this up more formally, but that might
help these two things look the same
<fantasai> +1 flackr
<ydaniv> to flackr, that could work, we had such tries before
astearns: Is it possible to resolve to make the action parameter
optional?
flackr: I think we're still bikeshedding the whole thing :)
astearns: ok, let's take back to the issue.
astearns: Breakout on Friday for snapshot issue, and another breakout
next week on values
astearns: please come if interested, and please do put your
availability into the Winter F2F poll at
https://app.rallly.co/poll/JVvrK6xuIeIK
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4