- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 12 Feb 2024 23:50:38 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-position-3] Containing block of dialog fixed position children`. <details><summary>The full IRC log of that discussion</summary> <fantasai> emilio: What happens if you have a fixedpos inside an abspos top layer?<br> <fantasai> emilio: Normally fixedpos has a different containing block, the viewport, and fixedpos works normally<br> <fantasai> emilio: but making stuff escape the top layer element is very weird<br> <fantasai> emilio: So first question is, should fixedpos be in the top layer<br> <fantasai> emilio: it's a controllable top-layer thing, which is weird<br> <fantasai> emilio: if it should not, then that breaks the layout ordering of the elements<br> <fantasai> emilio: to layout fixedpos, you want to layout top layer element first, but that's usually the last thing you lay out<br> <fantasai> emilio: so different ways to address this<br> <fantasai> 1. Do nothing. But if you have a transform between fixedpos and top layer, everyone behaves differently<br> <fantasai> emilio: Simplest would be making toplayer also fixedpos containing block (as if adding a transform)<br> <fantasai> emilio: that makes sure that nothing escapes the top layer<br> <fantasai> s/1./emilio: 1./<br> <fantasai> emilio: I tried that but it broke some stuff. I think WebKit used to do this in the past, so might still be doable?<br> <fantasai> emilio: There are some interesting cyclic issues, because toplayer escapes the normal containing block rules<br> <fantasai> emilio: it gets hauled up to viewport even if transformed ancestor<br> <fantasai> emilio: but its static position needs to be known before laying out<br> <fantasai> emilio: but fixedpos can be in the old place in the DOM<br> <fantasai> emilio: so some interesting cases there<br> <fantasai> emilio: toplayer can be anywhere in tree, doesn't need to respect normal CB rules<br> <fantasai> emilio: could end up laid out in the wrong order<br> <fantasai> emilio: I have a slight preference to make toplayer a fixedpos containing block, but that's probably not doable<br> <chrishtr> q+<br> <fantasai> emilio: so what do we do? do we promote fixedpos to toplayer or something else?<br> <TabAtkins> q+<br> <fantasai> oriol: I just noticed the problem in Firefox, but haven't looked in detail<br> <TabAtkins> fantasai: there's some concepts here i'm not super familiar with<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: so the top layer is, you pull it out of normal stacking contexts, it goes at top of z-order<br> <TabAtkins> fantasai: from layout perspective, it's an abspos element, it has a static position in the rest of the document - does it know where that is?<br> <TabAtkins> fantasai: so layout-wise it might be able to look at that static position<br> <TabAtkins> fantasai: and then you have a fixpos inside the top-layer'd element<br> <TabAtkins> fantasai: and so q is what you do with the fixpos<br> <TabAtkins> emilio: yes<br> <TabAtkins> fantasai: what makes sense to me is the static position of the fixpos is wherever it would be in inside the top-layer'd element<br> <TabAtkins> fantasai: and then the top layer element and its decendants, including the fixpos, are forming almost thier own document<br> <TabAtkins> fantasai: the fixpos will be in that top layer, then<br> <TabAtkins> fantasai: multiple fixpos will sort by zindex normally, but won't leave their top layer slot<br> <TabAtkins> emilio: i dont' think that's what browsers do now<br> <TabAtkins> emilio: i think main issue is that if they are in top layer<br> <TabAtkins> emilio: then i think it's fine<br> <TabAtkins> emilio: but if the're not, the way you lay things out may mean the fixpos is laid out before the staticpos of the top layer'd element<br> <TabAtkins> fantasai: but i'm proposing that they be in the top layer<br> <TabAtkins> fantasai: from the author's perspective, you have a dialog, kinda like a sub window. if it raises to the top layer, its contents should come with<br> <TabAtkins> emilio: hm possibly. we havent' done a lot of allowing other thins that isn't explicitly the top layer to be in the top layer<br> <TabAtkins> emilio: absposes dont' ahve the issue since they're contained within the top layer'd element<br> <TabAtkins> fantasai: but so is a fixpos<br> <TabAtkins> emilio: the containing block of an abspos *is* the top layer<br> <TabAtkins> dbaron: yes, containing block isn't just layout concpet, it also affects painting and z-order<br> <TabAtkins> emilio: so I think that idea is fine, browsers just don't do it currently<br> <dbaron> s/yes, //<br> <TabAtkins> emilio: oriol's testcase was a transformed modal on top of the top layer<br> <chrishtr> containing block doesn't affect paint order....<br> <TabAtkins> emilio: which would normally contain it, but if it's in top layer it's not<br> <TabAtkins> emilio: but i think promoting the fixpos to the top layer fixes the problem<br> <oriol> q+<br> <TabAtkins> fantasai: if you have a doc whose root element is abspos, and it has a fixpos child, how we lay that out seems to make sense here too<br> <astearns> ack chrishtr<br> <dbaron> https://drafts.csswg.org/css-position-4/#document-top-layer<br> <TabAtkins> chrishtr: so the way toplayer is defined, when an element enters the top layer it's reparented in the layout tree, under the root element of the document<br> <TabAtkins> chrishtr: its containing block is now determined by that tree<br> <TabAtkins> chrishtr: so the fixpos that is a child of a top layer'd element will have the root as its CB and laid out accordingly<br> <TabAtkins> fantasai: fixpos doesn't use root element as CB, it uses viewport<br> <dbaron> or really all of https://drafts.csswg.org/css-position-4/#top-layer<br> <TabAtkins> emilio: that's all true per spec, but i don't think impls do that yet<br> <TabAtkins> chrishtr: it shoul be what chromium does, and it doesn't cause issues<br> <TabAtkins> emilio: I think in gecko there's osme interesting order issues, i'll dig them up<br> <TabAtkins> emilio: I don't think we're going to find a lot of use-cases<br> <TabAtkins> emilio: i think there's still some layout ordering issues where, depending on how the DOM order is for abspos vs fixpos...<br> <TabAtkins> emilio: you might lay out one of them without laying out the thing that contains it<br> <TabAtkins> emilio: I have a test case which shows it<br> <TabAtkins> chrishtr: okay. as far as I can tell it's no different from an abspos with a fixpos under it and that works fine<br> <astearns> ack TabAtkins<br> <fantasai> TabAtkins: Right now, if you have abspos that contains fixedpos, the fixedpos is laid out after the rest of the document. First abspos, then fixedpos.<br> <fantasai> TabAtkins: if the abspos is put into top layer, then it's laid out after the rest of the document including fixedpos<br> <fantasai> TabAtkins: so Elika's suggestion that we put the fixedpos into the top layer slot makes sense<br> <TabAtkins> fantasai: and you should do that with the abspos children of the top layer'd element anyway<br> <TabAtkins> TabAtkins: yeah that's automatic, abspos is always a CB for its abspos children<br> <fantasai> TabAtkins: Let's have a concrete example<br> <astearns> ack oriol<br> <TabAtkins> TabAtkins: We're talking in circles, let's do a concrete example in the issue<br> <astearns> Zakim: close queue<br> <astearns> Zakim, close queue<br> <Zakim> ok, astearns, the speaker queue is closed<br> <dbaron> oriol: should these elements being promoted into the top layer be in the HTML spec's explicit list of elements in the top layer?<br> <fantasai> oriol: are we adding to toplayer list or ...?<br> <dbaron> fantasai: no<br> <fantasai> fantasai: it doesn't get its own toplayer, it's associated with the abspos<br> <fantasai> fantasai: descendants of the toplayer should be laid out and stacked relative to each other just as if they were the only contents of the document<br> <fantasai> ...<br> <fantasai> iank_: toplayer absposes get inserted into the tree ... but, that's just a side-effect<br> <fantasai> chrishtr: if you put 'position: absolute' on HTML element<br> <fantasai> chrishtr: it just works afaict<br> <fantasai> emilio: I think we don't share the same list for toplayer items as non-toplayer items for a reason, I need to look into it<br> <fantasai> astearns: OK, let's take it back to the issue<br> <fantasai> fantasai: I think the proposal is basically, the toplayer element and its descendants are all laid out and stacked exactly as if they are the sole contents of the document<br> <fantasai> fantasai: and this is placed over the backdrop as part of a single toplayer layer<br> <astearns> zakim, open queue<br> <Zakim> ok, astearns, the speaker queue is open<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8040#issuecomment-1939808323 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 12 February 2024 23:50:42 UTC