Xiaocheng Hu

Discussed with @wangxianzhu offline. This should be implementable in Chromium The solution doesn't involve duplicating any clip nodes, but we can simply make `PaintPropertyTreeBuilder` switch to the scroller's clip state...

A slightly revised idea: `anchor-clip: auto | none`, where - `auto` is the default value, meaning it should be clipped by all ancestor clip boxes of the default anchor1 -...

I'm wondering if the default value should be `auto` or `none`. Maybe `none` is better. It's pretty common to have a scroller with `overflow: auto`, which doesn't show a clear...

For example: ``` viewport +- scroller | +- anchor +- popover ``` Then `anchor-clip: auto` makes `popover` additionally clipped by `scroller`

@yisibl Yes, but I don't have a clear idea how it should work. Anyway, it's better to file a separate issue for it.

I don't see major issues with 3a60ac6d3f4dc76af96a8d6e8ecc4ec83105e2d4, but some minor ones: 1. What happens when we use `anchor(auto)` in a `@position-fallback` list? I think the correct behavior is to insert...

There's still value if we allow `anchor(auto)` in position fallback list: to reduce verbosity of a complex position fallback list. For example, [the current position fallback list of ``'s listbox](https://source.chromium.org/chromium/chromium/src/+/0c4306fc554c80506eb0f9b833a5d2a5fdd452d5:third_party/blink/renderer/core/html/resources/selectmenu.css)...

What happens if both axes use `auto`, while one is valid and the other is not? For example: ```css #foo { left: anchor(auto); /* invalid use of `auto` */ right:...

Thanks for the edits! One more issue: what happens when the element's base style has both auto position fallback? The current version has only specified two cases: 1. The element...

Are you suggesting that using auto in both base style with a position fallback doesn't make much sense? I was think of something else, but now I agree with that...