[CSSWG] Minutes Anchor Positioning Breakout 2024-03-13 [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.

+++Anchor Positioning Breakout+++

Rename `anchor-default` to `position-anchor` (Issue #10004)

  - RESOLVED: rename anchor-default to position-anchor
  - TabAtkins will open a new issue about resetting of position

Need ability to say "don't render" when anchor is off-screen
    (Issue #7758)

  - RESOLVED: Add position-visibility as proposed in the issue with
              concerns noted as issues in the draft, to the editors
              draft *after* publication of working draft


  - RESOLVED: Publish an updated WD of anchor-positioning


Agenda: https://lists.w3.org/Archives/Public/www-style/2024Mar/0010.html

  Tab Atkins-Bittner
  Kevin Babbitt
  David Baron
  Oriol Brufau
  Keith Cirkel
  Emilio Cobos Álvarez
  James Craig
  Yehonatan Daniv
  Elika Etemad
  Robert Flack
  Mason Freed
  Chris Harrelson
  Anders Hartvoll Ruud
  Daniel Holbert
  Jonathan Kew
  Roman Komarov
  Una Kravets
  Vladimir Levin
  Rune Lillesveen
  Noam Rosenthal
  Khushal Sagar
  Alan Stearns
  Miriam Suzanne
  Bramus Van Damme

Chair: astearns

Scribe: dbaron

Anchor Positioning

Rename `anchor-default` to `position-anchor`
  github: https://github.com/w3c/csswg-drafts/issues/10004

  TabAtkins: We've set up a dichotomy in names for properties: the
             things that apply to positioned element start with
             position-*, the things that apply to the anchor start with
             anchor-*. anchor-default is the exception.
  TabAtkins: so for better consistency and easier author handling of
             the mental model, we want to shift its name. The name from
             the Apple proposal was position-anchor.
  <fantasai> +1
  TabAtkins: so proposal is to rename anchor-default to position-anchor
             and leave everything else the same

  kizu: As I mentioned in issue 30 mins ago, small issue is we have
        another proposal for position-container, which could
        potentially accept dashed ident. If both end up in shorthand
        for position there's a clash of 2 dashed idents. Otherwise
        seems like a good thing.
  TabAtkins: We don't have a proposal for making a position shorthand
             (yet), so I'm happy to leave that as a problem for future
             Tab to solve

  fantasai: We should resolve whether or not the position property
            resets this
  fantasai: That determines whether it could be in the shorthand in the
  fantasai: I think we should.
  fantasai: In terms of shorthand syntax, we could use slashes to
            disambiguate, like we have in background shorthand.
  TabAtkins: But position shorthand is a separate issue, we can resolve
             on the naming change first.
  fantasai: I think we should decide whether it's reset by position.
  TabAtkins: Whether it's reset by the position shorthand won't changed
             based on what my call it.
  fantasai: More or less natural based on name
  TabAtkins: I'm trying to make incremental progress.
  fantasai: Then we definitely need a followup issue
  Proposed resolution: rename anchor-default to position-anchor

  RESOLVED: rename anchor-default to position-anchor

  ACTION: Tab: open a new issue about resetting of position shorthand

Need ability to say "don't render" when anchor is off-screen
  github: https://github.com/w3c/csswg-drafts/issues/7758#issuecomment-1965540529

  fantasai: We discussed use cases about not rendering when stuff
            doesn't fit
  fantasai: 3 major use cases (repeating the comment in the issue)
  fantasai: (describes bullets 1-3 from comment)
  <fantasai> position-visibility: always | [ anchors-valid |
             anchors-visible ] || no-overflow
  fantasai: (describes position-visibility suggestion from comment)
  fantasai: (finishes describing proposal)

  una: I think this is really important for a lot of anchor position
       use cases. I don't want to block this but I wonder if
       position-visibility is the best name. Sounds like describing
       different behavior for position... maybe call something like
       position-behavior. When you said it it was clear, but looking at
       the names/keywords it wasn't as clear to me.
  una: I don't want to bikeshed this forever but wondering if there are
       better names.
  dbaron: When you said "like visibility: hidden", wondering if that
          was correct, or if stronger… it normally contributes to
          overflow, can be overridden by descendants
  TabAtkins: Not "display: none" ish, because that modifies box tree
  TabAtkins: stronger in that children can't turn off
  TabAtkins: chrishtr suggests it does contribute to overflow, just
             turns off paint
  TabAtkins: Not display:none-ish because that changes the box tree.
             Shouldn't be stronger in that children can't turn it off
             (?). But chrishtr asking below for it to not suppress
             overflow. The argument seems reasonable to me. So I'm
             going to suggest we remove that part of the proposal and
             just suggest it turns off paint.
  fantasai: I don't understand reasoning for that.
  TabAtkins: The thing that it's overflow and the thing that it's
             setting its containing block might not have relation to
             each other.
  TabAtkins: So being able to avoid setting contributing to overflow
             doesn't help too much anyway.
  TabAtkins: There are several ways to raise the positioned element
             further up the box tree for these purposes so it won't
             care about sub containers anyway. e.g., a fix position or
             top layer, or move higher in the dom. Can avoid
             scrollability issues that way.
  TabAtkins: There are ways around if there is a scroll problem. Even
             when you are not moving it around... in a place where it's
             potentially subject to it, not a strong connection there.
  fantasai: I think wrong about not impacting scrollable overflow.
  astearns: The conversation TabAtkins mentioned with chrishtr was
            about not having the no-overflow value?
  TabAtkins: Not about changing the values, just removing the rule
             about not contributing to scrollable overflow when it's

  emilio: The "like visibility" thing made me think ... making it just
          suppress paint seems suspicious to me, you can still have
          things like focused elements inside. visibility:hidden does
          prevent focusability, but I don't think we want determining
          focusability to need layout. Has this been considered?
  fantasai: That's why it should be like visibility, not just paint
            suppression: we want it to block hit testing, focusability,
            rendering into speech. And we don't want children to
            override it.
  emilio: Do you really want it not to be accessible?
  fantasai: Yes. If it's not visible to sighted user, it shouldn't be
  emilio: It's accessible depending on the scroll position -- you're
          supposed to be able to scroll down and see it
  TabAtkins: So why would ???
  emilio: Also about search, find-in-page, etc.
  emilio: a11y client may want to see contents of popup even if it's
          not visible
  fantasai: If it scrolls off the screen that's fine, you can still
            access it. This is for cases where you want to hide it when
            it scrolls off.
  fantasai: These are cases where you don't want the popup to be
            visible based on where it lays out
  TabAtkins: If you find-in-page... it still doesn't fit, it won't be
  TabAtkins: not sure how we'd want to present the find-in-page result.
  TabAtkins: It's possible moving things around might reveal it, but
             there's no straightforward way to determine how to do so.
             Depends on how fallbacks are set up. So I don't think
             there's an automate-able way to expose the text inside to
             the user.
  emilio: It would be exposed if it was clipped by... we don't have
          other precedent for scroll position affecting focusability.
          You can totally find-in-page and focus clipped and
          overflow:hidden text.
  TabAtkins: You can scroll that in
  emilio: You're never going to see it.
  emilio: You have the same problem... but you still have the same
  emilio: a11y hacks rely on pushing stuff away from the viewport.
  emilio: I think that and making element.focus() require layout are
          concerning. element.focus() is hot. Every engine goes through
          hooks to try to avoid work there.

  chrishtr: Why does it cause more layout?
  emilio: You may be focusable if you're visible but not focusable if
          you're not.
  emilio: You can't determine focusability only with style any more --
          you need layout
  chrishtr: If it's hidden but focusable then a sighted user could a
            thing they can't see is focused
  emilio: That's my question -- a lot of things to do here. Just act
          like visibility. Maybe remove from a11y tree based on layout
          not a big deal?
  TabAtkins: Container queries already put us in a situation where
             layout can affect a11y tree.
  emilio: But they affect style
  emilio: so different from an implementation perspective
  TabAtkins: ...
  emilio: Engines try to avoid reevaluating ??? when CQ are in use.
  emilio: I don't know at which stage you'd bring stuff back to live
          for a11y tree.
  emilio: It's slightly different implementation-wise. You want it to
          keep generating boxes.
  chrishtr: If you scroll so anchored element has to disappear because
            of offscreen, then you go back. And anchored element was
            focused before visible. You'd want it to retain focus when
            back on screen. That's what user would expect.
  emilio: Not what would happen when working with visibility
  <vmpstr> this is what content-visibility: auto would work like fwiw
  chrishtr: What if there was script that applied inert and removed
            it... does the focus come back if it's lost?
  chrishtr: I don't think focus remembers?
  emilio: There's a focus fixup in the spec. It checks whether the
          current active element is still focusable and blurs it if
          not... but doesn't remember the previous one.

  jcraig: Maybe a naive question... but curious if the view is in a
          state where if the user would tab to it, it would be a state
          where it would be focused and hidden. Would the focus cause
          it to scroll into visible and then render? Would in-page
          search have similar effect, would the search cause it to
          scroll into visible and then render? If so I wouldn't
          consider it a problem... but if scrolling wouldn't cause it
          to render that would be a problem.
  TabAtkins: 2 of the values not affected by scroll position or not.
             The third requires the anchor to be scrolled, which isn't
             the same as scrolling the popup into view and might not be
             possible anyway.
  jcraig: If there's no scenario where a sighted user would expect
          focus to change the visibility, then you'd probably want them
          hidden by AT by default as well.

  dbaron: I wanted to say something close to what jcraig said
  dbaron: My understanding is that you want AT to show similar to
          what's shown in other modes  … because you don't know what
          combination of things the user is using
  dbaron: consider they might be using a mix of things, and want to be

  futhark: Wrt overflow contributing to overflow, wouldn't you get
  futhark: If you remove scrollbars then it changes the anchor's
           position, gets more space, becomes visible, -> cycle
  futhark: I can a comment on a separate part -- the overflow
           contributing to overflow. If it stops contributing to
           overflow, won't you get circularity with scrollbars? Or does
           that go into normal scrollbar handling?
  TabAtkins: That is a possible circularity, but maybe solvable like a
             tall element with an aspect ratio.
  chrishtr: Is that the same issue I mentioned in issue?
  chrishtr: My suggestion was tooltip always contributing to scrollable
            overflow so you don't have layout circularity

  vmpstr: I wanted to mention content-visibility as one of the things
          that has semantics of not painting when offscreen but is
          still available to AT. Focus and find-in-page work in similar
          ways -- you do the rendering just-in-time to make sure the
          content is available. I fully realize here you're scrolling a
          different thing, but that's the only difference I see.
  vmpstr: So I think there's a precedent for hiding this that are still
          available to assistive technologies.

  kizu: I think both for an element impacting overflow and for a hidden
        element being able to be searchable/accessible -- both things
        we could want to control not just for popovers/anchors but for
        anything. Might want element to be there but not contribute to
        overflow (decorative). The same for searchable: you want to
        search something that's hidden by display:none/visibility:hidden
        /etc., want it to be present in search.
  kizu: I agree if it behaves like visibility:hidden should be hidden
        -- this ability to hide is for some optional thing that doesn't
        necessarily need to be displayed. For most use cases removing
        focus and not returning it back seems ok.
  kizu: Can think of 2 ??: one is scroll driven animations.
  kizu: I think it's possible to detect anchor outside of current
        overflow. ??
  kizu: If you have a cursor and then scroll, cursor could affect
        elements based on :hover pseudo class.
  kizu: I think it's ok for tooltips to disappear and lose everything
        inside because you don't see them anymore.

  fantasai: We don't these to contribute to scrollable overflow when
            they're hidden because it's an optional tooltip-ish thing
            that's nice to have if there's room. If it's overflowing
            the scrollport you don't want to introduce scrollbars to
            accommodate an invisible thing the user can't see.
  fantasai: That's not a good user experience. The point of hiding this
            is that when the condition occurs, the item isn't relevant
            enough to display it.
  <masonf> Don't those scrollbars indicate to the user that there might
           be something down there to scroll to?
  <masonf> (Like the hidden popover?)
  fantasai: If it's not display it should behave like it's not there.
  fantasai: We didn't want to make it display:none because that has
            side effects we don't want.
  fantasai: But we want the page to behave as if it wasn't there for
            visible rendering and for layout. Suppress rendering,
            events, being in a11y tree. That includes not contributing
            to scrollable overflow.

  flackr: I heard a bunch about scrolling the anchor into view: I think
          we might want to spec that focusing something in the anchored
          thing, we might want to scroll the anchor into view. Should
          think whether that makes sense in all contexts.
  <TabAtkins> If we did "scroll the anchor into view", we'd have to key
              it off the default anchor.
  flackr: For contributing to scrollable overflow: there may be use
          cases on the opposite side. May be some cases where you want
          to have room to show. I thought we have another CSS property
          for whether things contribute to scrollable overflow.
  <chrishtr> w3c/csswg-drafts#8361 discusses adding a CSS property for
             avoiding scrollable overflow
  TabAtkins: Don't have it yet, have an open issue for it.
  flackr: Yeah, meant we have an open issue.
  flackr: If we resolved on that issue we'd have a way for authors to
          choose one method or the other.
  astearns: In the proposal it mentions the new overflow value would
            apply even when using abspos or fixedpos. Maybe that's an
            indication it belongs in the more general property.

  jcraig: Responding to earlier comment about precedent for having
          hidden contents interactable with AT. Typically what's
          available when something's off screen is the ability to find
          it and bring it on screen when the user interacts with it. If
          you have negatively positioned content, e.g., way off to the
          left, that isn't something we can ever scroll to. If you use
          that for the old "skip to main content" link. Then there's a
          time when...
  jcraig: AT is interacting with something offscreen. Exposure to AT
          often means ability to search/find and bring into view, at
          which time its rendered and the AT user can interact with it.
          So I think there's a distinction between "available for AT to
          bring something into view" and "available for an AT user to
          interact with while still offscreen/unrendered".

  chrishtr: I think I'm convinced by kizu's comments about developers
            intentionally making things hidden. I think anchored
            element is important to the user in relation to other
            thing, that's no longer on the screen. If that were
            scrolled back onto screen, then it would be on the screen
            and things would be consistent. So I think I agree it makes
            sense to hide it for all of them, or bring it back for all
            of them.
  chrishtr: Re scrollable overflow: the anchored element contributes to
            scrollable overflow whether hidden or not hidden. So the
            issue about scrollbars that might not make sense would
            potentially apply in either case.
  chrishtr: As TabAtkins mentioned there are ways to avoid that problem
            and meet needs of anchor positioning.
  chrishtr: So I think that's not a necessary feature for useful anchor
            positioning on the web
  chrishtr: I think worth considering another CSS property about
            whether element contributes to overflow.
  chrishtr: Another use case is transformed elements

  emilio: I wanted to ask flackr if other use cases for contributing to
          scrollable overflow or not -- but afaict the separate
          property wouldn't allow to not contribute only when hidden.
  flackr: I was saying if you set the property to not contribute to
          overflow, then you'd always be in the case where there wasn't
          sufficient space to match the position-try blocks
  emilio: Not sure I follow, but maybe not important
  <flackr> To be more specific, I was arguing that I don't think
           authors need to conditionally contribute to overflow, either
           always contribute or never (and sometimes not be possible to
           show the anchored element).
  emilio: Other thing: not sure if we have a similar issue for ...
          gecko has a mechanism to hide something visually but not from
          AT. I guess that could also be useful here.

  khush: Did I understand chrishtr correctly: if anchor is offscreen
         which causes anchor to be hidden -- you can't use find-in-page
         to search for text in anchored element?
  chrishtr: Yes... reasoning is that the anchored element is important
            only in relation to the anchor. If developer specifies
            hidden thing then developer says it's not relevant when
  chrishtr: Default value of this property would still be visible always
  khush: Definitely cases where want to search for text in anchored
         element... but seems find given default.
  chrishtr: Polyfills sometimes put visibility:hidden which has same
            effect as what we're discussing

  astearns: A few ways forward. I think we mostly agree this is useful
            and needed for some use cases.
  astearns: I think we could continue discussing in issue. Could
            resolve on putting proposal in spec or opening separate
            issue in the spec. Or could resolve on adding a subset that
            we agree on into the spec.
  fantasai: My impression is that there's a lot of confusion about what
            this is and what it ought to do.
  fantasai: I think TabAtkins and I need to clarify that or explain it
            better or work with bramus on demos or something.
  fantasai: I don't feel strongly about putting in draft or not
  fantasai: but I would like to publish the current draft as is
  fantasai: so maybe we add this into the editor's draft after we
  TabAtkins: I didn't see much confusion -- but also don't see how we
             can subset it.
  TabAtkins: So my preference is either to continue discussing, or put
             it in the spec with inline issues.
  astearns: I like the idea of publishing as-is and adding to ED right
  chrishtr: Should we resolve on what should be in ED spec? everything
  astearns: Guessing having a particular position in the ED may make it
            easier to discuss alternatives. Having a stake in the
            ground in the ED can be a good way forward.
  astearns: So what exactly would we add to the ED?
  fantasai: My suggestion is adding what TabAtkins and I originally
            proposed, and then mark the open questions against it.
  chrishtr: Would you mind removing the scrollable overflow part, or
            prefer not to?
  fantasai: I'd prefer not to... but happy to mark that as an issue.
            Issue largely around circularity.
  Proposed resolution: Add position-visibility as proposed in the issue
      with concerns noted as issues in the draft, to the editors draft
      *after* publication of working draft.

  RESOLVED: Add position-visibility as proposed in the issue with
            concerns noted as issues in the draft, to the editors draft
            *after* publication of working draft.

  <khush> One more sub-issue that can be done in a follow up, define
          what "offscreen" means for the anchor.


  fantasai: So we'll fold in the position-anchor/anchor-default rename
            and then publish

  Proposed resolution: publish an updated WD of anchor-positioning

  RESOLVED: Publish an updated WD of anchor-positioning

Received on Wednesday, 13 March 2024 23:32:43 UTC