[CSSWG] Minutes Telecon 2023-05-17 [css-grid] [scroll-animations] [css-logical] [css-images] [css-overflow]

  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 Grid

  - There were three options outlined to resolve issue #7661
      (Application of grid-positioning properties to static position
      of grid children is inconsistent). Additional clarifications for
      the options will be added to github and then this will come back
      to the agenda in two weeks for a resolution.

Scroll Animations

  - RESOLVED: Switch timeline names to <dashed-ident> (Issue #8746:
              Require <dashed-ident> for timeline names)
  - RESOLVED: Remove scroll/view-timeline-attachment, add
              timeline-scope, which accepts a list of timeline names
              and raises their scope (Issue #7759: Broader scope of
              scroll timelines)
  - RESOLVED: Accept "auto" as an animation-duration in the animation
              shorthand (Issue #8656: Explicit `auto` for
              `animation-duration` in the `animation` shorthand)
  - RESOLVED: Allow timeline ranges outside of 0-100% range, and use
              them as-is for existing animation start-time and
              duration calculations (Issue #8578: Out-of-range range

CSS Logical & Images

  - On the call it was suggested to address issue #1724 (flow-relative
      gradients) by using the <position> in Backgrounds 4 as a
      foundation. Discussion will return to github so folks can read
      up on the Backgrounds spec.

CSS Overflow

  - The group was moving toward a new property rather than reusing
      overflow-clip-margin for issue #7246 (How does
      overflow-clip-margin: border-box behave on a scroll container?).
      Use cases will be gathered on github to validate this approach.


Agenda: https://lists.w3.org/Archives/Public/www-style/2023May/0013.html

  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  David Baron
  Oriol Brufau
  Emilio Cobos Álvarez
  Yehonatan Daniv
  Elika Etemad
  Robert Flack
  Paul Grenier
  Chris Harrelson
  Daniel Holbert
  Brad Kemper
  Jonathan Kew
  David Leininger
  Peter Linss
  Alison Maher
  Eric Meyer
  Miriam Suzanne
  Bramus Van Damme
  Lea Verou

  Chris Lilley
  Florian Rivoal
  Sebastian Zartner

Chair: miriam

Scribe: TabAtkins
Scribe's scribe: fantasai

Upcoming F2F

  miriam: Any extra agenda items?
  Rossen: Reminder about f2f in July
  Rossen: The dates have firmed up, there's an update posted to the
  <dbaron> https://wiki.csswg.org/planning/cupertino-2023
  Rossen: Those of you traveling, this should give you the info of
          what to expect in terms of venue, rooms, food, where, how,
  Rossen: If you'll join us, have a read and make travel arrangement
  Rossen: And huge thanks to Elika, Tess, and Myles for organizing

CSS Grid

Application of grid-positioning properties to static position of grid
    children is inconsistent
  github: https://github.com/w3c/csswg-drafts/issues/7661

  iank: Want to get this on radars
  iank: We need to resolve it for subgrid
  iank: Today in the spec we will change the static position depending
        on if the grid is also the abspos CB
  iank: So if the grid is an abspos CB, its abspos child will "place
        itself in the grid" and use that area for its cb
  iank: If the grid isn't an abspos CB the abspos will use the content
  iank: Blink had a bug where we started placing OOF items twice
  iank: Regardless of whether grid was a CB, we'd figure the staticpos
        from the grid area, and then it would get positioned again if
        it was a CB
  iank: Three options
  iank: One is align impls along the spec as-is. That would undo the
        previous resolution, that the staticpos doesn't depend on the
        abspos CB.
  iank: Two is to get rid of the staticpos placement, and always use
        the content box.
  iank: Three is to place the abspos twice. Once in the grid for the
        staticpos, once in the actual CB.
  iank: This gets complicated for subgrid, it'll get placed in the
        subgrid for one and the grid for the other.
  iank: This'll also undo the previous resolution

  fantasai: I'm not sure what you mean by "place an item twice"
  iank: Imagine a grid container that is the abspos parent but not
        its CB
  iank: You'd place the abspos in that grid to pick up its staticpos,
        and then in its CB it'll get actually placed.
  fantasai: What I'm confused about - in a given axis, you're either
            placing it with regards to staticpos or with regards to
            the abspos CB. What do you mean by doing both?
  iank: So if you have an abspos it'll pick up its staticpos rect from
        the parent, say top and bottom aren't set so it uses that
        rect. Then if left and right are set, it's positioned with
        regards to the actual CB.
  TabAtkins: I'm confused, isn't that how abspos works in every case?
  iank: Say you have 'column: 2' on the abspos. It'll get placed in
        the subgrid for static pos and in the outer grid for CB.
  TabAtkins: Ahhhhh, you meant it invokes GRID PLACEMENT twice, in
             different grids.
  iank: Yes, sorry, that's what I meant by placement.

  miriam: So plan is to continue discussion in the issue and bring it
          up in two weeks for resolution.
  iank: Yes. My preferred is to not do grid-placement for the static
        pos, always use the content box.
  iank: If people have strong opinions otherwise, make yourself known.
  fantasai: Could you clarify the writing modes detail?
  iank: Yeah it's not a big issue, I'll clarify in the issue.

Scroll Animations

Require <dashed-ident> for timeline names
  github: https://github.com/w3c/csswg-drafts/issues/8746

  flackr: In the current spec we use <custom-ident> for timeline names
  flackr: But in previous specs this has resulted in compat risk as we
          add new identifiers, as they might clash with
          author-provided custom idents.
  flackr: So I propose we use <dashed-ident> for timeline names. We do
          this already in a few other properties.
  <TabAtkins> +1
  <ydaniv> +1
  <bramus> +1
  <fantasai> I don't like it but I won't object :)

  proposed resolution: Switch timeline names to <dashed-ident>
  miriam: Objections?

  RESOLVED: Switch timeline names to <dashed-ident>

Broader scope of scroll timelines
  github: https://github.com/w3c/csswg-drafts/issues/7759

  flackr: We previously resolved we wanted the scroll-animations spec
          to define a timeline that is provided by a scroller that
          wasn't discovered yet
  flackr: This issue is about the specific syntax
  flackr: Had discussions with a bunch of people and we have a
          proposed consensus
  flackr: New property, timeline-root
  flackr: Not directly related to the view-timeline or scroll-timeline
  flackr: timeline-root defines a new "deferred timeline" object,
          which will find a nested timeline to attach to.
  flackr: Sorry, timeline-scope as the name.

  fantasai: The way I'd describe is you create a timeline by naming an
            axis or whatever.
  fantasai: timeline-scope lets you increase the scope; you put it on
            an ancestor and it "hoists" the timeline higher to make it
            visible to more elements
  flackr: Conceptually this is true, but technically it does create
          its own timeline, for animation discovery purposes.
  flackr: But it's fine to think of it that way, and the timeline you
          observe from JS will be the real timeline generated by the
          scroller or whatever.

  miriam: What's the value of the property?
  flackr: A dashed-ident
  <flackr> probably a list of dashed-idents
  TabAtkins: It will search for a timeline with the same name (of any
             kind of timeline) among its descendants
  TabAtkins: if it finds one (not zero, not many) it attaches that
             timeline to the name for its entire scope

  proposed resolution: remove scroll/view-timeline-attachment, add
      timeline-scope, which accepts a list of timeline names and
      raises their scope
  miriam: Objections?
  <bramus> +1
  <fantasai> +1
  <ydaniv> +1

  RESOLVED: remove scroll/view-timeline-attachment, add
            timeline-scope, which accepts a list of timeline names and
            raises their scope

  <bramus> yay!

Explicit `auto` for `animation-duration` in the `animation` shorthand
  github: https://github.com/w3c/csswg-drafts/issues/8656

  flackr: scroll-driven animations, we want them to implicitly/
          automatically use auto duration, which matches their
          animation range
  flackr: So this raises whether "auto" can be used in the animation
  flackr: Tab suggested this is implied by omission, but this makes it
          impossible to represent a non-zero delay (since duration has
          to exist before a delay).
  flackr: So I suggest we do allow "auto" explicitly.
  flackr: This is similar to other properties like background
  dbaron: Are there any other things in the animation shorthand that
          take "auto"?
  flackr: No, besides animation-name of course
  fantasai: I think we discussed having delay potentially be auto
  flackr: Right, no conflict because delay is already positionally
          unambiguous with duration
  flackr: Only concern is if a non-time property takes auto
  <TabAtkins> +1

  proposed resolution: accept "auto" as an animation-duration in the
      animation shorthand
  miriam: Objections?

  RESOLVED: accept "auto" as an animation-duration in the animation

Out-of-range range offsets
  github: https://github.com/w3c/csswg-drafts/issues/8578

  flackr: This is about whether we allow animation-range offsets
          outside the 0-100% range, and if so what we do with them
  flackr: I propose we do allow them, and we have the animation-range
          account for that range (so the animation conceptually begins
          before the timeline start). This is already well-defined.
  flackr: Also fairly consistent with the way we allow keyframe
          offsets outside the animation active interval.
  flackr: I think it's also useful to have negative values so you can
          define an animation portion as starting before some other
  <TabAtkins> +1

  ydaniv: Is there weirdness with non-named ranges, having values
          outside the range?
  flackr: Why is that weird
  ydaniv: With named ranges you may still have more scroll range
  ydaniv: when you use the entire scroll range there's nothing outside
          of 0-100
  flackr: That's not true with view timelines, because their complete
          range is "cover" but they do produce values outside of 0-100
  flackr: But even so, having implicit clipping at the scroll limit is
          already part of the API in terms of how keyframes work, and
          how named ranges work if you can't scroll to that full
          range. So I think it's consistent.
  miriam: So if the value is outside 0-100 and there's no way to get
          to there, it's clipped?
  flackr: It's implicitly clipped - if you have an animation start at
          -20%, when the animation actually starts it'll actually have
          already gone thru 20% of the animation.

  flackr: Proposed resolution is allow timeline ranges outside of
          0-100% range, and use them as-is for existing animation
          start-time and duration calculations.
  miriam: Objections?

  RESOLVED: allow timeline ranges outside of 0-100% range, and use
            them as-is for existing animation start-time and duration

CSS Logical & Images

flow-relative gradients
  github: https://github.com/w3c/csswg-drafts/issues/1724

  oriol: Currently, in linear-gradient() you can specify an angle with
         physical keywords (to right)
  oriol: Proposal was to also allow a logical side keywords
  oriol: block-start/etc for sides
  oriol: For corners, use same as border-radius, start-start,
         start-end, etc. First refers to block axis, second to inline.
  oriol: Second part of the proposal was about logical angles.

  fantasai: I don't think this is quite the right way. Gradient uses
            `to <position>`, should continue, just with the extended
            <position> we put into BG 4
  fantasai: this is different than what Oriol is saying. It allows for
            logical/physical combos.
  fantasai: You can do purely physical (top left, etc). Axis is
            physical, direction in that axis is physical. You can also
            do purely logical.
  fantasai: But extended position also allows mixed - axis is
            physical, but direction in that axis is logical.
  fantasai: Oriol's suggested syntax doesn't allow for that and is
            inconsistent with the <position> syntax in general.
  fantasai: So we should use extended <position>
  <fantasai> https://drafts.csswg.org/css-backgrounds-4/#the-background-position
  oriol: I'm not as familiar with this extended <position>. Not sure
         how it works when you combine physical and logical.
  oriol: Seems hard to reason about.
  fantasai: Syntax is straightforward, it's documented there. If we
            don't like it, we should change it here, for everything.
            Shouldn't do different things for gradients and
  fantasai: But I do think this is the way we want to go.
  <TabAtkins> +1 to fantasai, at bare minimum we should be
              consistently using <position>, even if we end up wanting
              to change how we do logical <position>.
  oriol: I'd like to review the BG 4 syntax since I'm not familiar
         with it
  TabAtkins: I think it's fine to delay a bit more for review
  TabAtkins: not a high priority
  miriam: Ok, take back to the issue.

CSS Overflow

How does overflow-clip-margin: border-box behave on a scroll container?
  github: https://github.com/w3c/csswg-drafts/issues/7246

  miriam: emilio raised this, fantasai agenda+'d it
  <iank> +1
  emilio: I'm fine with "it doesn't apply to scrollable boxes"
  emilio: So when I filed this, I was wondering...
  emilio: There are some elements that need to clip, even though
          they're scrollable they clip to another box that isn't the
          padding box
  fantasai: Issue is about whether overflow-clip-margin should apply
            to scroll containers
  fantasai: Applying it brings up a lot of interesting questions
  fantasai: Where does the scrollbar go. If you scroll to the top/
            bottom is the content in the padding area clipped, or is
            the scroll area reduced so it's viewable. Etc.
  fantasai: There's a comment from Matthew Perry where he outlines the
            desire for this feature, and outlines a set of behaviors
            that seem to make sense to them.
  fantasai: Scrollable area and viewport are both... Never mind,
            follow the examples.

  fantasai: He wants things scrollable to be viewable until it's
            outside the scrollable margin.
  fantasai: I think if it's within the box it has a layout impact...?
            It's not clear to me exactly.
  flackr: I don't think it has to.
  fantasai: If it doesn't have a layout impact, you can't see all the
            content unless you know to put enough padding in the
  flackr: Right.
  fantasai: So I think it probably makes more sense to effectively
            increase the size of the box to the content area.
  fantasai: So I think the question is - do we want to figure out how
            to make this work? Or just define it to not work?

  flackr: I think there are a lot of UIs that would benefit from this,
          and we should try to make it work.
  iank: Can you give an example?
  flackr: This is a good way to handle cases where you want some
          visuals that show up above your scrolled content, but your
          scrollbar doesn't, so the image in Matthew's comment shows
          an example there with a chat widget where the text scrolls
          under the header (and is blurred by a backdrop filter) but
          the scrollbar doesn't.
  iank: That could also be solved with a z-index fix to the scrollbar,
        maybe? Is this the primary driver?
  flackr: Not the z-index, it's the physical size of the scrollbar
          should be smaller than the visible side of the scrolled
  flackr: In the chat support widget example, the scrollbar starts
          below the header. The header is outside the scroller.
  <bramus> +1 to this example/use-case. I needed something like this
           just recently.
  flackr: I see a lot of sites that have this issue where scrollbars
          don't line up with their visual affordances, and I think
          this API provides a path to fix that.

  iank: My problem is overflow-clip-margin can go negative, and that
        brings up additional questions
  flackr: there may be other ways to do this
  iank: This doesn't feel like overflow-clip-margin to me but I could
        be wrong
  flackr: The chat widget would have an overflow-clip-margin of
          -(header size).
  flackr: Or, positive. whatever makes stuff outside the scroller

  emilio: We do have a property already to specify the scroll distance
          to bring elements into view
  emilio: The use-case for the header seems like we should use that?
  emilio: scroll-padding
  emilio: So it seems there's a use-case to maybe put the scrollbar
          only in the scroll-padding area
  emilio: May be another way of solving this
  emilio: Haven't made up my mind about making the scroller smaller
          and content overflowing it, which is kinda weird, or tweak
          the positioning of the scrollbar via scroll-padding
  <iank> a control to shift the scrollbar seems slightly better

  bramus: Maybe another approach is instead of specifying distances is
          to specify "overflow on x-axis" is simple visible and a
          wrapper around it would clip it?
  <flackr> +1 I was thinking a common pattern would be an ancestor
           applies a clip so that it doesn't infinitely overflow
  bramus: In the chat support widget, there's a wrapper around the
          whole thing that's preventing the chat content from being
  bramus: That avoids the concern about numbers.

  fantasai: Using specific overflow-clip-margin is problematic, you
            shouldn't be trying to predict fixed pixel values
  fantasai: Makes it incompatible with allowing wrapping, etc.
  fantasai: So I don't know this is a good fit for the use-case, but I
            don't know what the right solution is either.
  miriam: I also don't necessarily think scroll-padding is right here,
          it defaults where to scroll to. Here you still want to
          scroll to the top, just want things to be able to scroll
          past that position.
  fantasai: Maybe now we need scroll-scope that hoists the layout
            scope of a descendant scroll container?
  flackr: My expectation is the way devs will use this is they have an
          ancestor that still clips the content, and having pixel
          values is not desirable
  flackr: Maybe you make scrollable overflow visible and it's clipped
          by an ancestor instead.
  <bramus> `overflow: scroll-visible` 🤨

  miriam: So it sounds we're moving in the direction of a new
          property, rather than re-using overflow-clip-margin?
  miriam: Do we want to resolve on the overflow-clip-margin behavior,
          and open a new issue for the remaining cases we still want
          to handle?
  emilio: I think overflow-clip-margin isn't necessarily the right
          property for this use-case, so acknowledging we want to
          solve them and open a separate issue probably makes more

  fantasai: Two side suggestions
  fantasai: from bramus, `overflow: scroll-visible;`
  fantasai: from someone else, a keyword to overflow-clip-margin
  <flackr> overflow-clip-margin: infinite was me :-)

  PaulG: If something is beneath the margin, and overflow-clip-margin
         is set, and there's something interactive in that text (a
         link), is is possible for that to come into focus when
         tabbed? Or will it only scroll to its normal limit and not
         come further in due to the clip?
  flackr: Not 100% sure I followed, but assuming it's just a visual
          clip change, then you wouldn't be able to scroll to the new
  PaulG: Sounds unhelpful, yeah.
  flackr: Right, the other solutions expand the clip instead.

  argyle: Another use-case. I have shadows on boxes inside of
          scrollers, I'd like them to leak out. Right now they're
  argyle: So similar case, I want the scrollport to contain and create
          a scrollable area, but not clip paint.

  miriam: And we're at time, we'll take back to the issue

Received on Thursday, 18 May 2023 00:20:33 UTC