Re: [csswg-drafts] [css-anchor-1] Need ability to say "don't render" when anchor is off-screen (#7758)

The CSS Working Group just discussed `[css-anchor-1] Need ability to say "don't render" when anchor is off-screen`, and agreed to the following:

* `RESOLVED: we add something to deal with clipping in this context`

<details><summary>The full IRC log of that discussion</summary>
&lt;emeyer> xiaochengh: In many cases, the anchor positioned element and its anchor are not in the same scroller<br>
&lt;emeyer> …Elements can appear hanging outside scroller, which looks weird<br>
&lt;emeyer> …There are use cases where you want that, but others where we want the element to act as if it’s in the scroller, so clipped<br>
&lt;emeyer> …Since both behaviors have use cases, we should add a new property tentatively named `anchor-clip` with values `none` and `auto` which means we want to clip using all ancestor scrollers of the anchor<br>
&lt;emeyer> …Not sure which should be default, but consensus is currently that it should be `none`<br>
&lt;emeyer> TabAtkins: While the exact mechanics of `auto` need work, you should be able to get the same clipping behavior you’d get if the anchored element is sitting right next to the anchor in the DOM<br>
&lt;emeyer> fantasai: Can someone drop the grammar being proposed into IRC?<br>
&lt;xiaochengh> anchor-clip: auto | none<br>
&lt;xiaochengh> default value: none<br>
&lt;emeyer> fantasai: I think this makes sense to have<br>
&lt;kizu> q+<br>
&lt;vmpstr> q+<br>
&lt;emeyer> …The one thing I’m a little unclear on is, you’re not clipping the anchor, so maybe a different name would be better<br>
&lt;astearns> ack kizu<br>
&lt;emeyer> TabAtkins: We have a l ot of anchor-* properties not actually affecting the anchor<br>
&lt;emeyer> …Not opposed to changing the name<br>
&lt;emeyer> bramus: We are either not clipping and element or else completely clipping by its bounds<br>
&lt;bramus> s/bramus/kizu<br>
&lt;emeyer> …This might have a connection with fallbacks<br>
&lt;astearns> ack vmpstr<br>
&lt;emeyer> …I wanted to mention that you might want to clip depending on the fallback, or clip as a final fallback strategy<br>
&lt;emeyer> vmpstr: Are there any other properties where, this is a situation where an element determines whether it should be clipped by things it’s not related to in the hierarchy<br>
&lt;emeyer> …If that’s the choice, how does it interact with other containers like paint containment or overflow-clip?<br>
&lt;emeyer> TabAtkins: The exact mechanics are still up in the air<br>
&lt;emeyer> …The idea is that it should act like it’s local, so I suspect you’d want things like paint clips to clip as well<br>
&lt;emeyer> xiaochengh: I’m not 100% sure but I did a rough prototype and the clips apply on each other<br>
&lt;emeyer> …We’re just doing an intersection of all the clips<br>
&lt;emeyer> TabAtkins: I’m no longer certain paint clip should apply, so we definitely need to discuss more<br>
&lt;emeyer> astearns: Should we discuss and come back to this at the next meeting?<br>
&lt;emeyer> TabAtkins: Can we resolve on basic behavior with details up in the air?<br>
&lt;emeyer> fantasai: I think so<br>
&lt;emeyer> astearns: Proposed resolution is we add something to deal with clipping<br>
&lt;emeyer> RESOLVED: we add something to deal with clipping in this context<br>
&lt;fantasai> s/context/context, continue figuring out details in the issue<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7758#issuecomment-1721382237 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 15 September 2023 14:33:09 UTC