- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 13 Mar 2024 19:32:11 -0400
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
+++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
shorthand
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
Publication
-----------
- RESOLVED: Publish an updated WD of anchor-positioning
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2024Mar/0010.html
Present:
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
future
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
hidden.
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
accessible
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
displayed.
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
problem.
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
consistent
futhark: Wrt overflow contributing to overflow, wouldn't you get
circularity?
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
offscreen.
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
publish.
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
after
chrishtr: Should we resolve on what should be in ED spec? everything
hidden?
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.
Publication
-----------
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