[CSSWG] Minutes Extended Telecon 2023-03-13 [motion-path] [css-display-4] [css-align] [css-flexbox] [css-grid] [css-shadow-parts]

  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
  - 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.


Agenda: https://github.com/w3c/csswg-drafts/projects/37

  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
           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
  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
  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
  TabAtkins: so by default won't affect the default behavior
  TabAtkins: if you do nothing special, your ray will come out of the
  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
  TabAtkins: so that's the core use case for ray()
  TabAtkins: So I think that would be the most sensible behavior going
  TabAtkins: and might be reasonably compatible with the content out

  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/
  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
  <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
  astearns: Objections?

  RESOLVED: Default box used by 'auto' value of 'offset-anchor' is box
            specified by 'transform-box', so it matches box used by

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
  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
  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
  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
  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
  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
  fantasai: and then interpolated between the two at the angles
  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
  TabAtkins: Old one wanted chord geometry is harder
  TabAtkins: Question is how much pull in the box to make it actually
  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
  florian: Last time we worked on this, was triggered by work on round
  florian: That faded, but Jihye is back maybe we can ask her to
  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: Reading order for grid and flex
  rachelandrew: Elika wrote in the spec edits for
  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

  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
  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
  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
  fantasai: I think there are people who care about a11y but not
            deeply, and will learn a best practice is to set it
  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
  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
  rachelandrew: But we couldn't think of use-cases where using "auto"
                didn't work, when discussing it with Chrishtr and
  iank: as-is, with integer value, it's not really adding value to
  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
  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
  florian: Also the overlapping capabilities of grid pose
  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
  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
  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
  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
  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
  [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
  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
  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
  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

  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
  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
  <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
  fantasai: We might also want the original light dom relationship
  fantasai: But definitely think we need based on the slotted
  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
  <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:
  <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
  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:

Received on Saturday, 18 March 2023 22:02:54 UTC