- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 11 Jun 2024 14:42:33 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-position] Static position of abspos top layer elements inside fixed pos.`, and agreed to the following: * `RESOLVED: Make the static position of top layer boxes not depend on the size or position of any other element on the page, likely by making static position rectangle the ICB` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> relative static position of absolute positions, fixed<br> <fantasai> emilio: This is the case where the static position of the abspos that depends on something laid out after it<br> <fantasai> emilio: annoying because cyclic<br> <fantasai> emilio: it seems what Blink does is making the static position at the end of the HTML element or something?<br> <fantasai> emilio: so mostly ignored<br> <fantasai> emilio: Gecko [missed]<br> <fantasai> emilio: And WebKit does something else that's incorrect<br> <fantasai> emilio: Tab's proposal is to ignore static position in top layer<br> <fantasai> iank_: I believe what happens is we reparent the top layer boxes in the box tree<br> <fantasai> iank_: so it's a box tree construction effect, not a layout effect<br> <fantasai> emilio: Conceptually they're reparented anyway because abspos<br> <fantasai> iank_: Blink doesn't have the concept of a static positoin placeholder like Gecko does<br> <fantasai> iank_: so as if you moved the placeholder and the thing during box tree insertion<br> <fantasai> emilio: Think it's best to ignore the static position<br> <fantasai> iank_: I think we've defined it to be, this happens at box tree time<br> <fantasai> iank_: or is it defined as something not that?<br> <fantasai> emilio: in Gecko we have two boxes for this element<br> <fantasai> emilio: but conceptually the abspos box (primary box) does get reparented<br> <fantasai> emilio: the static position, conceptually to me, is the position it would have if it wasn't abspos and thus not in top layer<br> <fantasai> iank_: but if this gets reparented during box tree...<br> <fantasai> iank_: when you insert abspos into tree in Blink, we don't reparent to the containing block. It sits whereever it lives<br> <futhark> q+<br> <fantasai> emilio: but it gets laid out and painted in a different order<br> <fantasai> emilio: behavior Blink has is super weird, so prefer to ignore it<br> <fantasai> iank_: you could just reparent the static position box to the same place?<br> <fantasai> emilio: yeah but I think it's super weird<br> <fantasai> iank_: but that's what the spec says?<br> <fantasai> emilio: I think that depends on whether the spec meant to include the static pos<br> <fantasai> iank_: staticpos is spec fiction<br> <miriam> ack futhark<br> <fantasai> futhark: Spec currently says "rather than generating boxes as usual, generate boxes as sibling of root element"<br> <fantasai> futhark: so spec says what we do<br> <fantasai> futhark: if that's not what we want, then we need to change the spec<br> <fantasai> emilio: I'm not opposed to close no change and test+clarification in the spec but... it does feel a little unusual<br> <fantasai> emilio: idk if that would cause issues, because then when destroying boxes you cannot reach ... if you remove an element in the DOM, can't reach descendant elements that are top layer<br> <fantasai> emilio: prefer to behave as regular abspos, parented to the relevant containing block<br> <fantasai> emilio: I'm fine with either behavior<br> <emeyer> fantasai: Could someone describe the situation that crfeates a cycle?<br> <emeyer> s/crfeates/creates/<br> <emeyer> fantasai: The top layer escapes the fixedpos to go into the top layer?<br> <emeyer> emilio: Right.<br> <miriam> ack fantasai<br> <emeyer> fantasai: Why is the top layer element not asbpos?<br> <emeyer> emilio: Top-layer things escape their usual containing block rules<br> <emeyer> iank_: Right, they get lumped on the end of the list for the ICB<br> <emeyer> iank_: The difference at the moment is Gecko doesn't do this well<br> <emeyer> iank_: In Gecko the placeholder isn't reparented so you need to lay out a second level of top layer thing to get the correct static position<br> <emeyer> fantasai: They're both top layer?<br> <emeyer> iank_: They're both direct descendants of the ICB<br> <emeyer> fantasai: I agree with Emilio it's super weird to reparent them and have them at the end of the static HTML element<br> <emeyer> fantasai: I suspect what the spec meant is similar to what happens with fixed position<br> <emeyer> fantasai: They wanted to make sure it would be painted on top<br> <emeyer> iank_: Pulling into a separate list at the ICB level achieves what's needed<br> <emeyer> fantasai: Yeah, the answer is just very weird<br> <futhark> q+<br> <emeyer> …I agree with Emilio that the static position of the element being at the end of the HTML element is super weird even if that's easy or what the spec currently says<br> <miriam> ack futhark<br> <fantasai> s/super weird/super weird from an author's PoV/<br> <emilio> https://drafts.csswg.org/css-position-4/#top-styling<br> <emilio> > Unless overridden by another specification, its static position for left, right, and top is zero.<br> <emeyer> futhark: In section 3.1 in CSS-position-4, there's a list on top layer styling that the static position for left, right, and top is 0.<br> <emeyer> TabAtkins: I guarantee I forgot to list out all four<br> <emeyer> fantasai: I don't know how much review this rewrite has gotten<br> <emilio> Comes from https://github.com/w3c/csswg-drafts/commit/051d37a64ca714fa0238df6db019967de2a086dd fwiw<br> <emeyer> fantasai: I'm not sure how much reliance I'd put on the validity of the spec since it was copied over from another spec<br> <emeyer> TabAtkins: Since top layer is new, we probably don't have a lot in the way of meaningful compatibility troubles<br> <fantasai> s/another spec/another spec drafted by someone who isn't a CSS layout spec expert/<br> <emeyer> …So let's just do the simplest possible thing!<br> <emeyer> …Which is 0,0 static position<br> <emeyer> iank_: With a zero-width-height static position?<br> <emeyer> TabAtkins: The concept of static position doesn't exist and everything resolves to zero<br> <emeyer> iank_: You don't want everything to resolve to zero<br> <emeyer> TabAtkins: Why not?<br> <emeyer> iank_: I think you actually just want the static position at 0,0<br> <emeyer> TabAtkins: I don't understand the objection<br> <emeyer> iank_: Anchor position sets the alignment differently and strethces<br> <emeyer> TabAtkins: Oh, yes, we probably want to fix that to not stretch<br> <emeyer> iank_: Other elements don't support alignment<br> <emeyer> TabAtkins: If we set it to 0,0 in the corner we don't get the auto-alignment, which we wanted to avoid in anchor positioning<br> <emeyer> …For legacy reasons, we can't get away with that in abspos<br> <emeyer> iank_: I think in UA styles, all these things have been set to zero anyway<br> <emeyer> …Like, you have to set insets to trigger this behavior, right?<br> <emeyer> emilio: For popover, I think so, but I'm not sure about other things<br> <emeyer> iank_: I'm fine with saying that static positioning is zeroed out<br> <emeyer> fantasai: Is that going to make sense for non-fixed-position cases like top layer elements that are halfway down the page?<br> <emeyer> iank_: Reparenting in the box tree up to the very top, when would that trigger?<br> <emeyer> fantasai: You scroll halfway down the page and you click on something that's in the top layer<br> <emeyer> …If it's fixedpos and not in the viewport you can't read the whole thing<br> <emeyer> …Sometimes it gets pushed into a static position, which makes it scrollable<br> <emeyer> TabAtkins: The generic answer is, if you want to attach to a thing on the page, use anchor positioning<br> <emeyer> …We don't need to rely on fixed things that are weird if we have a more powerful variant<br> <emeyer> (awkward silence)<br> <emeyer> miriam: I don't feel a need to preserve static positioning generally, and especially not going into the top layer<br> <emeyer> TabAtkins: Can we just say that then?<br> <emeyer> …If you're top layer, we do the same as anchor positioning?<br> <emeyer> fantasai: I think what makes more sense is to define the static position rectangle in the ICB, which I think gives you the right effects<br> <emeyer> TabAtkins: I don't see why it would, necessarily<br> <emeyer> …There'd be no connection to its normal position in the DOM<br> <emeyer> fantasai: I think we want to define the rectangle where it lives and define what that means<br> <emeyer> …If you set everything to zero then it will anchor to that edge<br> <emeyer> …We should talk about it offline<br> <emeyer> TabAtkins: Ah, I see what you mean<br> <emeyer> …We can resolve on doing something arbitrary<br> <emeyer> fantasai: Propose to make the static position of the top layer does not depend on the size or position of any other element on the page<br> <fantasai> fantasai: And probably define by making staticpos rectangle as ICB<br> <emeyer> miriam: Do we have a thing we can resolve on?<br> <fantasai> PROPOSED: Make the static position of top layer boxes not depend on the size or position of any other element on the page, likely by making static position rectangle the ICB<br> <emilio> sgtm<br> <emeyer> miriam: Any objections?<br> <fantasai> RESOLVED: Make the static position of top layer boxes not depend on the size or position of any other element on the page, likely by making static position rectangle the ICB<br> <RRSAgent> I have made the request to generate https://www.w3.org/2024/06/11-css-minutes.html fantasai<br> <jarhar> scribenick: jarhar<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9939#issuecomment-2160944468 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 11 June 2024 14:42:34 UTC