[CSSWG] Minutes Telecon 2024-05-22 [css-overflow][css-viewport][css-flexbox][css-anchor-position]

  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 Overflow

  - RESOLVED: Close the issue, adding a note to the ink overflow
              definition about platform and rendering differences
              (Issue #8649: Specify extent of ink overflow)

CSS Viewport

  - RESOLVED: Leave open, bring back in the upcoming F2F (Issue #7767:
              Add a meta viewport parameter to control ICB layout
              behavior for interactive overlays)

CSS Flexbox

  - RESOLVED: Change minimum size of flex items to be the larger of
              min-intrinsic and transferred size (Issue #6794: Change
              content-size suggestion to min-intrinsic instead of

Anchor Positioning

  - There was concern that the proposal in issue #10315 (Alignment
      shouldn't interfere with sizing) would cause poor behavior in a
      majority of cases. However, the proposal in issue #10316 (should
      alignment safety consider the containing block?) could address
      that concern. The group will return to issue #10315 later after
      folks have had a chance to read and discuss issue #10316.


Agenda: https://lists.w3.org/Archives/Public/www-style/2024May/0016.html

  Rachel Andrew
  Tab Atkins-Bittner
  Kevin Babbitt
  David Baron
  Keith Cirkel
  Emilio Cobos Álvarez
  Yehonatan Daniv
  Elika Etemad
  Robert Flack
  Mason Freed
  Chris Harrelson
  Daniel Holbert
  Brian Kardell
  Jonathan Kew
  Ian Kilpatrick
  Roman Komarov
  Una Kravets
  Alison Maher
  Khushal Sagar
  Alan Stearns
  Miriam Suzanne
  Stefan Zager

  Chris Lilley
  Lea Verou

Chair: astearns

Scribe: emilio
Scribe's scribe: fantasai

CSS Overflow

Specify extent of ink overflow
  github: https://github.com/w3c/csswg-drafts/issues/8649

  szager: Trying to summarize the discussion:
  szager: IntersectionObserver v2 uses ink overflow rects to determine
  szager: view transitions use it too
  szager: It was brought up to me that ink overflow is a bit
  szager: which can cause interop issues
  szager: My personal agenda was to enable IOv2
  szager: for everything except text, the extent of ink overflow is
          pretty straight-forward
  szager: A couple places didn't call out it in the spec
  szager: so I wrote a few PR
  szager: but text is the really different one
  szager: When laying out text we're subject to font selection / glyph
          shaping, web devs understand that different platforms give
          different results
  szager: you can access the layout geometry via APIs and
  szager: on inlines etc
  szager: Ink overflow is different, it's magic and not observable
  szager: I wonder if we can help developers get a hand on this
  szager: given we now have APIs which kind of expose ink overflow
          extents directly, it seems weird not to expose them
  szager: I know that some of my PRs are not up to the standard in the
          spec. I'm not super-engaged on getting them landed but I
          think we should do the best possible for developers

  florian: You submitted 3 prs, for text, text-decoration, and for
  florian: it seems you want (1) define ink overflow better
  florian: which seems useful
  florian: I haven't reviewed all the PRs, but the text PR isn't about
           defining it
  florian: it's author guidance about how to reason about it
  florian: so that's less obvious to me that it belongs in the spec
  florian: You made some arguments which I didn't understand before
  florian: but this looks more like devrel etc
  florian: If there's agreement that this should be in the spec then we
           should work more of it
  florian: but as is the PR is not definition of ink overflow, more
           like author guidance

  chrishtr: Just to bring it back to what I think should be the main
  chrishtr: Is ink overflow well-specified enough for those use cases?
  florian: Not sure that's relevant because the PRs doesn't define
  chrishtr: I agree with it being more dev guidance
  chrishtr: If it's well defined let's close the issue and we can put
            developer guidance elsewhere

  emilio: I think the differences in text ink overflow are unlikely to
          cause substantial web compat problems for the APIs we're
          exposing right now
  emilio: I don't think defining ink overflow for text is a blocker for
          the occlusion stuff
  emilio: nor for View Transitions
  emilio: The differences are relatively minor, and also happen even
          within the same browser across different platforms.
  emilio: If you only test Chrome on Windows, Chrome on Mac is different
  emilio: I don't think the ink overflow extents for text are likely to
          break use cases for intersectionObserver v2
  emilio: same for View Transitions
  emilio: I don't think it can cause realistic compat issues
  emilio: Not necessarily well defined
  emilio: but it doesn't matter much
  emilio: One thing Stefan was asking was about exposing the ink
          overflow rects more
  emilio: I think authors should generally not care about ink overflow
  emilio: devtools could point out if needed
  chrishtr: Sounds like you think we could close the issue as "good
  emilio: Depends on the goal of the issue
  chrishtr: for existing use cases that need it
  emilio: text ink overflow maybe needs better definition
  chrishtr: Open a new issue, add some examples

  khush: We're using this definition in one spot for view transition
  khush: but not Web-observable
  khush: Want to clarify that view-transition we are using it at one
         spot but it hasn't been a compat issue because it's not
         observable at all
  khush: because the area is managed by the browser
  khush: but we want to use it for a feature where visibility with the
         viewport is handled with ink overflow instead of border box
  khush: that technically would expose it
  khush: and you could measure it moving a div 1px at a time
  khush: but for the use cases we want I think it's ok

  florian: No strong view on whether what we have is good enough
  florian: for view-transitions or intersection-observer
  florian: predictable for authors is one thing, easy to compute for
           browsers is another
  florian: Glyphs are not the kind of infinite thing you need to
  florian: It could be very expensive to compute where a glyph ends
  <fantasai> Definition of ink overflow
  florian: it's where the text ends, which you can compute, even though
           it might not be easy
  florian: so I don't think it's badly defined
  szager: All browsers need to compute it already
  fantasai: I was on the queue to say what florian said, I don't think
            text ink overflow is ambiguous
  fantasai: if there's an actual ambiguity then we should fix the spec
  fantasai: otherwise it's not ambiguous
  fantasai: I don't think an API to expose it would be a good idea
  fantasai: because of that issue

  astearns: I think what I'm hearing is that what's currently in the
            spec is good enough for current use cases
  astearns: so propose to close unless spec is ambiguous
  emilio: Ambiguity is not so much the spec definition, but the fact
          that the same text in the same font may generate different
          ink overflow on different platforms due to shaping and
  emilio: Might be worth pointing out in the spec
  emilio: so that people defining APIs that depend on ink overflow can
          take that into account
  emilio: Doesn't have to be long, just a paragraph, that says it'll
          differ across platforms and rendering engines
  emilio: for Khush's proposal about exposing more directly, file a
          different issue
  emilio: idk to what extent that can increase fingerprinting surface
  emilio: That's a good reason why someone might measure a div pixel by
  emilio: not something you really want to expose, maybe it's exposed
          on canvas already
  emilio: worth more thinking
  fantasai: If you want a note saying this can differ due to different
            factors then happy to do that
  chrishtr: Sounds great, thank you for volunteering

  RESOLVED: Close the issue, adding a note to the ink overflow
            definition about platform and rendering differences

CSS Viewport

Add a meta viewport parameter to control ICB layout behavior for
    interactive overlays
  github: https://github.com/w3c/csswg-drafts/issues/7767#issuecomment-2109901056

  emilio: Added to draft, but never got WG review
  emilio: Discussed adding meta viewport to control effect of keyboard
          on layout / visual viewport
  emilio: I recall Jen presenting use cases for different things.
  emilio: There are use cases for resizing either layout or visual
  emilio: That changes things like fixedpos
  emilio: This viewport meta key allows you to configure that behavior,
          as well as via JS virtual keyboard API.
  <astearns> changes we are discussing:
  emilio: The tl;dr is, there are use cases for different behaviors
  emilio: existing meta tag seems like the right place to configure this
  emilio: Are people OK with this? Gecko is implementing, Chromium may
          have shipped awhile ago, unsure about WebKit status
  <TabAtkins> Looks good to me, personally.

  fantasai: This is the first I'm hearing about it. Recall discussing
            the problems, but don't recall resolving on adding this
  iank: We made a switch to iOS behavior, but had compat issues, and
        needed to provide a toggle for the various behaviors.
  emilio: Gecko and Blink used to resize the layout viewport for the
  emilio: and iOS didn't
  emilio: but sometimes could e.g. in webview
  emilio: For Gecko to align with WebKit and Blink, we are also looking
          at implementing this
  emilio: because use cases for other behavior
  emilio: so this seems like reasonable place to opt into this
  iank: It's served us pretty well when we did this change.

  fantasai: I can't represent WebKit's position on this
  fantasai: From my perspective it's not amazing that somebody edited
            it without bringing it up and now everybody is shipping it
  iank: We did bring it up for discussion
  fantasai: interactive-widget doesn't show up in the mailing list
  fantasai: Just saying, let's avoid that kind of situation in the

  astearns: It sounds like there was discussion in the PR
  astearns: which isn't great
  astearns: three different things we could do I guess
  astearns: (1) leave issue open, bring it back in the f2f
  astearns: (2) accept PR, belatedly, open new issues if needed
  astearns: (3) ack that we didn't follow process, rip it from the
            draft and opt in again
  <TabAtkins> +1 to 1
  chrishtr: +1 to 1
  <chrishtr> https://github.com/WebKit/standards-positions/issues/65

  RESOLVED: Leave open, bring back in the upcoming F2F

CSS Flexbox

Change content-size suggestion to min-intrinsic instead of
  github: https://github.com/w3c/csswg-drafts/issues/6794#issuecomment-2117951367

  iank: This is regarding auto min size on flex items and aspect-ratio
  iank: Blink is more or less consistently dropping the aspect-ratio
  iank: other browsers are sometimes dropping it
  iank: Blink has been on the receiving end of a bunch of web dev bug
  iank: This situation isn't good for web devs
  iank: haven't seem bug reports for the other engines
  iank: as such I think we would do a change to respect aspect-ratio
  iank: we can add a bunch of tentative tests about this behavior
  iank: Proposal would be max(transferred-size, min-intrinsic size)
  <dholbert> (in the min() expression)

  <TabAtkins> I'm happy to take the change, I'll just have to spend
              some time digesting exactly what it is. But if we're
              getting compat issues and webdevs are preferring one
              behavior, let's do it.
  fantasai: I'm the same as Tab here
  fantasai: TabAtkins and I would like to spend some time on this
            issue, but if there are compat issues...
  iank: Yeah I'm going to try changing blink and add tests
  fantasai: I think I understand the proposal now
  fantasai: I think it makes sense?

  astearns: should we resolve on accepting this change tentatively?
  <chrishtr> +1 to accepting the change

  iank: What's going on is web devs really hate it when the
        aspect-ratio gets dropped
  iank: I think proposed resolution would be to change the AMS of flex
        items to be max(min-intrinsic-size, transferred-size via
  fantasai: ok, got it

  emilio: Do we understand what Gecko and WebKit are doing?
  iank: I understand, it's complicated
  iank: WebKit and Gecko are inconsistent between row/column axes, and
        aren't consistent in when transferred size is applied. They are
        inconsistent between column / row and how the transferred size
        is getting applied
  iank: everyone is super inconsistent
  emilio: If you could write it up, I'd be curious
  iank: My intention was to write out a suite of testcases for this
  iank: that should show what's happening
  iank: Issue is that Web Devs are running into behavior where Webkit/
        Gecko are consistent in honoring aspect ratio and Blink isn't
  emilio: So your proposal would be breaking changes for all three
  emilio: right?
  iank: Yes, because we're all inconsistent. And inconsistent across
        axes. Basically everyone is bad.
  iank: We're probably the most consistent, but not what web devs expect
  iank: so that's where we are
  emilio: Ok, this sounds good. We'll look at tests. On paper sounds
  iank: Given lack of bug reports on other engines, not worried
  astearns: Proposed resolution to change minimum size of flex to be
            the larger of min-intrinsic and transferred size
  PROPOSED: change the AMS of flex items to be max(min-intrinsic-size,
      transferred-size via aspect-ratio)

  RESOLVED: Change minimum size of flex items to be the larger of
            min-intrinsic and transferred size

Anchor Positioning

Alignment shouldn't interfere with sizing
  github: https://github.com/w3c/csswg-drafts/issues/10315

  fantasai: The current anchor-center definition changes the available
            size for sizing the abspos to the largest rect that can be
            centered wrt the anchor that fits within its inset area
  fantasai: so if your anchor is in the center on the screen you have
            all the regular stuff
  fantasai: but if you're in the edge of the screen you have a little
            bit of space
  fantasai: Alignment never affects the avail space
  fantasai: this would be a first
  fantasai: Alignment takes the box and avail space and aligns it
  fantasai: I think that's what we should do for anchor-center
  fantasai: If the author wants to resize the anchor we should provide
            keywords in the inset or what not properties to enable that
  fantasai: so I think the anchor-center kw should say "size the box in
            this container, and move it as close to the desired
            alignment without overflowing the container"

  TabAtkins: This is novel for alignment
  TabAtkins: but that's not needed for existing alignment values
  TabAtkins: This isn't true for anchor-center
  TabAtkins: if half your size is larger than the distance to the
             closer edge
  TabAtkins: then you overflow if you stay centered
  TabAtkins: In particular if you fill the cb then you're almost
             guaranteed to overflow
  fantasai: That's not what I'm proposing though
  TabAtkins: Right, two possibilities
  TabAtkins: (1) is the current behavior
  TabAtkins: which has this edge case but looks good pretty good if
             you're in the middle
  TabAtkins: Looks better than growing to the full size and align
  TabAtkins: (2) is what you suggest
  TabAtkins: This was what the spec originally said
  TabAtkins: but the sliding behavior needs to be available to more
             than anchor-center
  TabAtkins: Bikeshed does this for left-aligned anchors for example
  TabAtkins: but whatever you do it can't be locked to anchor-center
  TabAtkins: When we come up with something that does the sliding, it
             should disable this shrink-avail-size bit
  TabAtkins: so I wrote the spec the way it is because it looks better
             in the majority of cases
  TabAtkins: You can kinda fix this with min-size (though it's not
             perfect because you'd overflow)
  TabAtkins: but when we have the sliding bit then it should work just
  TabAtkins: If we do the sliding I'm concerned about doing it too
             early before knowing what it'd look more generally

  <fantasai> una made a visual of this issue in

  iank: We do have changing of avail space in inset-{axis}: auto in rtl
  iank: there are cases where this happens
  fantasai: yeah static pos...

  fantasai: I see what your concern is
  fantasai: there's another issue I filed that should get us there
  fantasai: I feel strongly that alignment should not change sizing
  fantasai: My suggestion is that maybe we defer this issue, we have a
            chat about the other issue
  fantasai: if we have a system that works then we can come back to
            this issue
  fantasai: I'd much rather give authors control about this
  TabAtkins: What's the other issue?
  fantasai: #10316
  <kizu> +1 to fantasai that align should not resize things, I had
         cases in my experiments where this behavior was not what I
         wanted, and I almost would always prefer sliding behavior
         (which _sounds_ like something close to how `position: sticky`
         could work)
  TabAtkins: happy with that
  TabAtkins: there are slight tricks we could do to minimize the
  TabAtkins: bad case here
  TabAtkins: but we can chat
  astearns: Let's leave open and come back after TabAtkins and fantasai
            have discussed the other one

Received on Wednesday, 22 May 2024 23:18:32 UTC