- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 19 Mar 2025 20:16:39 -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.
=========================================
FPWD of Forms
-------------
- RESOLVED: Publish FPWD of CSS Forms
CSS Conditional
---------------
- RESOLVED: Editors will figure out how to fix the OM to match the
new behavior, and bring it back to the group for review
(Issue #10845: `CSSContainerRule.containerName`/
`containerQuery` should return a list)
CSS Scoping
-----------
- RESOLVED: Drop `:host-context()` (Issue #1914: Dynamic changes of
state and attributes referenced by :host-context rules
are pretty hard to handle efficiently)
CSS Values
----------
- RESOLVED: Accept the epsilon proposal, with follow-up refinements
as needed (Issue #11864: Make UA, not author, deal with
floating point errors in random())
- The folks on the call were leaning toward accepting the proposal
for issue #11742 (Maybe min, max and step should not be part of
the random-caching-key), however they wanted more time to discuss
the concerns in the issue.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2025Mar/0019.html
Present:
Rachel Andrew
Tab Atkins-Bittner
Kevin Babbitt
David Baron
Keith Cirkel
Elika Etemad
Robert Flack
Simon Fraser
Paul Grenier
Daniel Holbert
Roman Komarov
Vladimir Levin
Alison Maher
Tim Nguyen
Florian Rivoal
Gaurav Singh Faujdar
Alan Stearns
Miriam Suzanne
Bramus Van Damme
Samuel Weinig
Regrets:
Oriol Brufau
Chris Lilley
Lea Verou
Scribe: TabAtkins
FPWD of Forms
=============
github: https://github.com/w3c/csswg-drafts/issues/6900#issuecomment-2715192840
ntim: I'd like to request FPWD of Forms
ntim: currently an unofficial draft, would like to get ball rolling
ntim: the current draft defines appearance:base, and a set of
pseudo-elements for form controls
ntim: a few more things for form control styling
ntim: this has been discussed in the joint openui/csswg meetings
astearns: There are a bunch of open issues, so clearly people are
interested
astearns: Are there also pending PRs?
ntim: Yes, I've approved most of them. currently one left open, I
think
astearns: So your intent is to merge everything we've got in the
pipeline before fpwd?
ntim: Not necessarily
astearns: I'd like to get some more co-editors to help out
astearns: Would you prefer that before fpwd, or after?
ntim: After
astearns: K, I'll plan to do that right after fpwd
<TabAtkins> no questions, spec looks reasonable for an early fpwd
??: can someone remind me about the process? what does being a WD do?
astearns: A FPWD is our intent to work on this. IPR becomes an issue
for merging things into an official FPWD, as opposed to an
editor's draft that hasn't been adopted yet.
florian: Yeah, until it's a WD of some kind (including FPWD) it's not
actually a deliverable for the group, this is the official
start
florian: As mentioned, this has patent implications, W3C patent rules
start applying to WD, not EDs
florian: Member companies don't need to license things just because
we start publishing, but they do need to start paying
attention. Their lawyers will get a notification, because
eventually they'll need to license patents if they don't
object.
fantasai: The name is "first PUBLIC working draft"; in the past
editor's draft weren't public so this was the first that
was public
fantasai: In the interest of "release early, release often" we don't
want to wait for a polished spec, but want it up enough
that people know how the spec is going to go
fantasai: Major conflicts in underlying model, might want to delay
for a bit. Like in Variables, early on there were a lot of
possible directions and none of them caught traction.
fantasai: When we finally hit on the current model and it caught, we
finally made the FPWD for it
fantasai: so the point at which you're asking for feedback outside
the WD, that's when you should FPWD
florian: Other topic. I understand this is also supposed to take over
some parts of CSS UI 4
florian: Some issues in the spec asking about taking over bits
florian: I think we probably should, for most at least. Don't think
we need to solve those for fpwd, since the text is already
in a spec, but we should decide on which things move and
which things stay soonish.
florian: Happy to work with Tim to figure this out either before or
after fpwd, whatever's helpful
ntim: Let's do it after
ntim: I think it's weird to move something from a higher level spec
to an unofficial draft
florian: Sure, so FPWD to get the new stuff, then migrate once it's
official. Works for me.
fantasai: Some notes, FPWD patent stuff is like 90 days or 120 days
from the first public draft for the timer to kick in, so
even if you add stuff afterwards, it's as if it was in
the fpwd
fantasai: Also note, all Working Drafts have some degree of patent
protections, while none of our Editors Drafts do. so it's
actually important to publish your drafts.
astearns: Proposed resolution is to publish a FPWD of CSS Forms.
Objections?
RESOLVED: Publish FPWD of CSS Forms
CSS Conditional
===============
`CSSContainerRule.containerName`/`containerQuery` should return a list
----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10845
astearns: Miriam, this was months ago, but you put this on the agenda
last year
miriam: Okay, let's review...
miriam: We resolved earlier that a @container prelude could accept a
list of conditions, but we didn't update the CSSOM to return
a list
miriam: so the proposal is that CSSOM should reflect that list back
to us
astearns: It's mentioned that none of the impls do it yet
miriam: At least, last year, yes
astearns: So proposed resolution is to update CSSOM to match the
resolution?
miriam: yes
<kbabbitt> seems reasonable to me
emilio: Is the proposal to return a readonly sequence?
TabAtkins: I was thinking about that too. Either it's readonly, or it
could be settable but the list you get from the getter is
"dead", doesn't reflect back into the object if you mutate
astearns: I think Guillaume's PR doesn't mention the read/write
nature of the list
emilio: Some back compat too. for the single-condition case, it might
need to still return a string
astearns: Do you think it's reasoanble to resolve on returning the
list and find out if we have compat problems?
TabAtkins: if today we allow a comma-separated list, how is it
reflected? Just comma-separated list?
TabAtkins: if so it might be worth keeping the property alone
TabAtkins: and just have a function to get the listified version
miriam: Maybe more complicated, containerName wouldn't make sense if
it was returning the whole prelude
miriam: maybe nobody is using the feature yet?
TabAtkins: Propose we just resolve to fix, and let editors figure out
what it should look like
astearns: and who should edit it?
TabAtkins: miriam or emilio?
emilio: This sounds reasonable. Note that Firefox doesn't support
multiple conditions yet, so it's not an issue for us.
emilio: Maybe other browsers don't either, presumably they'd have run
into this containerName issue too
astearns: So proposed resolution is we'll accommodate our intent in
the CSSOM spec, but leave details to the editors to figure
out what is possible given the constraints
miriam: Can we get a little further? do we just have one property
that returns a list, or a string property plus a list
accessor?
astearns: I'd prefer only one, but I don't know if it's possible
emilio: I agree if we couldn't return a list...
emilio: but also the name is optional. if you have multiple container
conditions, what are the names...?
emilio: if you have three conditions, only the first and third have
a name...
TabAtkins: This is why I suggested leaving the details to the
editors, I think they'd be pretty obvious once you start
working it out
emilio: Yeah, we can try to sort it out and come back with a more
fleshed out proposal
miriam: Sure
astearns: So we're resolved to fix this, and bring the solution back
to the group
astearns: Objections?
RESOLVED: Editors will figure out how to fix the OM to match the new
behavior, and bring it back to the group for review
CSS Scoping
===========
scribe: emilio
scribe's scribe: fantasai
Dynamic changes of state and attributes referenced by :host-context
rules are pretty hard to handle efficiently
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1914
TabAtkins: emilio brought up the issue that `:host-context`
pseudo-class matches the host element inside a shadow
root, and it matches the host if any of the ancestors
match the compound
TabAtkins: intention was to solve some theming use cases (light/dark
mode etc)
TabAtkins: issue is that this is not very efficient, tree-crossing,
and invalidation is difficult
TabAtkins: Since then, most of the use cases can be replaced by style
queries (and better)
TabAtkins: e.g. instead of light / dark class, you can use it to set
a custom prop and use inheritance
TabAtkins: shadow tree can use a style query
TabAtkins: It handles scoping / don't have to worry about which one
is closer
TabAtkins: it pulls in the cost of the container query but avoids the
cost of cross-tree invalidations
TabAtkins: emilio and WebKit impl would prefer to remove host-context
TabAtkins: afaict it's only chrome
TabAtkins: This could be a compat issue for chrome, so fairly limited
TabAtkins: so I'm ok with dropping this given the powers CSS has now
TabAtkins: unless there's objections I'd be happy with a resolution
astearns: Do you think you'll be successful convincing Blink to
remove it?
TabAtkins: We shall see
TabAtkins: but at least it can be clear that it's chrome-only and not
intended to be implemented everywhere
keithamus: Is there a use counter?
TabAtkins: Not sure but that'd be the first step in our deprecation
process
<dbaron> use counter:
https://chromestatus.com/metrics/feature/timeline/popularity/470
astearns: Is there anything that host-context can be used for not
covered by container-style queries?
TabAtkins: The only difference is it switches who has control over
TabAtkins: that said you shouldn't be depending on details from the
outer tree if the outer tree isn't expecting it
TabAtkins: shouldn't really matter where the control lives
TabAtkins: but if the same person controls both sides, there's no
difference in abilities
TabAtkins: slowly trending upwards but given the numbers probably
possible to remove via a deprecation process
astearns: proposed resolution to drop `:host-context()`, objections?
<emilio> +1 :-)
RESOLVED: Drop `:host-context()`
CSS Values
==========
Make UA, not author, deal with floating point errors in random()
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11864
TabAtkins: `random()` has been getting some attention. Gets a numeric
range, with an optional step
TabAtkins: If you have 100, 200, 150 ... [missing]
TabAtkins: works fine with integer values, but not with floating
points
TabAtkins: because 0.1 * 3 is one step further than 0.3
TabAtkins: Exact details about the number system would expose this
sort of precision issues unpredictably
TabAtkins: even where these are consistent people get bit by this all
the time
TabAtkins: floating point math is hard
TabAtkins: various ways to get around
TabAtkins: An epsilon
TabAtkins: that's what we proposed adding
TabAtkins: Whenever you calculate the steps you calculate an epsilon
of 1/1000th of the step size
TabAtkins: as long as that's around the max we include it
TabAtkins: 1/1000 is more than large enough for any precision issues
but small enough to not triggering it accidentally
TabAtkins: authors might need to spell out 1.3333 to get reliably
TabAtkins: Unless any objections that's on the spec already
<iank> When you get to the extreme values doesn't floating-point go
outside the 1% range?
TabAtkins: Only when you get to extraordinarily extreme values
TabAtkins: not reasonable to be used in CSS
<iank> ok
TabAtkins: if you get beaten by it you're going to have problems
anyways
TabAtkins: even for 1M pixels you should be fine
weinig: If the only use case is evenly dividing ranges by a number
weinig: an alternative would be to have a keyword that specifies that
instead of a step size you specify the number of buckets
weinig: the impl then can do it for any value
weinig: barring that there's also a more classical, similar function
from TAOCP, using the ...
weinig: from "accuracy of floating point arithmetic" from TAOCP
weinig: I'll paste it in
TabAtkins: Certainly happy to defer to people that have thought more
about it
TabAtkins: certainly happy to about
weinig: The important bit is that the epsilon is not constant
TabAtkins: Don't want to force people to write a calc() to get the
right thing
TabAtkins: so it can also work with 1.3333 or so
weinig: I really worry about trying to invent our own thing
weinig: specially if a property has small numbers or ranges far away
from zero
weinig: so trying to find another solution seems wise here
TabAtkins: Re. your first question about dividing the range in
buckets, issue is usability
TabAtkins: in the abstract it's the same
TabAtkins: in practice knowing the number of buckets means range /
step size
TabAtkins: you have start and end, calculating the number of buckets
needs unit division
TabAtkins: inclined to avoid that one even it does solve the
fundamental issue
<weinig> The floating point comparison accuracy compare function from
Knuth is - Knuth, D. E. "Accuracy of Floating Point
Arithmetic." The Art of Computer Programming. 3rd ed. Vol.
2. Boston: Addison-Wesley, 1998. 229-45.
<weinig> (boost has a good write up,
https://www.boost.org/doc/libs/1_34_0/libs/test/doc/components/test_tools/floating_point_comparison.html)
emilio: Was going to suggest same as weining, can't you get around
the unit size with round() ... I guess it gets complicated if
you want to handle mixed units
emilio: but definitely annoying
TabAtkins: The atan() hack for stripping units is not great
fantasai: Wanted to say that the idea that I have four segments,
rather than step by 10px, is a different feature
fantasai: but not the same
fantasai: we should make the step size work in an intuitive way
fantasai: given the step size, if they're 0.1% to the end, it seems
we should use the end
fantasai: I think making the author deal with this by round() or so
is really hostile
fantasai: we should be handling that math for them
fantasai: only case where we might want to do the accuracy comparison
is if you don't have any step size indicated
fantasai: so I think Tab's proposal is the right way to go
fantasai: trying to just solve the floating point case is not a good
idea
<kizu> +1 to the proposal as well
dholbert: Regarding the 3.333 from 0 to 10, thinking about 6.66667
from 0 to 20
dholbert: seems this would introduce an arbitrary minimum amount of
precision
dholbert: to get the right result
dholbert: maybe seems slightly surprising that it automatically
starts rounding at a particular rounding of precision
dholbert: feels a bit magical
TabAtkins: You're right that you need at least 4 digits
dholbert: Maybe unavoidable
TabAtkins: Yeah, spec says to provide five digits of precision
intentionally
astearns: Sounds like the proposed resolution is to accept the
epsilon proposal subject to some refinement looking through
the literature
astearns: Is that good enough?
weinig: Don't wanna block it, this seems like a good start
fantasai: I think the "let's split into n parts" is not bad
fantasai: it's just a different feature
weinig: Some wording for pixels vs numbers having different epsilons
could be good to think about
TabAtkins: I think you're right that a unit-based approach might be
useful
weinig: The reason why this is on my mind is that we recently had an
issue with epsilons in the color space, to determine
something if something is powerless
weinig: and that epsilon wasn't defined, and the value in webkit was
too large
weinig: getting this right can cause real issues
weinig: I wanna think a bit harder about it for the color part but
these are details that we can work out
astearns: Proposal is to accept the draft with follow-up refinements
as needed
RESOLVED: Accept the epsilon proposal, with follow-up refinements as
needed
Maybe min, max and step should not be part of the random-caching-key
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11742
<fantasai> Proposal at
https://github.com/w3c/csswg-drafts/issues/11742#issuecomment-2707697957
TabAtkins: Defining randomness in CSS because the execution model is
not strictly temporal
TabAtkins: can't hold on to existing values
TabAtkins: don't want to calculate a random value on every recalc
TabAtkins: you need to have some stability
TabAtkins: the old draft did this via a caching key approach
TabAtkins: so if the key is the same between two instances of a
random() function then the values need to be the same
TabAtkins: this caching key has changed tho
TabAtkins: author could provide a custom-ident, but also min/max/step
values were pulled in
TabAtkins: any other random function would probably have a different
step and thus generate a different random value
TabAtkins: this worked reasonably well but did mean that values could
be accidentally linked together
TabAtkins: so random width/height you would get a random square
TabAtkins: rather than a random rectangle
TabAtkins: fantasai proposed something else, which is on the spec
right now. Caching key is (property, index among random
values in that property)
TabAtkins: so if you use `width: ...;` the key is (width, 0)
fantasai: You don't want a global random
fantasai: caching key also includes the element identity
fantasai: all of that gets computed to a random value which they
inherits so that we don't recalc it for inheritable
properties
TabAtkins: So on a single element if you use the same values on
different properties you're guaranteed to get distinct
values
TabAtkins: you can override it if you want, so you could still pass
the same ident to width/height
TabAtkins: some good examples of this are in the spec
TabAtkins: don't know what people might need for this but I propose
we accept the new draft based on elika's proposal for the
different key
TabAtkins: one further question about bikeshedding the keyword name
emilio: Is this declaration index thing local to each element you
compute?
TabAtkins: There's a 2nd thing you can provide, which is a keyword
indicating whether this value should be shared by all
elements with this style, or be element-specific.
TabAtkins: Then it either includes the element identity in the
caching key or not
emilio: Say you have 2 selectors with random() and you have an
element that matches one, and another that matches both of
them
emilio: so in one the index ...
TabAtkins: index is just the number of random() instances in that
declaration.
TabAtkins: so for 'width' always index of zero
emilio: So if they're in different elements, they would be shared?
TabAtkins: if not adding extra "match-across-elements" keyword, then
they all include element ident
TabAtkins: This is new, because CSS generally doesn't care where a
value came from
TabAtkins: whether spell out in comma-separated selector list, or in
a style attr, these are all the same
TabAtkins: I want to maintain that equivalence as much as possible
TabAtkins: so only including information from declaration it lives
in. Nothing from style rule or selector.
emilio: So maybe some things that you would expect to work don't?
emilio: e.g. 10 elements, each with style blah: random()
emilio: Ok, sounds good
TabAtkins: To be clear, having it vary by element is the default. You
have to specify keyword to make it shared across elements.
TabAtkins: So common case would be what you expect there
emilio: Seems reasonable
emilio: Shorthands maybe funny?
TabAtkins: It uses the declared property, e.g. in 'margin' you'd use
'margin' as part of the key, not the longhand names
TabAtkins: if you write 'margin: random(...)' you get equal margins
on all four sides
TabAtkins: There's a bit of text in the draft about how this works
for custom properties, it's a bit weird (unfortunately)
TabAtkins: Unregistered vs registered properties, since the latter
compute and the former don't before substitution
emilio: Might be confusing, but as long as we clarify impact of
registration should be ok
astearns: Over time
fantasai: What we're trying to do is by default you get max
randomness (varies by element, property, declaration
index), but doesn't by where you declare it
TabAtkins: within an element you can make it shared by using the
custom property
TabAtkins: can share across elements with the keyword tbd
TabAtkins: I think it's the right direction
astearns: A bit concerned about Oriol's comments
astearns: Concerned about Oriol not being convinced yet.
TabAtkins: I feel strongly about this model
fantasai: We should give Oriol a chance to comment on here
astearns: Let's defer this to next week
Received on Thursday, 20 March 2025 00:17:12 UTC