- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 22 May 2025 19:14:14 -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.
=========================================
Scribing
--------
- The group will experiment with creating a scribe rota to help
expedite the process of selecting a scribe each call. If you are
interested in being on the rota, please add your name to the wiki
here: https://wiki.csswg.org/planning/scribing
CSS Values
----------
- RESOLVED: Explicitly allow tree-counting functions in container
queries (Issue #10982: Disallow mix/random/tree-counting
functions in some contexts)
CSS UI, Media Queries & Selectors
---------------------------------
- RESOLVED: Working on scrolling queries (Issue #6400: Expose current
scrolling direction)
CSS Borders
-----------
- RESOLVED: Reduce all radii in order to avoid overlap of shapes
(Issue #12098: Consider constraining radii for concave
corner-shape when opposite corners overlap)
- There was some initial preferences toward the third option, add
env(hairline), to resolve issue #3720 (Add a 'hairline'
border-width value). Several questions were unresolved on the
proposal at the end of the call time, so discussion will continue
on github and a future call.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2025May/0007.html
Present:
Rossen Atanassov
Tab Atkins-Bittner
Kevin Babbitt
Justin Breiland
Oriol Brufau
Keith Cirkel
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Simon Fraser
Daniel Holbert
Roman Komarov
David Leininger
Vladimir Levin
Rune Lillesveen
Alison Maher
Eric Meyer
Cassondra Roberts
Noam Rosenthal
Miriam Suzanne
Josh Tumath
Munira Tursunova
Lea Verou
Sam Weinig
Regrets:
David Baron
Scribe: fantasai
Scribe's scribe: TabAtkins
Scribing
========
<JoshT> https://lists.w3.org/Archives/Member/w3c-css-wg/2025AprJun/0062.html
JoshT: I'm concerned how some people in the WG scribe more often than
others, desire to give them a rest
JoshT: Also want to help people feel more confident scribing
JoshT: Proposal is to create a list of people who would like to scribe
JoshT: We would go through the list and pick the next scribe
JoshT: If someone is absent and sending regrets, skip to next person
and they will swap
JoshT: Initially some positive feedback on emails
JoshT: But yesterday/today also some emails about people who aren't
sure
JoshT: And maybe being able to scribe more ad-hoc is more useful
JoshT: You don't know what's going to happen that day, maybe you're
tired at the end of the European day
JoshT: If people approve this, I can make a wiki page to note this
down
JoshT: links to how to scribe, etc.
JoshT: and we'll try to make a list of ~8 people who can scribe
JoshT: I'll ask on the call if people want to be on the scribe rota
Rossen: Seems like a great initiative. Also might be good to have an
ad-hoc list
Rossen: Hopefully will make it easier for people to come forward
lea: I think the general idea is good, but need to work on details. I
assume that missing person goes to next telcon
lea: One problem is it formalizes who is regular and who isn't
lea: Not just that it could be a barrier to participation, but
sometimes who is regular varies over time
lea: But as long as we can flesh out the details, could be a good
thing
fantasai: My suggestion is that rather than going down the list -
that requires handling exceptions, etc
fantasai: rather than rotating I suggest picking a random person from
the list each time
fantasai: so people don't have to maintain state across telcons, but
over time it'll be distributed
fantasai: if someone can't make it, just skip past them
fantasai: I suggest [missed] rolling [missed] for the n
JoshT: My concern with randomness is that it's not fair, could choose
the same person multiple time
<TabAtkins> Note that we can do a useful randomness with some
history, yeah.
<lea> there are randomness algos where we ensure a fair distribution
<lea> yup, what TabAtkins said
kbabbitt: Support idea. I'd be happy to join. Haven't volunteered
recently because of injury, but otherwise happy to join.
kbabbitt: If person wants to speak, maybe next person becomes backup
scribe?
Rossen: Overall hearing positive feedback, and definitely support
this myself
Rossen: Josh, how about you put together that wiki strawman proposal?
Rossen: We can figure out the details in no time
<TabAtkins> (I like the rota idea in general, but I'm fine with one
of us "good scribes" being the usual person to turn to
when the scriber is talking. ^_^)
JoshT: If you're willing to sign up, note in IRC
POLL: Do you want to volunteer to scribe?
<fantasai> +1
<JoshT> +1
<kbabbitt> +1
<ydaniv> +1
<emilio> +1 (when permitted)
<TabAtkins> +1 (obvs)
<JoshT> Here is the initial draft of the scribe rota. If you asked to
sign up and I missed your name, please add your name.
https://wiki.csswg.org/planning/scribing
CSS Values
===========
Disallow mix/random/tree-counting functions in some contexts
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10982
futhark: Some functions are only possible in some contexts, e.g.
property declarations or other places where we have an
element context
futhark: descriptors, media queries, etc. don't have element context
futhark: For font-relative units we fall back to the default font,
but no such fallback for sibling-index()
futhark: Conclusion is to drop such functions at parse-time as
invalid where they don't make sense
futhark: we can add back case-by-case if something makes sense
futhark: One question is with regards to container queries, which
does have an element context: should we allow such functions
in container values?
weinig: These issues speak to a need, when defining CSS functions, to
have a table that specifies how they operate and what
contexts they're allowed in
weinig: Quite a matrix now, that each function needs to think about
weinig: like properties, standard set of questions to answer, would
be helpful
<TabAtkins> +1 to finding the set of constraints that we should
formalize around
emilio: Agree this is an issue, and container queries is interesting
emilio: I suspect it might be annoying to invalidate on container
queries, and I can't think of a good use case... not that
people might not come up with one
emilio: So my preference would be to start by disallowing, and if
people ask for it, we can enable later
emilio: but also ok if people think it's useful to have
futhark: For style queries, we currently parse as a non-registered
property, so we don't know until we're finished parsing that
it's not a property
futhark: if it's a registered query
emilio: I was thinking about container queries like size container
queries and such
futhark: That too. But with regards to style queries specifically
emilio: For style queries... I am not sure I follow, can't you just
disallow those functions while parsing?
emilio: That maybe presumes those functions wouldn't be part of the
syntax
futhark: When you parse the property the first time, you don't have a
registered property on the first pass. So you don't know if
it's a sibling-index()
miriam: If we disallow any of these, we should consider one at a time
in container queries
miriam: I do think there might be use cases, so I wouldn't want to
take as a group
miriam: because here they would have a meaning, so we'd disallow for
some other reason
weinig: Another way to think of this is to reverse it, and say, for
each context where CSS values can be used, we should define
what types of CSS values are allowed
weinig: For instance, if relative units aren't allowed, but you're
using <<number>> a calc() with relative units wouldn't be
allowed
weinig: It's both these unique contexts, and these unique values,
that have certain dependencies
weinig: Probably you want one or the other, but maybe both?
weinig: But need to figure out what the constraints are, to define
that matrix
futhark: I'm fine with starting by disallowing these functions in
contexts where you don't have an element
futhark: If I understood you , Mia, you're fine with not supporting
anything and then bringing in each function that has a need?
miriam: Is there a good reason to start that way?
miriam: I think there are going to be use case for these, and we do
have a context for them
miriam: so want to know if there are particular reasons not to
support them
futhark: I've been working with sibling-index() and sibling-count(),
we have an implementation, haven't found any problems
weinig: I think just going and disallowing in some context is too
simplistic
weinig: disallowing wholeheartedly, would disallow calc() with
certain values
weinig: It's a more complicated question, which elements in which
contexts
<TabAtkins> Yeah, math functions don't bring any context requirements
*themselves*, just their contents
futhark: would it make sense to start with tree-counting functions,
separately?
futhark: or would that be too wide
weinig: It's a problem to do one-off restrictions, rather than
figuring out the system
weinig: We'd have to look at the whole landscape again
weinig: so now is the time to define these characteristics
futhark: Can we get a resolution on container queries to explicitly
allow tree-counting functions for now?
weinig: Sounds reasonable to me
weinig: we think CQ will have an element context, so seems reasonable
to allow them now, and formalize more later
futhark: So we can extend the CQ spec, which currently talks about
font-relative units. We can expand to include tree-counting
functions
<miriam> +1
futhark: Then let's resolve that now, and continue the rest of the
discussion
emilio: I just wanted to note, regarding complexity, the one that's
annoying is inserting an element in the DOM, assuming index
of container ....
emilio: Right now :has() has this problem, too, needs to invalidate
deeper to invalidate random elements in arbitrary parts of
the tree
emilio: The usual stuff doesn't have this complexity
emilio: it's a lot more non-local than using it in property
declarations
emilio: That said, it *can* be implemented, so I'm fine allowing it
futhark: Similar issue with keyframe animations
futhark: so multiple cases of it
fantasai: If there are use cases, then it's worth doing the extra
work; if not, it's not worth doing
futhark: I would expect there to be use cases for style queries in
particular, because computed style can use sibling-index()
so it would be natural to allow
Rossen: So this is an academic expectation rather than a practical one
miriam: I'm trying to encourage expectation that things in CQ resolve
based on the container, and the more that's true the easier
that is to teach
miriam: Things can resolve because we have a container to resolve
against
futhark: Proposed to explicitly allow tree-counting functions in CQ
PROPOSED: Explicitly allow tree-counting functions in container
queries
Rossen: Any additional points or objections?
RESOLVED: Explicitly allow tree-counting functions in container
queries
CSS UI, Media Queries & Selectors
=================================
Expose current scrolling direction
----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6400
TabAtkins: We have a whole batch of scroll-related container queries
TabAtkins: There are a lot of use cases in this space, particularly
about knowing the last known scroll direction
TabAtkins: Two questions are: what's most recent scroll direction.
Other is what is current scrolling direction.
TabAtkins: Hidey UI is like this on mobile
TabAtkins: Some discussion about velocity and other things that might
be better to handle as scroll animations
TabAtkins: There's an explainer in the issue
smfr: In general this seems reasonable. Went through explainer,
didn't see any explanation of rubber-banding
smfr: I don't think we want to expose that change in direction to web
content
smfr: Also curious, what happens for scrolls that result from content
changes
smfr: i.e. scrolls that scroll anchoring tries to prevent
smfr: Could end up with circularity, or oscillating between two
states -- we see this often with JS-driven changes
TabAtkins: I think the answer should be that we base this on
user-driven scrolling, so not script-driven or
content-driven
TabAtkins: that would avoid these circularity issues
<flackr> +1
TabAtkins: And it's close to impossible to detect in JS, could
address directly this way
TabAtkins: Don't think there's a use case for script scrolling for
these things
smfr: Seems surprising, because wouldn't an animated scroll to 0,0
want to show/hide these bars?
TabAtkins: possibly, but at that point you're scripting, so why not
just script it
<flackr> I think at least scroll anchoring should not count,
programmatic scrolling may be interesting
[missed]
Rossen: what about autoscrolling?
TabAtkins: that's still scrolling
TabAtkins: Wanted to ask if group wants to pursue this idea
ntim: Not sure I'm convinced by answer that if we invoke script we
can just invoke more script
ntim: The way you write the query is @container scroll-state(), and
if you invoke script and you can't change that state, then you
have to duplicate your CSS to support a class
ntim: And also have your scroll direction query
ntim: It would be duplicated into 2 places, if you invoke script to
manipulate the state
<flackr> I think we can explore this with an example of how this
would be done
TabAtkins: Question of what to do about script-driven scrolls is
something to think more about, so let's discuss in the
issues
fantasai: You don't necessarily have to introduce a class, could do
it with a property
fantasai: and put that in the CQ
flackr: Directionally, should we consider whether "last scrolling
direction" is thing we should pursue first, because it comes
up in all use cases, and active scrolling direction can be
pursued afterwards?
TabAtkins: Problems are easier and more common for recent scroll vs
active scroll
flackr: Agree
flackr: Active scroll might need extra capabilities
Rossen: Any objections to this direction?
fantasai: We need to figure out what to do with active scroll, so
we're designing a coherent syntax space for when it is
tackled
RESOLVED: Working on scrolling queries
CSS Borders
===========
Consider constraining radii for concave corner-shape when opposite
corners overlap
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12098
noamr: Right now we constrain radius when there is a corner overlap
noamr: but we don't constrain for diagonals, because these can't
overlap in convex shapes
noamr: but for concave shapes they can
noamr: so question is how do we constrain these?
noamr: Right now shrinking is all corners by a ratio
noamr: enough to avoid overlap of radii
noamr: Here I'm doing the same thing. If the shapes intersect, I
shrink both so that they don't touch
noamr: Here proposal is in green
noamr: Both corners shrink by same ratio, and aspect ratios are
maintained
<TabAtkins> "Hull" here is defined by the tangent at the center point
intersecting the horizontal/vertical?
fantasai: [missed] all the principles that led to the original
conflict formula
fantasai: probably want to shrink all the radiuses, not just the two
intersecting
fantasai: [missed more]
noamr: Keeps the shape, I like that
TabAtkins: But we don't do that with current case
TabAtkins: We don't do that for adjacent overlaps, so I'm not sure
why we'd shrink everything in a diagonal overlap
<fantasai> https://www.w3.org/TR/css-backgrounds-3/#corner-overlap
fantasai: You reduce all of the radii
<fantasai> "When the sum of any two adjacent border radii exceeds the
size of the border box, UAs must proportionally reduce the
used values of all border radii until none of them
overlap."
<fantasai> ALL radii
<TabAtkins> I'm wrong, fantasai is right, we do shirnk all of them
<TabAtkins> https://software.hixie.ch/utilities/js/live-dom-viewer/saved/13807
<TabAtkins> So we should shrink all of them, and jsut use the largest
necessary factor between all four adjacent pairs and two
diagonal pairs
smfr: If you have convex and concave shapes, then you have some
complex constraints
smfr: how do you do that
noamr: First constrain adjacent ones, then constrain the opposite ones
smfr: Maybe that works, yeah
flackr: Another possibility would be that we don't shrink and the
border becomes a straight line
noamr: Wanted something consistent with adjacent borders
smfr: I don't think we should, the math is already super complicated
TabAtkins: fantasai was right, we do shrink all of the corners if one
pair is too large
TabAtkins: see demo ^
TabAtkins: so we should be consistent, find the shrink factors
necessary for all four adjacent corners and the diagonal
corners ,and just apply the largest one to all the corners
fantasai: the reason we did it this way was to preserve the shape as
much as possible. anything else distorts the shape
PROPOSED: Reduce all radii in order to avoid overlap
RESOLVED: Reduce all radii in order to avoid overlap of shapes
Add a 'hairline' border-width value
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3720
<Rossen> https://github.com/w3c/csswg-drafts/issues/3720#issuecomment-2864297026
TabAtkins: Options I see here: 1) hairline keyword to border-width
and inside calc(), 2) add a hairline unit, 3) add a
function, e.g. border-round() or env(hairline)
TabAtkins: benefit of keyword is it's easiest to write
TabAtkins: but downside is grammatical ambiguity means might not be
able to use it everywhere easily, need to wrap in calc()
some places
TabAtkins: The other two options don't have these downsides
TabAtkins: but several people don't like the usability of the unit,
looks weird, I agree
TabAtkins: shortest option but funky
TabAtkins: Function might be the best way to go
<TabAtkins> env(hairline)
TabAtkins: Question of what is appropriate hairline is an
environmental info, so my proposal is env(hairline)
<kizu> +1 to env(hairline)
<romain> Those that do want it as a unit can make one from the env()
with the (unimplemented) custom unit feature.
emilio: My concern with env(hairline) is that it behaves differently
with CSS zoom
emilio: You multiply by zoom, but as long as less than hairline,
would be rounded to device hairline
emilio: whereas if you have a device hairline, get pixels, and zoom
the pixels
emilio: zoom could make the hairline invisible
<lea> Is env() allowed anywhere the other options would be?
TabAtkins: Zooming down could shrink to invisibility, but could
[missed]
emilio: If you had border: env(hairline) and something relies on that
value to match, zooming out, the lengths would no longer
match because borders are still rounded up
emilio: that's a subtle difference
emilio: considering everything, I think env(hairline) is the best
option
smfr: Are you referring to non-scaling-stroke emilio?
smfr: I don't think we want that
TabAtkins: Not the explicit goal but if you have a sufficiently small
length it can behave like that
TabAtkins: he's not asking for that as a goal
smfr: So if scale() is used it'd get thicker?
TabAtkins: Yeah that's not a question
<lea> I wonder if it may make sense to figure out what a hairline
should resolve to before we name it. E.g. if it resolves to a
device pixel, that is a reasonable unit in itself. If it
doesn't resolve to that, then I'm having trouble
conceptualizing what it resolves to.
<TabAtkins> it does not resolve to a specific device pixel, Lea
fantasai: I think I'd prefer a border-round() function
fantasai: I'd call it pixel-round()
fantasai: I'd prefer to avoid giving the idea that it's possible to
do your layout in device pixels
lea: 3 things
lea: not making it a unit makes sense if we only use multiple of one.
lea: env() seems to make sense... is it disallowed anywhere that
could otherwise be allowed?
lea: would it make sense to figure out what a hairline resolves to?
lea: when would I use a hairline unit?
lea: I would conceptualize as a device pixel
lea: so as an author, I don't know, and it's too vague
lea: might make sense to figure that out first
<fantasai> +1 lea
TabAtkins: We keep running out of time, so let's do this first next
week
<astearns> or could do an async
TabAtkins: Use cases for multiples if you need to match another
element to width of element with hairline borders, might
need 2x
TabAtkins: env() is allowed everywhere
TabAtkins: Finally, what does it resolve to? It will resolve to some
multiple of a device pixel, not necessarily 1. As screens
become higher res, device pixels might be too small to be
a reasonable hairline
Received on Thursday, 22 May 2025 23:14:46 UTC