- From: Krzysztof Maczyński via GitHub <sysbot+gh@w3.org>
- Date: Tue, 10 Nov 2020 21:37:18 +0000
- To: public-css-archive@w3.org
The main reason why I don't consider it a positioning scheme is that you provided no description of how any positioning properties would be interpreted differently for `popover`. And indeed in the considered examples, including the one in your picture, authors would rather like to relate to the element's context in the box tree in specifying its position. We considered requirements for interactions and for lack thereof with different, as yet quite vague sets of properties. Let me take a stab at a simple spec taking into consideration only the most important ones: `overflow` (without separating the axes for now), `clip-path`, `z-index` and `contain`. I propose we start from there and see what's needed and achievable in the first level. Name: `popover` (to bikeshed) Value: <selector># && icb | none Initial: none Applies to: all elements Inherited: no Computed value: as specified (or with `<selector>`s canonicalized) Animation type: discrete If the value is not `none`, let `B` be the nearest ancestor of the subject matching any of the given selectors. If there is none and the value contains the keyword `icb`, let B be the initial containing block. If `B` is still undefined or there is an element with `contain` other than `none` (but cf. ISSUE 3) between the subject (exclusive) and `B` (inclusive) in the subject's ancestor chain, the used value is `none`. Otherwise, disregard `overflow` and `clip-path` on the subject's ancestors which are descendants of `B` when rendering the subject. Additionally, if the subject is not a child of `B`, take the subject out of the stacking context in which it would participate and insert it into the stacking context in which `A` participates as if it were the following sibling of `A`, where `A` is the subject's ancestor which is a child of `B`. ### Open issues 1. A syntactic nit to iron out: `icb` and `none` are valid selectors. (Use parentheses?) 2. Is there a need for a `viewport` value? Probably not, given this property's orthogonality to `position`. 3. Add more refined (and potentially controllable) interaction with `contain` instead of fully trumping in all cases? 4. Consider potential interactions with `transform`, `filter`, `perspective`, `mask`, `mask-image` and `mask-border`. -- GitHub Notification of comment by ByteEater-pl Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5699#issuecomment-724981690 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 10 November 2020 21:37:20 UTC