- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 8 Jan 2025 20:10:59 -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 Inline
----------
- RESOLVED: text-box-trim does not change height contribution of
inline (Issue #10834: inline boxes and line-fit-edge vs
text-box-trim/edge)
- fantasai will make a testcase for the above resolution and report
back on WebKit/Chrome implementation status.
- RESOLVED: If text-box-trim reduces the effective height of the
inline box compared to line-fit-edge, that amount is
propagated as a negative margin (the same way as a
specified negative margin is propagated) to inline
descendants (Issue #10384)
- RESOLVED: Apply text-box-trim to a column box or spanner iff it is
adjacent to the relevant edge (Issue #11363:
text-box-trim and multi-column containers)
CSS Selectors
-------------
- There was discussion around the naming decision for issue #10975
(:local-link should have a more precise name) but no clear answer
was discovered during the call. Discussion will continue on the
issue to outline possibilities.
- RESOLVED: `:has-slotted` should match when the fallback content is
not being displayed (Issue #6867: Pseudo-class to
indicate when a slot has content)
CSS Shapes
----------
- RESOLVED: Restrict ordering such that `to` or `by` would need to
come first (Issue #10666: Order of points and control
points in `shape()`)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2025Jan/0005.html
Present:
Rachel Andrew
Adam Argyle
Tab Atkins-Bittner
Kevin Babbitt
David Baron
Andreu Botella
Oriol Brufau
Keith Cirkel
Emilio Cobos Álvarez
Yehonatan Daniv
Stephanie Eckles
Elika Etemad
Robert Flack
Simon Fraser
Chris Harrelson
Daniel Holbert
Roman Komarov
Chris Lilley
Alison Maher
Eric Meyer
Jen Simmons
Gaurav Singh Faujdar
Alan Stearns
Josh Tumath
Bramus Van Damme
Jeffrey Yasskin
Sebastian Zartner
Regrets:
Brian Kardell
Jonathan Kew
Miriam Suzanne
Lea Verou
Scribe: kbabbitt
Administrative
==============
alisonmaher: Looking for responses on the F2F scheduling email for
the spring
alisonmaher: https://app.rallly.co/invite/VFdy8sxOY2WU
<TabAtkins> what was the survey email titled?
<alisonmaher> The email was titled "CSSWG F2F April 2025"
CSS Inline
==========
inline boxes and line-fit-edge vs text-box-trim/edge
----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10834
<fantasai> https://github.com/w3c/csswg-drafts/issues/10834#issuecomment-2540644321
fantasai: Problem statement is at (link in chat)
fantasai: we have a transparency principle that an unstyled inline
should have no effect on layout
fantasai: if I have some text in an <em> and insert a <span> that
should not affect formatting
<fantasai> <em>Some text</em> vs <em><span>Some text</span></em> must
be identical
fantasai: that means properties need to be inherited if they affect
inline layout
fantasai: question is what does text-box-trim do on inlines
fantasai: backgrounds and borders on inlines traditionally do not
affect layout and that's fine
fantasai: we also talked about text-box-trim impacting height of line
on an inline
fantasai: my conclusion is I don't think we should do that
fantasai: because if we set text-box-trim on an inline, e.g. on a
span, that will affect the line height because the inner
element now has a taller height
fantasai: I think we have to specify that when we are in default line
height mode, text-box-trim can change how backgrounds and
borders are drawn
fantasai: but it does not change the height contribution of the inline
fantasai: which remains based on line-height property
astearns: dbaron commented on different effects on blocks and inlines
fantasai: we have a distinction, it's called line-fit-edge
fantasai: that's a separate property which allows it to trim
fantasai: Proposal Part A: text-box-trim does not change height
contribution of inline
<dbaron> Part A sounds good to me
Proposed: text-box-trim does not change height contribution of inline
RESOLVED: text-box-trim does not change height contribution of inline
fantasai: Next part: we have a line-fit-edge property; it changes to
a new inline layout model
fantasai: where instead of using line-height as height contribution,
we use margin box edge
fantasai: in addition, it also lets you control which edge you use,
effectively setting default edge to be used
fantasai: and that inherits
fantasai: what we could do is have a negative margin
fantasai: negative margin ran into this transparency issue
fantasai: to solve it, we said negative margin is propagated to
descendant of inline box
fantasai: if we say text-box-trim is applied to this box and changes
where borders and padding are drawn, then it should
correspondingly affect height contribution
fantasai: but since it doesn't inherit, we somehow need to propagate
fantasai: in the same way as a negative margin would be
fantasai: Proposal is that, in this mode, the amount by which
text-box-trim reduces margin box is propagated as a
negative margin
<fantasai> PROPOSAL: if text-box-trim reduces the effective height of
the inline box compared to line-fit-edge, that amount is
propagated as a negative margin (the same way as a
specified negative margin is propagated) to inline
descendants
astearns: Is this propagation of negative margins a new thing?
fantasai: the line-fit-edge negative margin is a new thing, yes
astearns: concerned this new thing may have side effects
dbaron: Right now we already have these rules for special propagation
of negative margins when you have line-fit-edge in
non-default value
dbaron: proposal is that, when you use text-box-trim, in this case
where line-fit-edge has non-default value, then negative
margin gets propagated to descendants? in addition to other
negative margin?
fantasai: yes
dbaron: I think this makes sense, but we need to think about the
line-fit-edge model some more and test it some more
dbaron: but this proposal does seem to make sense to me
fantasai: agree 100%
astearns: Restating: the effect of text-box-trim contributes to the
negative margin that is assessed when line-fit-edge is
non-default and propagates to descendants
fantasai: correct
astearns: Not sure I understand repercussions, need to take a deep
look at this, but I'm fine with resolving on this
chrishtr: re: first resolution: is normal the default?
fantasai: yes
chrishtr: does that have an effect on chromium/webkit implementation
of text-box-trim
fantasai: I haven't tested that, not sure what implementations are
doing
fantasai: but it's only on inline boxes
chrishtr: could you take an action item to take on that?
ACTION: fantasai to make testcase and report back on WebKit/Chrome
implementation status
<RRSAgent> records action 1
chrishtr: bonus points for a WPT
PROPOSED: interaction between line-fit-edge and text-box-trim
contributes to a negative margin that is propagated to inline
descendants
RESOLVED: If text-box-trim reduces the effective height of the inline
box compared to line-fit-edge, that amount is propagated as
a negative margin (the same way as a specified negative
margin is propagated) to inline descendants
CSS Selectors
=============
:local-link should have a more precise name
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10975
keithamus: Headline features for these is that there needs to be a
way to differentiate links on a different origin vs
different parts of a hierarchical navigation
keithamus: e.g. on github.com/settings there might be sublinks on
that, we have a big menu, a little visual treatment to
show what page you're on
keithamus: many sites do this, this selector attempts to abbreviate
that
keithamus: look at URL of current page, parts of it
keithamus: selectors-5 currently just has local-link as a selector
keithamus: I would like to extend that
keithamus: jyasskin had some great commentary on that
keithamus: resolution I'm looking for is: what selectors to enable,
what to name them
keithamus: not sure if I made sufficient justification for
:local-link(n) but happy to make it
<fantasai> https://www.w3.org/TR/2013/WD-selectors4-20130502/#local-pseudo
fantasai: We had much more control in original version of spec
fantasai: there was a proposal to cut it down to a more minimal set
fantasai: if there's interest in making it more powerful that would
be fine
fantasai: but this issue is asking for a renaming
keithamus: topic is around the renaming but I'd like to discuss in
context of if we had a suite of these selectors
<jyasskin> And fwiw, the :local-link(n) is still in
https://drafts.csswg.org/selectors-5/#local-pseudo. It was
removed from level 4.
keithamus: there's a chance to approach this with a look at all of
them and get some symmetry
keithamus: to that end, we have [missed]-target already, should we
have same-*? same-target, same-origin, same-path?
<jyasskin> +1
fantasai: difference between origin and domain?
keithamus: I don't think there's a distinction between those. there
is between path and target
<andreubotella> IIRC the origins for HTTP and HTTPS in the same
domain are different
fantasai: for matching fragment, there was proposal in the thread for
:target-link
fantasai: expanding out to all those things [missed]
keithamus: symmetry would be :target-link, :local-link, ...
keithamus: would :local-link still exist as matching origin?
keithamus: or would we have :origin-link?
fantasai: previous proposal had :local-link(n) where n=0 represents
same domain, 1 represents same first segment, etc.
fantasai: one thing it didn't handle was query parameter, etc
keithamus: yes which is doable but difficult with one single selector
keithamus: because if you have an arbitrary path it can grow to an
arbitrary number
<fantasai> 1. :target-link matches including fragment
<fantasai> 2. :local-link matches page URL ignoring fragment
<fantasai> 3. :local-link(<integer>) matches domain + number of path
segments
astearns: jyasskin had concerns about using local in name
jyasskin: local is not great for this purpose because of what it
means in the rest of platform
jyasskin: we want CSS to be consistent with those
jyasskin: and not confuse people wrt other parts of platform
fantasai: I think we have a structure and need better names
jyasskin: origin vs domain - domain isn't great but there is a site
concept in other parts of platform which could be used here
jyasskin: not clear it's needed but could be right term
keithamus: one suggestion in thread is same-path, same-site
keithamus: same-path parameterized with an integer
keithamus: and then same-target
jyasskin: not sure target is exactly right, :target matches the thing
referred to by the active fragment, so it might not be the
right name when matching a link, but it's not terrible
astearns: context is that keithamus is implementing local-link
astearns: looking to ensure whatever gets implemented can get extended
keithamus: I've prototyped parameterized version in Chrome
keithamus: that's the version most useful to github
keithamus: bare one could visually treat intra-page navigations as
inter-page navigations
keithamus: lot of posts about cross-origin links
fantasai: what if we called it match-link?
fantasai: but that doesn't quite capture what you're matching
keithamus: I like the idea of saying dash-whatever, it matches the
problem space
<fantasai> `:self-link(<integer>)`
fantasai: also suggestion of self-link
keithamus: does self-path(3) ...
fantasai: you don't need to distinguish in that case
jyasskin: is it self-origin, self-path, ...?
fantasai: parameter 0 means site, 1 means site + 1 path segment
jyasskin and then keyword for fragment, parameters, etc?
fantasai: yes
<jyasskin> :self-link(path(3)) ?
keithamus: how would keywords look? positional parameters?
<jyasskin> :self-link(site)
keithamus: would both be precluded?
<fantasai> :self-link(<integer> | target || query)
astearns: like self a little more than same
flackr: self-link is from the proposal to generate pseudo-element
links from current element
flackr: in that discussion we talked about approaching it from
different direction
flackr: if we choose self-link here, we need to make sure we have
something that makes sense in that other context
fantasai: Maybe that one can be anchor-link?
<fantasai> ::anchor-link ?
flackr: maybe
jyasskin: hearing a bunch of concerns from CSS experts
jyasskin: shying away from same-path, same-site, same-origin
terminology
jyasskin: where they've been used in other parts of platform, curious
why that is
fantasai: we do want to have an integer parameter, right? once you
have that, that gets you site + path without a keyword
jyasskin: it gets you origin + prefix of path
fantasai: or a keyword or default value or something that specifies
full path
jyasskin: we still need something that specifies whole query
astearns: I was a little concerned about adding path and site and
origin
astearns: not sure authors have those concepts in mind
fantasai: we can add keywords corresponding to them if that would be
more user friendly
astearns: would it make sense to hold off on this and have a
discussion in upcoming f2f
<dbaron> (it might also help the discussion to define path and origin
for the rest of the group)
[jyasskin and keithamus both remark that they won't be able to be
there]
<jyasskin> Re dbaron: and site, query, and fragment.
<dbaron> (oops, I meant to say "site and origin" :-)
keithamus: I think there's a good direction for the semantics but
naming is where we got stalled
fantasai: suggest we sketch it out and put some suggestions down
CSS Inline Con't
================
text-box-trim and multi-column containers
-----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11363
fantasai: we talked about applying text-box-trim to multicol
containers
fantasai: said it applies to every column
fantasai: we didn't discuss what happens if there's a column spanner
fantasai: it can occur before or after the column box
fantasai: also you can have column boxes that span in the middle of
the multicol container
fantasai: and only want to trim the columns on the outsides
fantasai: I think we want to clarify
fantasai: suggest that we only target column boxes adjacent to edge
of multicol container
fantasai: and that we also trim spanners if present
astearns: we only target things if they are adjacent to the
appropriate edge?
fantasai: yes
rachelandrew: sounds good to me
rachelandrew: that would then work if we do block-direction overflow
for columns, same issue but without spanner
<fantasai> PROPOSAL: Apply text-box-trim to a column box or spanner
iff it is adjacent to the relevant edge
RESOLVED: Apply text-box-trim to a column box or spanner iff it is
adjacent to the relevant edge
CSS Anchor Positioning
======================
Was changing acceptable element algorithm intentional?
------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11170
TabAtkins: yes it was a mistake, I'll fix it
CSS Selectors Con't
===================
Pseudo-class to indicate when a slot has content
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6867
keithamus: tldr from thread is chrome has :slotted, it can match on a
few different things
keithamus: concept of flattened vs non-flattened tree
keithamus: flagged in firefox and chrome as non-flattened tree
keithamus: so it can match direct descendant of a slot
keithamus: some contention around this
keithamus: setting flattened to true would mean it would make child
slots transparent effectively
keithamus: so if you have a slot slotted by another slot then that
slot [missed]
keithamus: my opinion is we should keep behavior as-is
keithamus: that's the only way you can match slotted content
keithamus: even if it's just a text node as a descendant of a slot
element
keithamus: web components cg is asking for commitment that this is
acceptable
keithamus: as long as we define the alternatives to that
keithamus: chief use cases are: has my slot been populated? what has
it been populated with?
emilio: flattened true and flattened false - only effective
difference is nested slots right?
keithamus: that's true, has-slotted will always match populated text
nodes
keithamus: nested slots become transparent
[missed some context]
keithamus: how do you determine nested slots is the short summary
emilio: to me, flattened tree behavior is what I'd expect as an author
emilio: components that use nested slots... that becomes useless
emilio: a bit confused about when you'd want to differentiate between
useful slotted content and empty slot
emilio: why would you want flattened behavior?
keithamus: other way around makes more sense for that use case, am I
displaying default slotted content
emilio: right but if you have an empty slot you could do that?
keithamus: I don't think so?
keithamus: will have to test
<dbaron> (that would be my assumption ^)
emilio: my understanding is that you'd display default content of
nested slot
emilio: flattened behavior is easier but I'm surprised that's most
useful
emilio: would not object but might be worth checking
emilio: ideally has-slotted should reflect fallback content
keithamus: agree, that's my understanding of what flattened false
would do
emilio: assuming that's the case flattened false seems reasonable
emilio: if you want we can resolve that we make has-slotted match
fallback content
<keithamus> PROPOSED RESOLUTION: `:has-slotted` should match when the
fallback content is not being displayed
astearns: doesn't mention flat tree deliberately
astearns: but if it turns out flat tree is desired behavior, [?]
keithamus: need to confirm
keithamus: whether a slot would display fallback content
keithamus: but if that's the case it shouldn't use the flat tree, but
if it isn't then it should
RESOLVED: `:has-slotted` should match when the fallback content is
not being displayed
CSS Shapes
==========
Order of points and control points in `shape()`
-----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10666
smfr: previously we decided you could specify dest point and control
points in any order
smfr: later we added ability to specify control points in a way that
depended on relative/absolute to/by on dest point
smfr: possible to write segments where control points come first but
there's ambiguity on how to get to dest point
smfr: curve with top left by 10% 10%
smfr: which is invalid
smfr: you cannot read left to right, you cannot parse left to right,
have to maintain state to resolve `to` keyword
smfr: do we have a desire in CSS to make things valid when read left
to right?
<fantasai> curve with 10px 30px by 20px 20px
<fantasai> curve by 20px 20px with 10px 30px
TabAtkins: I'm fine with smfr's suggestion
TabAtkins: being able to know what coordinate space you're working in
early seems reasonable
fantasai: prefer to keep it reorderable but not a big deal
PROPOSED: restrict ordering such that `to` or `by` would need to come
first
fantasai: could decide later that it can be reorderable
RESOLVED: restrict ordering such that `to` or `by` would need to come
first
Received on Thursday, 9 January 2025 01:11:31 UTC