- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 3 Jul 2025 18:33:35 -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.
=========================================
Pseudo classes for the `interestfor` API (Issue #12154)
-------------------------------------------------------
- Concerns were raised that `possible` my be cyclic; if it causes
issue it may be dropped.
- There was no clear agreement on how `partial` will work, especially
in a mobile context. Discussion will continue on github and
`partial` will move to a separate issue to make discussions
easier.
CSS Borders 4
-------------
- RESOLVED: Publish css-borders-4 with the edits described [add an
introduction and move the not ready for implementation to
partial borders]
CSS Text
--------
- RESOLVED: Allow shipping with no-autospace as initial value,
continue discussing eventual default behavior (Issue
#12386: Reconsider the initial value of the
`text-autospace` property)
CSS Values
----------
- RESOLVED: Republish the WD (Issue #6245)
CSS Backgrounds
---------------
- There were several concerns raised on issue #12132 (Using logical
keywords in background-position shorthand with multiple
backgrounds) around how to implement and how to cascade. There
wasn't time to dive in further during the call so group members
were asked to add examples of how the concerns would manifest to
the github issue.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2025Jul/0001.html
Present:
Rachel Andrew
Rossen Atanassov
David Awogbemila
Kevin Babbitt
David Baron
Justin Breiland
Oriol Brufau
Emilio Cobos Álvarez
Yehonatan Daniv
Matthieu Dubet
Elika Etemad
Robert Flack
Simon Fraser
Mason Freed
Paul Grenier
Anders Hartvoll Ruud
Brian Kardell
Roman Komarov
Romain Menke
Eric Meyer
Florian Rivoal
Noam Rosenthal
Alan Stearns
Miriam Suzanne
Josh Tumath
Bramus Van Damme
Lea Verou
Samuel Weinig
Sebastian Zartner
Regrets:
Tab Atkins-Bittner
Daniel Holbert
David Leininger
Chris Lilley
Scribe: emilio
Scribe's scribe: fantasai
Pseudo classes for the `interestfor` API
========================================
github: https://github.com/w3c/csswg-drafts/issues/12154
masonf: we talked a bit about this API in the past for
`interest-{show,hide}-delay`
masonf: fyi the attribute is probably going to get renamed to
`interestfor`
masonf: so these are things that match while the user shows interest
(e.g. hover or keyboard focus)
masonf: there are two pseudo-classes in the last comment, the
`invoker` and the `target`
masonf: then there are two levels
masonf: partial (with keyboard focus) and full interest
masonf: also another proposal to suggest possible interest
<lea> partial interest seems like a confusing concept. Reading the
explainer, perhaps something around "delayed" or "future"
interest? Is there partial interest that is not around that?
masonf: so current proposal is two functional pseudo-classes
`:interest-{target,invoker}()`
masonf: with values of `possible`, `partial`, and `total`
masonf: you can use them without the parentheses
masonf: which means `(total)`
masonf: questions are general shape
masonf: questions about the "possible"
masonf: e.g. should the target exist and be valid
masonf: also whether the target should support possible
masonf: that'd require to know whether something points
astearns: so possible should be only for valid interestfor values...?
astearns: anything less than that is not a possible match
masonf: I think that makes sense
emilio: I think we shouldn't do possible
emilio: since it seems it'd require / want to check whether something
is focusable / hoverable as well, and that's trivially cyclic?
emilio: unless there's a very strong use case for it I'd at the very
least defer it
masonf: The cyclic part is a great observation I hadn't noticed
masonf: the possible value was discussed in the middle of the issue
masonf: was brought up as sugar for `[interestfor]`
masonf: it was not brought up whether it actually needs to be
focusable or so
masonf: I'm agnostic to the possible value so if it causes issues I'm
ok dropping it
bkardell: the possible thing does seem a little dicey to me too
bkardell: we don't have a hoverable / focusable pseudo-class
bkardell: I kinda wish we did?
bkardell: but I'd rather have those than this
<lea> +1 to bkardell, a :focusable class is sorely needed, and very
hard to emulate
<bkardell> lea: it would need more than that I guess, since you can
have things that have nuance too - what does it mean to be
focusable isn't necessarily just binary
astearns: Is `partial` actually needed?
astearns: could we start with the non-functional versions, then
decide partial / etc?
masonf: that one was the genesis of the pseudo-class
masonf: in the partial interest state the popover wants to have a
hint text
masonf: so we wanted to provide that hint in the UA stylesheet
masonf: and we'd rather not do magic
astearns: haven't thought about it too deeply, but that
interest-partial thing is the interesttarget, then there's
the second level of "I've done a thing to show something
else"
masonf: if the popover contains a button the user would have to do
something else to get to the button
bkardell: not sure if we're talking about this but there's some
disagreement over whether this is currently possible,
because FF and apple don't support this if we can't find a
way to actually do it on mobile
bkardell: there was a thing added the other day to add a
pseudo-element
bkardell: does this relate to that?
bkardell: if we have that pseudo-element, does the pseudo-classes
apply?
masonf: there are issues for this, those are rather unrelated
masonf: all of these pseudo-classes apply in the same way
masonf: whether the pseudo exists
<bkardell> but wouldn't the pseudo be the thing that got interest?
fantasai: we want to echo the concerns about making this work on
mobile on the feature over-all, on the naming question I
think interest-target is a bit ambiguous, because the
target of your interest is the invoker
masonf: the attribute is not interesttarget anymore, it's interestfor
fantasai: you're proposing `:interest-target`
<lea> +1 fantasai
fantasai: but the target of your interest is :interest-invoker, and
not :interest-target; so that's confusing
<fantasai> maybe :interest-details?
lea: wanted to ask about the pseudo-element
lea: IIUC that'd be a pseudo-element that would go from the target to
the popover
lea: that'd be a pseudo-element on the invoker
lea: to provide a button on the side for touch-screen users
masonf: it'd be a button that shows e.g. the context menu
<bkardell> it is like a (?) button
lea: Oh I thought that it went from the invoker to the popup
lea: which would be a combinator
lea: which would also be useful
masonf: had not heard that suggestion, can open one
<bkardell> there is a long /for/ thing going back like 100 years
<bkardell> I don't see why this would be diff
emilio: trying to keep about pseudo-classes in particular. Are there
other use cases for this other than telling the user how to
fully activate the popover?
emilio: if not, I'm doubtful of the pseudo-element approach in the
style sheet
emilio: if we use an existing pseudo-element, authors may want to use
for other thing
emilio: Also don't want to show it all the time, once the user has
opened doesn't need instructions anymore
emilio: Just doesn't seem useful to have the partial option
masonf: primary use case is that
masonf: 2 things: instructions for the user -- which could be handled
by UA -- but the problem with that is that the site might
know whether it's needed or covered elsewhere or already
known by user etc.
masonf: also styleability, e.g. fading in/out
emilio: Should the unparenthesized pseudo-class match both partial
and total. Is there a reason for the default to be full
interest?
masonf: Subtle question of whether full interest includes partial.
masonf: prototype is that full is a superset of partial
masonf: reason for that is it feels more useful
masonf: partial interest is a corner case
masonf: does this thing have interest at all or not
masonf: so I thought shorthand should be total
<bkardell> it does seem like pseudo classes generally are more like
the way Emilio mentions
emilio: That's not how I would have expected total to work?
<fantasai> +1
emilio: I would expect total to only match when not partial
emilio: I would expect partial and total to be exclusive
emilio: and unparenthesized one to match both
<fantasai> +1
masonf: Third state, empty args with parens
masonf: main usage will be unparenthesized, and that should match
either partial or full
masonf: I think as long as way to do this, it's ok
masonf: Does what emilio suggested make sense?
astearns: It does constrain us if we want to add other parameters
astearns: would need to also match with no-parens to be consistent
masonf: I don't think that'd be very useful if we add partial
<bkardell> Maybe that would/should be a separate issue
<bkardell> just like I said with focusable and hoverable
astearns: let's take it back to the issue and move partial to a
separate one
CSS Borders 4
=============
github: https://github.com/w3c/csswg-drafts/issues/6900
noamr: wanted to publish a fpwd of css-borders-4
<florian> +1
noamr: corner-shape is about to ship in one browser, and some of the
other stuff
fantasai: +1 for publishing early and often
fantasai: I wonder if you can add an announcement
SebastianZ: +1 to publish, big fan
SebastianZ: we need to get rid of the not ready for implementations,
and update the changes section
fantasai: there's no changes since it's a fpwd
SebastianZ: changes since level 3?
SebastianZ: border-color and other things from l3
fantasai: maybe list the new things
fantasai: not ready for impl should probably apply to the partial
borders section
weinig: Is there any indication that the prev draft is not having the
same name?
weinig: css-backgrounds vs. css-border
fantasai: we should cover that in the introduction
fantasai: this is no longer a diff spec?
fantasai: has all been merged?
SebastianZ: only part of it
fantasai: the introduction should describe its relationship with
other specs
fantasai: so additions, introduction, move the not ready for
implementation to partial borders, then publish sgtm
astearns: so are we fine with resolving publishing with those edits?
fantasai: yes!
RESOLVED: Publish css-borders-4 with the edits described
CSS Text
========
Reconsider the initial value of the `text-autospace` property
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12386
Rossen: this issue is still under active discussion
Rossen: I know this is something the chrome team wanted to bring
forward to unblock implementation
Rossen: is koji on the call?
fantasai: I think we all agree it should be fine to ship initially
with default no autospace
fantasai: what the default should be ultimately is the debate in the
issue
fantasai: but we can resolve that no autospace is an acceptable
default for the time being
florian: That's chrome's position as well
Rossen: Anything else that you want to point out?
fantasai: I think we need to continue the discussion about eventual
default
<florian> +1
emilio: Does the property definition allow changing defaults easily?
Is there 'normal'?
fantasai: yes
emilio: then that sounds fine
PROPOSED: Shipping with default autospace off is fine for now, keep
discussing eventual default
RESOLVED: Allow shipping with no-autospace as initial value, continue
discussing eventual default behavior
<masonf> Per side-chat, Chrome is supportive of the resolution on
12386 above.
CSS Values
==========
Interpolate values between breakpoints
--------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6245
<fantasai> https://drafts.csswg.org/css-values-5/#mixing
fantasai: we split mix function in two categories, mix and
interpolation
fantasai: where mix() produce weighed averages
fantasai: interpolate creates a mapping
fantasai: where progress and stops and options of how you interpolate
fantasai: that's currently spec'd out
<fantasai> interpolate(<progress>, [ <position> : <value> ]#)
fantasai: we wanted to publish these and bring people's attention and
if anyone has concerns or suggestions (re. commas or
semicolons)
fantasai: that's kinda where things are at
fantasai: wanted to check-in with the WG and ask if we can update
the WD
fantasai: one of the interesting thing is that when you define a stop
we allow numbers / percents / lengths
fantasai: when you have an absolute progress and need to create this
kind of map
fantasai: from progress to output, the interesting case is if you're
mixing percentages and absolute values
fantasai: so we take the first and last absolute points, and those
are 0 and 100%
fantasai: and that's how you build the map
fantasai: if you have feedback on that we'd love to hear it
emilio: Is there any sorting of stops? E.g. in gradients.
emilio: at what point to percentages resolve?
fantasai: we pin things then we do the gradient stop fixup rules
<fantasai> See
https://drafts.csswg.org/css-values-5/#interpolation-normalization
miriam: maybe tangential, but progress() returns a number between 0
and 1
miriam: can it be used directly or needs to be converted to something?
fantasai: percents and numbers are called proportional, and they get
treated similarly
fantasai: if you have proportional input, then all the stops need to
be proportional values
fantasai: (i.e. numbers or percents)
RESOLVED: Republish the WD
CSS Backgrounds
===============
Using logical keywords in background-position shorthand with multiple
backgrounds
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12132
fantasai: it gets tricky how to expand background properties that
contain both physical and logical shorthands
fantasai: proposal is introducing a defer keyword which defer to the
opposite's coordinate system value
fantasai: so if I have `bg-position-x` and `bg-position-inline`, then
`defer` gets ignored and the shorthand can expand into all
properties
oriol: how this longhands work is quite unclear to me
oriol: they're supposed to form a logical property group
oriol: but there the pairing of logical and physical properties share
a computed value
oriol: does defer get resolved at computed value time?
oriol: also grammars are different
weinig: can clarify that
weinig: defer would not exist at computed value time, for the
background the keywords never make it to the computed value
time
weinig: it's currently replacing what currently is the empty string
weinig: so when you read the logical version at specified time it
gives you the empty string
weinig: which works fine when you don't have a list
weinig: so it's just kinda replacing the empty string
weinig: we could also use defer for non-list properties
weinig: but I don't have a strong feeling either way
<fantasai> +1 to using for all properties, not jus
dbaron: if I'm understanding this correctly then implementing it
requires doing additive cascade
dbaron: which has a lot of use cases
dbaron: and I think we should flesh it out
<bramus> +1
weinig: what is additive cascade?
dbaron: basically instead of overriding the pre-existing values, you
add to your background list or counter-reset list
fantasai: I don't think this is quite that
fantasai: it just lets you say that the value of this item in the
list is taken from the value of a different property
dbaron: right but to implement it you need to sort of search further
back
dbaron: in this case there's sort of at most two declarations involved
fantasai: and for different properties
fantasai: so you do the whole cascade and you end up with declared
values for -x/-y/-block/-inline
fantasai: similar to margin longhands / shorthands
emilio: I think the model wasn't quite clear. I agree with Oriol that
this feels odd. It's not quite the same as margins, for
example
emilio: because there you map the property while you're doing the
cascade
emilio: here the specified values ...
emilio: Not necessarily opposed, but it feels awkward
emilio: but don't have a suggestion
SebastianZ: My point was regarding when you setting 'defer' on the
longhands, what should we do?
SebastianZ: fantasai suggested 2 options, we need to decide on those.
weinig: If you do have a concern, providing a syntax example -- I
tried to show in the issue, with each thing, put examples to
help think it through
weinig: so be specific with your concerns
Received on Thursday, 3 July 2025 22:34:08 UTC