- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 12 Feb 2025 19:00:12 -0500
- 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 Cascade
-----------
- RESOLVED: We use a caret approach. It's part of the syntax and not
part of the name. Weak/strong with the same name is ok
(Issue #6323: Allow authors to explicitly place unlayered
styles in the cascade layer order)
- RESOLVED: Strength is exposed in CSSOM, details tbd (Issue #6323)
CSS Borders
-----------
- Solving issue #3720 (Add a 'hairline' border-width value) was
supported by the team, but the proposal needed more details added.
CSS Shapes
----------
- RESOLVED: shape() remains as-is, spec subset that is more tightly
tied to SVG <path> for a path() overload (Issue #10647:
Overload `path()` for CSS-y SVG path syntax instead of
taking up `shape()`)
CSS View Transitions
--------------------
- There wasn't clear support for the proposal to address issue #10773
(Elements with content-visibility in new Document) by having the
content-visibility:auto determination run again when there is an
incoming viewport. Discussion to clarify the proposal and discuss
alternatives will continue on the issue.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2025Feb/0004.html
Present:
Adam Argyle
Rossen Atanassov
Tab Atkins-Bittner
Kevin Babbitt
Emilio Cobos Álvarez
Yehonatan Daniv
Robert Flack
Simon Fraser
Simran Gill
Chris Harrelson
Brian Kardell
Jonathan Kew
Roman Komarov
Vladimir Levin
Alison Maher
Noam Rosenthal
Gaurav Singh Faujdar
Miriam Suzanne
Josh Tumath
Bramus Van Damme
Lea Verou
Regrets:
Oriol Brufau
Sebastian Zartner
Scribe: noamr
CSS Cascade
===========
Allow authors to explicitly place unlayered styles in the cascade
layer order
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6323
miriam: We discussed this at the f2f. We seem to have a solution in
the thread. The goal is being able to name layers that are
stronger than unlayered styles
miriam: The proposal is to have a character before the name that
marks that a layer is stronger rather than weaker than
unlayered style
miriam: We suggested the caret, a concern was raised that the
character should not be part of the name. This sent us back.
In that thread we've agreed on a path forward, if we're ok
going with this:
miriam: 1. resolving that we're taking on the caret approach at the
beginning of the layer name. 2. The caret is syntax rather
than a layer name.
miriam: This allows one issue to discuss, whether we allow name
conflicts between strong and weak layers of the same name
miriam: Sounds OK?
TabAtkins: Seems fine. It would have been ok in the name but this is
acceptable. For name conflicts, everything gets more
complex if we try to prevent conflicts
TabAtkins: It's reasonable if weak/strong names are different in the
CSSOM, works similar to important
<kizu> +1
<bramus> +1
miriam: Seems right
<kbabbitt> +1 to the proposal, I had someone ask about this feature
the other day
rossen: Anyone wants to add? Challenge?
PROPOSED RESOLUTION: We use a caret approach. It's part of the syntax
and not part of the name. Weak/strong with the same name is ok
bramus: Also something about CSSOM?
miriam: We expose strength in CSSOM
<TabAtkins> names come in "strong" and "weak" versions, in the CSSOM
there's a bool that reflects this; in the @layer rule a ^
prefix indicates it's strong
RESOLVED: We use a caret approach. It's part of the syntax and not
part of the name. Weak/strong with the same name is ok
PROPOSED RESOLUTION: strength is exposed in CSSOM, details TBD
rossen: Objections?
RESOLVED: strength is exposed in CSSOM, details tbd
rossen: miriam, you're going to follow up?
miriam: sure
CSS Borders
===========
Add a 'hairline' border-width value
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3720
TabAtkins: People look for a hairline border-width, usually "as
thinner as visible", something like device pixels
TabAtkins: We saw that it's not something that we want to expose
because it varies across devices. Authors don't anticipate
this change
TabAtkins: we'd like to avoid this
TabAtkins: Device pixels is not always well defined
TabAtkins: also it's not clear what happens if it's zoomed
TabAtkins: This can become very small
TabAtkins: kbabbitt suggested to declare that hairline is exposed as
1px, but rendered in an implementation-defined way,
probably something like device pixel aligned
TabAtkins: We can define how hairline works for each CSS property,
e.g. border/column etc
TabAtkins: This would allow accessibility options for users who need
to scale the hairline, and this won't mess up design
TabAtkins: I suggest we take Kevin's proposal and add it to the
border-spec and columns spec for multicol rule, perhaps to
other specs that need this
smfr: I'm concerned that the painted width is different from the
background. It means that the background is going to leak out
of the hairline
smfr: we can apply the same heuristic, but it seems weird that the
geometry doesn't match
TabAtkins: we should define that background area extends, but doesn't
paint
smfr: it doesn't work with box-shadow, adjacent boxes
TabAtkins: I think it's a good thing, but probably usually fine
<dholbert> RE the gap, you'd *only* get a gap on a HiDPI screen,
which is weird
smfr: My suggestion would be that the border-width would be some
fractional implementation defined value rather than being
different
Rossen: I can see how this would work if it takes the outermost part
of the pixel, e.g. there should never be background that
extends out, same for shadows etc. Anywhere else, you're
asking for all of the trouble smfr pointed out
TabAtkins: I was describing it wrong. The details in the thread are
to have it on the outside, exactly for these issues
TabAtkins: let's go with that
<emilio> It reveals the underlying background unless it uses
`padding-box` or so right?
<TabAtkins> yes
Rossen: It's going to break things that align, like snapping/abs
position etc
joshtumath: Similar note, the stripes function (not implemented yet).
What would happen when we want multiple hairline-width
stripes?
TabAtkins: I think hairline wouldn't be a generic width value, it's a
value for specific properties like border-width
<kizu> Fun fact: Chrome paints `2px double` border as 2 hairline
lines with a gap
TabAtkins: We'd probably won't paint stripes in a hairline-width
border
emilio: I was going to raise a lot of smfr's concerns. I don't object
to hairline value, but I think we can change the border
bounding algorithm we have to bound towards the nearest
hairline
emilio: The UA already aligns pixels e.g. 0.01 border-width to
something that's hairline-like
emilio: I would prefer to tweak the current border-width rounding to
a hairline
emilio: For shadows, it's not a huge issue. Maybe it's just a matter
of implementing stripes
emilio: I much rather expose the current border-width rounding and
allowing the UA to tweak it, or expose a round-ish function
<smfr> Blink and WebKit round a 0.0001px border up to a hairline;
Gecko doesn't draw it
<emilio> smfr: Probably pixel precision issue, `0.01px` does get
rounded up
Rossen: Also what does this mean for two hairline borders to collapse
kbabbitt: I heard that in border the hairline would be painted on the
outermost hairline, and the background would fill under that
TabAtkins: It's not that the background fills in, it's that the
background is drawn under the border area
kbabbitt: I want to avoid something where when a designer defines
something on a high DPI device it breaks on a different
device with lower DPI
Rossen: I'm not sure where this was going. There are still some
questions
Rossen: This sounds like a great proposal and something that people
are trying to do today
Rossen: Is that something we want to pursue? Do we have a good
starting point?
TabAtkins: We don't have all the details yet
TabAtkins: I propose we take this back to the issue
<emilio> TabAtkins: wdyt of `border-snap(<length>)` which just snaps
that length as a border or so?
<TabAtkins> emilio, that's part of why I don't *want* to rely on
border rounding. "if you want a hairline, put in a value
that is *probably* too small to actually paint, but not
*too* small, and you have to guess what "too small" means"
<emilio> I think it's not incompatible with `hairline`, if we make
hairline resolve to pixels and affect geometry...
<emilio> fair
CSS Shapes
==========
Scribe: TabAtkins
Overload `path()` for CSS-y SVG path syntax instead of taking up
`shape()`
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10647
lea: There's been discussion around making paths easier in CSS
lea: so far it's still very closely mapped to SVG paths
lea: taking the design of paths, with its concepts, segments,
commands, args, and supporting a CSS syntax for them
lea: that's what we've done with the other shapes already too
lea: polygon(), circle(), etc
lea: so it seems weird that we leave path() as this weird function
that just takes a string of SVG, and make a different shape()
function for the css-y one
lea: less discoverable and inconsistent
lea: when I filed this issue, thought we might leave shape() for
another feature
lea: but now I think overloading path() is better even disregarding
that
noamr: shape() does already have a few features that SVG doesn't, or
does it differently
noamr: order of control points, you can combine rel/abs in the same
shape
noamr: now adding corner shapes, that'll probably get added to shape()
noamr: but also, I think path() can still be extended to make it
actually usable, by giving it viewbox and fit
noamr: I don't have a strong opposition to calling this path(), but I
do think they're a bit different
noamr: shape() is a recipe to create a shape
noamr: once you combine the shape with a reference box, the path you
get can be vastly different from what svg could make
noamr: so I think keeping shape() separate makes sense as it's a
recipe to create paths rather than the path itself
noamr: also the mental model of path() is closely related to SVG, and
if it's extended as I propose it'll stay close to SVG
lea: You mention rounding
lea: I think we eventually want to backport some of these improvement
to path, at least those that are feasible
lea: but in general I think a better shape function is useful, it
just worries me that we're leaving this gap
lea: authors will expect a CSS syntax for <path> like the other
functions/elements have, and they'll find path() and shape() is
a different thing
noamr: We don't have proposals to backport the new stuff to SVG, or
filling in gaps
<smfr> +1
noamr: so right now, is this better to give a new name with the
intention that it'll continue growing, or should we name it
path() and say it's a CSS-ified <path> but with extensions
noamr: I think it ends up just being a name thing
noamr: No strong opinion, but weak pref for shape()
lea: Replying to "no proposals for backport"
lea: when designing syntax, it's not just about what proposals exist
now, but what future direction the language might go to
lea: that's the challenge with standards
lea: things like backporting rounding to <path> is a low-hanging
fruit I think we could end up with
lea: so we should plan around it
smfr: I feel more strongly than Noam that shape() is right
smfr: it's more discoverable, search for "css shape function" you'll
find it
smfr: I see it being used a lot with future border-shape, so shape()
seems natural
smfr: I sympathize with lea that we should design for the future, but
we can choose a different name in the feature if needed
TabAtkins: Regarding any backporting/future extensions of path(), to
the extent we want to backport anything into SVG, we'll
still be spelling it in the SVG way and would probably
want to maintain this in-string capability
TabAtkins: if we don't backport to SVG, but just add to the string
that SVG defines, it would look quite different from what
shape is doing, because you can't drop things as easily
into a command because of the parsing
TabAtkins: anything we add to SVG would probably not make it into the
path itself. I'm not hopeful
lea: Another benefit is that it's convertible
lea: I'm convinced that the current design is good enough. I wonder
how much can be backported to path?
TabAtkins: What kind of improvements?
lea: Same segments with CSSified names, length-percentage etc
smfr: A more restricted grammar of this
lea: Sounds perfect
noamr: I'm also okay with that possibility, think it's doable to take
the subset of shape() be ported back to path()
<lea> PROPOSED RESOLUTION: shape() remains as-is, spec subset that is
more tightly tied to SVG <path> for a path() overload
Rossen: So I'm hearing keep shape() as is... [basically restates
lea's proposed resolution]
<noamr> +1
<TabAtkins> +1
<smfr> +1
<chrishtr> +1
RESOLVED: shape() remains as-is, spec subset that is more tightly
tied to SVG <path> for a path() overload
CSS View Transitions
====================
Elements with content-visibility in new Document
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10773
noamr: Issue with how cross-document VTs, the order that things are
discovered for an incoming VT
noamr: We check for the names, and only after check if the element is
visible (based on content-visibility:auto)
vmpstr: For initial content-visibility:auto determination, it happens
during "update the rendering" in html
vmpstr: if we have an incoming VT, we need to determine which
elements are matched to the old doc *prior* to running
"update the rendering"
vmpstr: so we have an issue, all the content-visibility:auto things
aren't matched even if they're in the viewport, because we
haven't determined their visibility yet
vmpstr: so proposal is, if we have an incoming VT, we run the
content-visibility:auto determination first
vmpstr: this might also apply to same-doc transitions if you've added
an element to the DOM with content-visibility:auto
vmpstr: but it's less clear that's needed, since the same-doc steps
happen in a different spot. but we do want the same ability
emilio: Are you proposing to run the determination steps again/first,
or *move* them?
vmpstr: The initial determination has to just run before the VT
matching steps
vmpstr: so I'm proposing that we do it *again* if there's an
incoming VT
vmpstr: doesn't duplicate work because the second time it's not the
initial determination, it's a subsequent
emilio: I thought VT operations already happened after this, maybe I
was wrong
vmpstr: For the cross-doc case, it happens before
vmpstr: it needs to happen before frames are drawn in the new doc
vmpstr: so "update the rendering" hasn't run yet
emilio: Okay, so cross-doc VT runs the content-visibility:auto
determination explicitly, outside the rendering loop
vmpstr: Yeah
emilio: It's a little sad, might expect intersection observers to
also work...
emilio: maybe it's better to run the whole rendering loop but not
point, that seems tricky to define tho
emilio: maybe that's fine, but wondering if we've considered larger
changes like that
vmpstr: We haven't
vmpstr: the content-visibility case was a bug report
vmpstr: haven't seen other cases reported yet
vmpstr: don't think we want to run the rAF handlers without them
producing paint
emilio: Maybe not, but also it might not be too bad?
emilio: but if you did a content-visibility:auto-like thing with IO
you might want that to run
emilio: seems a bit whack-a-mole if we need to keep adding things for
the VT step
vmpstr: If there's script involved, yeah, that won't trigger. but
content-visibility is a CSS thing, so as long as things are
declarative they should all "work"
vmpstr: but script is tricky
emilio: I think my pref would be to try running one frame without
painting, that might work, but that's a bit awkward. Don't
want to block if you're certain on this approach, just feels
a bit special-case-y for my taste
<smfr> +1 to emilio
bramus: Wanted to underline the content-visibility part affects
whether the element is captured or not, authors have reported
that
bramus: maybe we can resolve on just the content-visibility part and
then experiment with the frame render?
bramus: some people are blocked on this right now, they can't add the
content-visibility performance improvement to their website
due to VTs
emilio: There are two approaches, right? a third is to make
content-visibility:auto not behave as hidden for VT. I think
scrollIntoView() already acts like you're visible
emilio: so it's not unheard of
vmpstr: With find-in-page there's no difference, but this would
defeat the style optimization for content-visibility:auto on
navigations that have an incoming VT
vmpstr: there's no user action besides the navigation, and we need to
run style on the whole document to find names then
vmpstr: we've previously decided that in same-doc, if a c-v auto is
off-screen then a sub-element won't be available for VT
emilio: Right, point is that you don't have to paint it, you just
check for names
Rossen: Out of time on the call, don't feel like we're ready to
resolve.
Rossen: Continue discussion in the issue
Received on Thursday, 13 February 2025 00:00:44 UTC