- From: Dael Jackson <daelcss@gmail.com>
- Date: Sat, 18 Mar 2023 18:02:09 -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.
=========================================
Motion Path
-----------
- RESOLVED: Add "at <position>" to path(), shape(), and ray() (FXTF
Issue #504: offset-position + circle())
- RESOLVED: Add 'normal' keyword to 'offset-position' (FXTF Issue
#504)
- RESOLVED: Default box used by 'auto' value of 'offset-anchor' is
box specified by 'transform-box', so it matches box used
by 'transform-origin' (FXTF Issue #503: anchor-position
- which box?)
- RESOLVED: offset-position: auto uses offset-anchor point (FXTF
Issue #501: offset-position:auto has bad behavior)
- RESOLVED: offset-anchor:auto uses transform-origin point (FXTF
Issue #502: offset-anchor:auto is nonsensical)
- RESOLVED: Use half width/height for horizontal/vertical rays,
interpolate for other angles (FXTF Issue #363: The
description of contain flag in ray() function)
- RESOLVED: For sides value, have snugness (FXTF Issue #363)
CSS Display
-----------
- RESOLVED: Land the PR, after addressing pending feedback (PR
#8257: Define 'reading-order: auto')
- The concern about needing reading-order:auto on the children
will be raised in a separate issue.
Align, Flexbox, & Grid
----------------------
- RESOLVED: first/last baseline takes from the first/last item
(rather than taking highest/lowest baseline) (PR #8341:
Improve container baseline finding algo)
- Issue #7641 (How to determine the last baseline of a flex
container with different alignment groups) should be resolved by
the above PR. There are some cases that need further
investigation and will have separate issues opened.
CSS Shadow Parts
----------------
- In discussing issue #7922 (Make `::slotted()` a combinator), it
was raised that there is existing confusion with named slots as
illustrated in this codepen: https://codepen.io/castastrophe/pen/yLXpagw
The group discussed this for the remaining time on the call, but
did not come to a resolution. A separate issue will be created
to track this topic.
===== FULL MEETING MINUTES ======
Agenda: https://github.com/w3c/csswg-drafts/projects/37
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Emilio Cobos Álvarez
Elika Etemad
Robert Flack
Daniel Holbert
Brian Kardell
Jonathan Kew
Eric Meyer
François Remy
Cassondra Roberts
Alan Stearns
Miriam Suzanne
Chair: astearns & rossen
Scribe: fantasai
Scribe's scribe: TabAtkins & florian
Agenda Shuffling
================
ACTION: fantasai find extra agenda items for Wednesday
<emilio> astearns: If we can add
https://github.com/w3c/csswg-drafts/issues/8564
at the end of Wednesday's call it'd be great :)
<emilio> Should be fast and blocks color-4 work we're doing
Motion Path L1
==============
TabAtkins: Motion is in Interop 2023
TabAtkins: There was a bunch of things that weren't editing in quite
write
TabAtkins: I did some rewriting
TabAtkins: but there's a bunch of stuff that's open questions
TabAtkins: I wanted to change / clarify a few things, so issues
offset-position + circle()
--------------------------
github: https://github.com/w3c/fxtf-drafts/issues/504
TabAtkins: About the interaction of offset-position and circle() etc.
TabAtkins: originally offset-position was replacement for left/top
TabAtkins: could use polar
TabAtkins: When we changed to transforms, it got weird
TabAtkins: After discussion years ago, we came to some moderate
conclusions that we wanted offset-position to apply to
the ray() function and path() and probably nothing else?
TabAtkins: Benefit was offset-position has a way to say "use my
current position" which seemed useful for things like SVG
path, which are in global coordinate space
TabAtkins: starting a path from "right here" was useful
TabAtkins: that wasn't edited in
TabAtkins: It ended up affecting circle() and ellipse(), to set the
center
TabAtkins: rather than defaulting to center like css-shapes
TabAtkins: My proposal is to pursue the original intent in the
thread to allow path() to also be relative as well
TabAtkins: making things consistent, taking ray/path/shape and
giving them all an "at <position>" syntax that sets the
starting point
TabAtkins: For path start at 0,0, for ray at center
TabAtkins: if you omit, will take value from offset-position
TabAtkins: Paired with this, since we want shapes to default
differently, we'd add a new 'none' value to
offset-position
TabAtkins: so by default won't affect the default behavior
TabAtkins: if you do nothing special, your ray will come out of the
center
TabAtkins: which is generally what people want?
TabAtkins: It keeps these two things consistent
TabAtkins: So 1) add "at <position>" to all things
TabAtkins: 2) add 'none' value to offset-position to not affect
shape functions
TabAtkins: 3) ???
TabAtkins: Other functions don't affect
TabAtkins: but for ray/path/circle/ellipse, seems to make sense
TabAtkins: Note this spec is very inconsistently written
TabAtkins: and very little interop
TabAtkins: part of reason why under interop 2023
TabAtkins: very hard to do anything consistently
TabAtkins: anything we do will break stuff
dbaron: I tried to use Motion Path to cause an element to maintain
its own position, couldn't do it interoperability
<dbaron> (the test I was working on was
https://dbaron.org/css/test/2018/stacking-context-z-order )
fantasai: I don't have the history of all this loaded up
fantasai: Not 100% sure I want to sign off because I'm not sure what
we were trying to do.
TabAtkins: auto is the box's current position
fantasai: So you're proposing a none value, which uses the default
position for each function
fantasai: And what's the default value? still auto?
TabAtkins: No, it's none
TabAtkins: Path starts at 0,0, but ray looks at offset-position
TabAtkins: If we default to auto, paths will change, if we default
to none, rays will change
TabAtkins: for rays defaulting to center is almost always what you
want
TabAtkins: so that's the core use case for ray()
TabAtkins: So I think that would be the most sensible behavior going
forward
TabAtkins: and might be reasonably compatible with the content out
there
fantasai: First comment if none is supposed to mean the default,
then maybe it should be called normal instead
fantasai: Currently, if you don't specify anything for path, it'll
be auto
TabAtkins: Path has no way to specify a position, so it goes by the
containing block's origin
fantasai: and that's interoperable?
TabAtkins: Probably, no change in spec in a long time
fantasai: For ray?
TabAtkins: It pays attention to offset position
TabAtkins: no way to set the position otherwise
fantasai: You want to make them consistent by making them start at a
default value
fantasai: The alternative would be for both to start at the
element's own position
TabAtkins: Yes. I think the common case for path will not like that
TabAtkins: ray will want to center
TabAtkins: So usecases are probably better served by a default value
than the element's own position
fantasai: Not 100% sure…
PROPOSED: Add "at <position>" to path(), shape(), and ray()
PROPOSED: Add 'normal' keyword to 'offset-position'
astearns: That matches what's already in circle and ellipse?
TabAtkins: Yes
RESOLVED: Add "at <position>" to path(), shape(), and ray()
astearns: Any question on the second resolution?
RESOLVED: Add 'normal' keyword to 'offset-position'
anchor-position - which box?
----------------------------
github: https://github.com/w3c/fxtf-drafts/issues/503
TabAtkins: Most offset stuff refers to containing block for sizing/
positioning
TabAtkins: exception is offset-anchor, which specifies point that
anchors to the path
TabAtkins: This needs to refer to one of the element's boxes
TabAtkins: spec just says "a box"
TabAtkins: doesn't say which one
TabAtkins: The obvious one would be to use border box
TabAtkins: but since it's a transform, might want to synch up with
other transforms
TabAtkins: I suggest using 'transform-box' property
TabAtkins: This would also default it to border-box, because that's
what 'transform-box' defaults to, which is good
TabAtkins: but it would let you match, if you change the transform
thing
<fantasai> wfm
florian: Seems reasonable
PROPOSED: default box used by 'auto' value of 'offset-anchor' is box
specified by 'transform-box', so it matches box used by
'transform-origin'
astearns: Objections?
RESOLVED: Default box used by 'auto' value of 'offset-anchor' is box
specified by 'transform-box', so it matches box used by
'transform-origin'
offset-position:auto has bad behavior
-------------------------------------
github: https://github.com/w3c/fxtf-drafts/issues/501
TabAtkins: When using offset-position: auto; and offset-anchor
TabAtkins: offset-position means "start from box's position"
TabAtkins: offset-anchor says which point you put on the path
TabAtkins: As written, offset-position uses top left corner
TabAtkins: offset-anchor uses center
TabAtkins: means that by default you get this slight shift
TabAtkins: Seems bad and weird
TabAtkins: I think this is one of the things that fell through the
cracks
TabAtkins: My proposal is when offset-position: auto is used, we
start from the offset-anchor point
TabAtkins: so wherever the box is, that's where it will start from
TabAtkins: and will start moving from that point instead of shifting
a little bit
TabAtkins: The examples show that the current behavior is expected,
but seems bad
<fantasai> +1
PROPOSED: offset-position: auto honors offset-anchor
florian: Only bit that worries me is that we don't know why we
decided the way we did
TabAtkins: Reason why was probably because we based it on the
position stuff
TabAtkins: If you wanted a ray from the center, easiest way is left:
50%; top: 50% which puts your left top in the center
TabAtkins: to actually center your box, you'd have to use a
transform hack
TabAtkins: with previous resolution, you could just say ray(at
center) and get the behavior you want
TabAtkins: I think this was just confluence of a slightly weak
feature and interaction with position
florian: Seems convincing enough
RESOLVED: offset-position: auto uses offset-anchor point
offset-anchor:auto is nonsensical
---------------------------------
github: https://github.com/w3c/fxtf-drafts/issues/502
TabAtkins: The definition of offset-anchor: auto just copies over
the offset-position value if that's not auto
TabAtkins: The reason for this was, if you specify offset-anchor:
auto; offset-position: %
TabAtkins: then you would get a behavior similar to
background-position
TabAtkins: where 100% put the element at the bottom right edge
TabAtkins: That's not unreasonable
TabAtkins: but if offset-position is not using percentages, you
interpret 100px e.g. relative to the element's own box
TabAtkins: which means the element doesn't move at all!
TabAtkins: That's really weird behavior and definitely unintended
TabAtkins: It's also not necessary if we do the other fix if we do
the other fix of starting from offset-anchor
TabAtkins: if you want bottom right corner, you set both to the same
value
TabAtkins: Very simple to get this behavior without the weird hack
TabAtkins: so propose to drop this behavior, offset-anchor: auto
just uses transform-origin
TabAtkins: since we need a default value, and good chance you'll
want to use the same transform-origin as other transforms
florian: In all cases, or just when offset-position is not using %?
TabAtkins: In all cases
astearns: Any objections?
RESOLVED: offset-anchor:auto uses transform-origin point
The description of contain flag in ray() function
-------------------------------------------------
github: https://github.com/w3c/fxtf-drafts/issues/363
<TabAtkins> https://drafts.fxtf.org/motion-1/#valdef-ray-contain
TabAtkins: When we first talked about motion path, I didn't realize
how much needed fixing
TabAtkins: First thing was that contain flag was over-complicated
and didn't do what we wanted it to do
TabAtkins: I proposed some simplifications, supported by FF and
Blink implementations
TabAtkins: Basically you take the larger of width or height, and
subtract that from the ray
TabAtkins: In the common case of you start the ray from the center
and get digits around a clock face, they will sit a
consistent distance from the edge no matter what angle
you're using
TabAtkins: in other cases where elements aren't round or ???
TabAtkins: You'll get similar behavior, it will be
direction-agnostic, but not exactly the same as the old
spec
TabAtkins: but should be close
florian: If old spec didn't do what it meant to do, not losing
anything, but can we gain something and do what old spec
meant to do?
TabAtkins: I don't know what it meant to do
TabAtkins: afaict, it was optimized for the sides value for ray,
which made the ray ?? angle-dependent
TabAtkins: Old spec if rectangular, you would get snug against the
edge of the box
TabAtkins: for any other case, it was just wrong
TabAtkins: because it made sure that rectangle fit against the
element
TabAtkins: Square fits into circle more closely when axis-aligned
and less so when [missed]
TabAtkins: so I think it was one way to interpret the way the
intent, but a bad way
fantasai: If you're working with rectangles (or ellipses) rather
than circles and squares
fantasai: you won't get a snug fit because of the difference in
width/height -- we're only using the largest, so it fits
in one axis and not in the other
fantasai: What if we used width in horizontal axis and height in the
other
fantasai: and then interpolated between the two at the angles
in-between?
TabAtkins: That's identical if element is square, but not
unreasonable if element is off-square
TabAtkins: it does mean we regain angle dependence, but not strictly
a bad thing...
TabAtkins: I guess I'm ok with that. Do a sinusoidal interpolation
between half width and half height
florian: That sounds like a good idea to me too
astearns: So proposal is to change spec to use half of width/height
and interpolate between the two?
TabAtkins: Yes, then a wrinkle based on that
astearns: objections? concerns?
RESOLVED: Use half width/height for horizontal/vertical rays,
interpolate for other angles
TabAtkins: Old spec worked great for the "sides" value of ray,
always fit against containing block edges
TabAtkins: worked badly for other things
TabAtkins: When I simplified, doesn't quite work as well for sides
TabAtkins: but thought it was acceptable loss
TabAtkins: but if we're regaining angle dependence, I think it's OK
to break simplicity a tiny bit more
TabAtkins: and say that for sides value, we do calculate the
intersection bit
TabAtkins: Much easier in this case because it's rectangle against
rectangle
TabAtkins: Old one wanted chord geometry is harder
TabAtkins: Question is how much pull in the box to make it actually
fit
TabAtkins: that's relatively easy math, I can put in the spec
astearns: Sounds reasonable
astearns: Proposed for sides value we will have snugness
astearns: Objections?
RESOLVED: For sides value, have snugness
TabAtkins: That's it, just need a decision on the initial value of
offset-position
florian: Last time we worked on this, was triggered by work on round
display
florian: That faded, but Jihye is back maybe we can ask her to
review?
TabAtkins: I did some issue archeology, so pretty sure I captured
intent, but happy to ask her for review
CSS Display 4
=============
scribe: TabAtkins
Define 'reading-order: auto'
----------------------------
github: https://github.com/w3c/csswg-drafts/pull/8257
<rachelandrew>
https://github.com/w3c/csswg-drafts/pull/8257#issuecomment-1416683499
rachelandrew: Reading order for grid and flex
rachelandrew: Elika wrote in the spec edits for
reading-order:<integer>
rachelandrew: Lets you change the order relative to the dom
rachelandrew: and "auto" which only works for things that are
"randomized" layout, like dense-order packing
rachelandrew: Where the author can't predict ahead of time what the
order is
rachelandrew: As I was writing an article for dev feedback, it was
very obvious that for most things we just need
reading-order:auto on the children
rachelandrew: And make it apply to all layout methods
rachelandrew: If they wanted order to follow layout order, if
children have "auto" this happens
rachelandrew: Elika doesn't want this because she doesn't want to
make it too easy for devs to do this (setting layout
order rather than changing dom order)
rachelandrew: But it seems very obvious that we'll be making things
ergonomically difficult
rachelandrew: Seems a bit odd, want to make sure we really do intend
that.
fantasai: I haven't seen your examples, so less context, but
fantasai: The thing I'm concerned with is devs won't think about
spec order, just set `* { reading-order:auto }` and think
they've solved the problem
fantasai: But this doesn't actually use the right behaviors in many
cases
fantasai: Many cases where people reorder source in order to get the
speech order and layout order to be different on purpose,
because the two perceive the document differently
fantasai: For example, an image and a heading, you want the image
above the heading in layout, you want the heading first in
source
fantasai: So the reason we added 'order' was to enable that case
specifically, not to enable "can sort anything with the
'order' property"
rachelandrew: Those cases are handled by "order" already, as long as
you don't set reading-order:auto
fantasai: Yeah, my concern is just that people will set it on "*" in
their stylesheet
rachelandrew: Are those people already failing to do this stuff
correctly?
fantasai: I think there are people who care about a11y but not
deeply, and will learn a best practice is to set it
everywhere
rachelandrew: We can publish against that
rachelandrew: My concern is that we're adding complexity just to
prevent things
rachelandrew: Another concern is that if we say "auto" is only for
random layouts we can't change that in the future;
while we were just integers it was still open.
fantasai: I'm fine with adding a different keyword for randomized
layout and using "auto" for this purpose.
fremy: I think I agree it doesn't make sense for "auto" to not use
layout info when you can. I think it'll be what people want
most of the time.
fremy: I disagree it can be used for everything. For grid there's no
obvious reading order, mentioned in the issue
fremy: "auto" makes it seem like there's always an obvious choice
fremy: We can't ask authors to add 1, 2, 3, etc; can't do that with
an unknown number of elements.
fremy: I think this needs a more specific proposal for
layout-by-layout.
fremy: So I don't think it makes a lot of sense for grid, don't buy
that "you just need auto" is true
rachelandrew: I think more work is needed, but - what I'd like is
more feedback from devs.
rachelandrew: At the moment we'll be asking for feedback with a
suggested spec that is making things difficult, that
might affect the feedback.
rachelandrew: There were def issues around flex-direction, for
example
rachelandrew: But we couldn't think of use-cases where using "auto"
didn't work, when discussing it with Chrishtr and
others.
iank: as-is, with integer value, it's not really adding value to
webdevs
iank: Don't think people will actively use it
astearns: Next steps?
fantasai: I'd like to pull Rachel's discussion out of the PR and
into an issue
fantasai: The PR was about following up what was already resolved,
just needed Oriol's review on technical aspects.
fantasai: So I'd like to land Oriol's feedback, and discuss
additional changes in an issue.
fantasai: Haven't looked at Rachel's article so don't have the same
context
fantasai: But I am definitely concerned that there will be articles
saying "just use 'auto' to handle speech"
florian: Seems fremy's direction wouldn't take us there - if we have
several autoish values there's no single answer to rely on.
iank: And in flexbox you sometimes want opposite order for reading.
For grid, could want column-major and row-major.
iank: So there are some high-level directionalities for particular
layouts.
florian: Also the overlapping capabilities of grid pose
possibilities.
florian: Dunno if we need to expose all of them with keywords, but
should think through it
astearns: Rachel would you be okay landing this PR and opening an
issue?
astearns: So resolution today is accept this PR once Oriol's
concerns are handled?
fantasai: Yeah, wanna address Oriol's concerns.
florian: Want to inline an issue into the PR saying "auto" name can
change?
fantasai: Yeah, can do, pointing at Rachel's issue. Might be
redesigning the feature, rather than just renaming
astearns: So resolution is we land this PR after addressing feedback
RESOLVED: Land the PR, after addressing pending feedback
Align, Flexbox, and Grid
========================
Improve container baseline finding algo
---------------------------------------
github: https://github.com/w3c/csswg-drafts/pull/8341
fantasai: When Tab and I were drafting the fixes, we ran into a few
questions
fantasai: wanted to ask WG
fantasai: There was some confusion whether we resolved to take
baseline from "first" item or "highest" item - discussion
about highest, but resolution said first.
fantasai: Second is, if we take highest, what to do in a tie?
Rossen: Is there a reason we're not using first? I presume this was
originally what the text says
Rossen: Seems reasonable for the "first" keyword
fantasai: This is in a grid row or similar, not clear which is
"first"
fantasai: first and last refers to whether you take from the first
or last linebox, or row
fantasai: for lineboxes there's a definite baseline
fantasai: For rows (flex rows, multicols, grid rows) it's less clear
fantasai: For multicol we resolved to take the highest baseline
iank: Yeah for multicol we take the highest/lowest
iank: Mostly because first/last column might not have a baseline
iank: Tables probably have some historical stuff
<fantasai> https://github.com/w3c/csswg-drafts/issues/7641#issuecomment-1292240713
iank: For flexbox and grid, suspect we want first/last, because it's
more likely to match the adjacent content
fantasai: In October you suggested taking the highest line
iank: Yeah not sure I thought it through at the time
iank: I think it may make a little more sense to do first/last, but
can go either way
Rossen: It sounds like everyone but Chrome is doing first/last?
Rossen: Firefox/WK do first, Chrome NG does highest (per issue)
iank: Not sure if that is correct.
iank: I think I'm fine with whatever makes sense to other people
<iank> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=11394
Rossen: So do we have strong use-cases where we *don't* want the
first/last one?
dholbert: I can imagine if the first flex item was an image, second
is text... but even there highest isn't necessarily better
fantasai: It would take from the text there
dholbert: Unless the image was small
fantasai: It'd have to be *really* small, smaller than the first
line, which seems unusual
Rossen: I can't think of where you'd want to choose other than first
or last one
iank: I think Firefox's behavior in this test case shows a weird
behavior for last baseline
<iank> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=11395
dholbert: I think our last-baseline support is just buggy right now
iank: I think everyone currently implements taking first or last item
iank: But happy to change if necessary
Rossen: Okay, let's resolve on first/last, if we get a strong case
to do different we can change it
Rossen: For now we have proof of some compat for first/last
RESOLVED: first/last baseline takes from the first/last item (rather
than taking highest/lowest baseline)
How to determine the last baseline of a flex container with different
alignment groups
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7641
Rossen: Should we consider this issue resolved by the PR discussion?
fantasai: Yeah
iank: Clarification - are we still taking the first baseline from
the topmost row and bottommost row?
fantasai: Yeah?
iank: One subtlety with last issue around reverse flex
iank: What would be the behavior with a reverse flex?
fantasai: Not sure, let me see if the spec handles that right now,
if not we should resolve to handle it
iank: I think I have relatively strong behavior on this, I think our
new behavior makes sense
fantasai: We took the startmost or endmost flex line
iank: So first baseline from the visual top (basically) and last
from visual bottom?
fantasai: Yes
<iank> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=11393
iank: Can you check chrome's behavior in the testcase I just posted?
[people look at the example]
fantasai: Yeah this looks right
fantasai: although... did we define alignment across multiline items?
[more clarification of the example]
iank: I think in [missed case] we'll still do visual bottom/top
<iank> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=11396
fantasai: If you wrap the columns, are you doing baseline alignment
across the topmost items in each line? Because we could...
Rossen: Let's open an issue for these additional wrinkles
CSS Grid
========
Distribute extra space into non-intrinsic tracks instead of going
beyond growth limits
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3648
fantasai: I flagged this as f2f because it needs whiteboard
discussion
[we're punting for now because it's very complicated and wants
proper set up]
<fantasai> SUMMARY: Would benefit from whiteboard discussion
CSS Shadow Parts
================
Scribes: fantasai & TabAtkins
Make `::slotted()` a combinator
-------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7922
lea: ::slotted() is a pseudo-element
lea: This doesn't really solve author's problems though
lea: Four issues in the issue
lea: Can't use in querySelector
lea: Can't target children of slotted elements
lea: etc, lots because it's just a pseudo-element
lea: The WC community has chimed in and seem to think making this a
combinator would solve these
lea: ::part() might have a similar approach but is more complicated
to avoid exposing too much info, but ::slotted() refers to
things in the light dom so it's not exposing anything too bad
lea: Discussing with fantasai, we don't see any issues spec-wise,
but want to hear from impls
emilio: ::slotted() can also match in the shadow dom, it matches
fallback content per spec (but unsure how well that's
implemented)
emilio: Also as-is ::slotted() depends on which shadow tree you're in
emilio: Also I think we do support ::slotted()::before, etc
emilio: probably not non-tree-abiding pseudos
emilio: If we don't support it, we should
castastrophe: My one concern with adding complexity to ::slotted(),
there is already some confusion as to how it's applied
castastrophe: I have a codepen, like :first-child is first child in
the DOM, not based on first in the slot
<lea> castastrophe: would love a link to the codepen!
<Rossen> https://codepen.io/castastrophe/pen/rNKjLVj?editors=0010
castastrophe: So would be useful to clarify how things resolve
relative to slot ordering, etc
<castastrophe> Referenced codepen: https://codepen.io/castastrophe/pen/yLXpagw
TabAtkins: I feel like that might be the reason we ended up
designing ::slotted() the way it is, because you *can't*
have sibling relationships
TabAtkins: unless it's a little more clear what context it's
evaluated it
TabAtkins: but the rest of the issues lea brings up seem to be
accidental damage
TabAtkins: Not being able to descend into slotted element, no reason
not to allow that
lea: The point emilio brought up is good, that sometimes these
elements can also be in the shadow DOM
lea: what if the slotted combinator didn't match such fallback
content, only the author-provided elements
lea: but not sure if it satisfies the use cases, something to thin
about
lea: I wonder if /slotted/ not matching fallback content would make
sense. Not sure if it would still satisfy use-cases tho
TabAtkins: If you did want to distinguish other proposal to having a
pseudo-class for whether using fallback content or not
TabAtkins: :has-slotted or something?
<lea> I think you can style fallback content with regular shadow DOM
CSS, so it doesn't seem to be much of a problem at first
glance?
castastrophe: I think named slots is a bit of a challenge, what does
light dom look like in multiple named slots
castastrophe: The codepen does show the confusion about the elements
having a relationship in the light dom vs in the slots
lea: I think you can style fallback content with regular CSS in the
shadow.
TabAtkins: Emilio, you said that the ::slotted selector can match
differently depending on which shadow tree it's coming
from, what did you mean?
fantasai: So first thing to think about is, if we add this, would we
use the slotted relationship or the light dom relationship
fantasai: I think using the slotted relationship would be more
understandable but not sure
lea: Explain?
TabAtkins: Say you're slotting all the even elements
TabAtkins: and you asked :nth-child(2)
TabAtkins: Is this the 2nd slotted item, or the 2nd item in the
original DOM?
lea: We'd need to figure out what the author expectations are
TabAtkins: I expect there's complexity in evaluating on the slotted
list
lea: Intuitively to me, as an author, it seems like the light dom
relationship makes more sense
TabAtkins: Wanting to style first/last items in the slot using
:first-child/:last-child is reasonable case
castastrophe: There's a lot of confusion over named slots
castastrophe: e.g. if you pull things into named slots, currently
:first-child is only if it's the first child in the
light DOM
castastrophe: but not if it's the first child in the slot
castastrophe: I think we'd need to be very clear in the spec
emilio: Regarding what we talked before, matching where the
selector is
emilio: in the case of nested slots, it would jump across to slots
in the current shadow tree
emilio: That's the behavior I was talking about before
castastrophe: If you have a slot that's passing content to a shadow
template that also has.. if you have multiple?
emilio: From outer tree, slotted pseudo would cross that nested slot
emilio: the outer shadow tree
emilio: so you could still style the slotted contents ...
emilio: I need a whiteboard to reason about nested slots!
emilio: but I'm sure we jump across to the right scope
emilio: That scope is dependent on the tree that we're looking at
right now
Rossen: I'm hoping that made sense to you, Tab?
TabAtkins: I don't know that's necessarily right...
TabAtkins: I'd have to look up again the slot assignment algorithm
TabAtkins: I forget, if you're in nested slot, if we match the slot
element from higher up or the things slotted in that
element
<TabAtkins> Oh, it's after flattening
fantasai: I think we definitely need ability to style based on the
slotted relationships
fantasai: as brought up before
fantasai: if you're pulling a subset of items into a slot, e.g. into
a list
fantasai: and you want to style every other item with :nth-child(),
you want to get every other slotted item
fantasai: not a random set of items based on what was selected or
not from the light DOM
fantasai: Similarly, as was brought up earlier for first/last child
styling
fantasai: We might also want the original light dom relationship
fantasai: But definitely think we need based on the slotted
relationship
fantasai: Since ::slotted() currently works based on light dom, one
possibility would have ::slotted stay with that, but
/slotted/ shift into "the slotted view of the world"
fantasai: we've discussed different ways to shift your view of the
world, one of which was using subtrees under
pseudo-elements
<bkardell> Does that not imply that you know something about the dom
inside the shadow root then?
lea: There are two relationships, one based on relationships in
light dom or slotted tree
lea: is one easier to implement than the other?
Rossen: Does anyone have an answer?
emilio: slotted thing is new thing, so you need to somehow decide on
?? child matching vs
emilio: other thing is storage of slotted children different
Rossen: Sounds like light DOM is easier
emilio: But probably not impossible to make slotted work
castastrophe: I agree, I think light DOM would be less complex
castastrophe: because that relationship is flat
<lea> Light DOM is easier to implement because that's the current
behavior of ::slotted(), but does anyone have any feel of the
implementability of the other option?
castastrophe: I was just making notation, but I think the nested
shadow DOM is getting the slot element, not the
slotted content
castastrophe: it renders it correctly, but when using CSS selectors
castastrophe: you don't have access to the slotted content until
further down
castastrophe: So I think it's just the tag <slot> in nested shadows
castastrophe: so I think we need to open a new issue for how we
build styles for named combinators
castastrophe: Need to identify the named slot and the combinator in
the same query
<emilio> I need to check what this `while` loop is doing then:
https://searchfox.org/mozilla-central/rev/af78418c4b5f2c8721d1a06486cf4cf0b33e1e8d/servo/components/selectors/matching.rs#464-468
<emilio> castastrophe: if you have a codepen for that nested shadow
example I'd love to check it out
TabAtkins: So Cas, if you've been seeing the slot element matched by
::slotted in deeply nested situations, that is spec
violation
TabAtkins: because should flatten and get the real elements
TabAtkins: so the slotted inside the nested part should see the
original light dom elements, not the slot
Rossen: It sounds like we'll end issue without a concrete resolution
Rossen: let's pick it up again on Wednesday
Rossen: We're about 60% slower than anticipated
Rossen: If there's more to pick up on this we can return on Wed,
otherwise we'll pick up with the rest of the Agenda
Rossen: Next is 8am Pacific on Wed
<castastrophe> Created the issue:
https://github.com/w3c/csswg-drafts/issues/8577
Received on Saturday, 18 March 2023 22:02:54 UTC