- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 01 Nov 2023 23:49:14 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-pseudo] Define ::backdrop`, and agreed to the following: * `RESOLVED: backdrop is a tree abiding element. It's tree is a sibling of the root tree. It inherits from its originating element` * `RESOLVED: backdrop does not have a before and after` <details><summary>The full IRC log of that discussion</summary> <dael> TabAtkins: We discussed question 1 at the F2F. 2 and 3 were not decided at the time.<br> <dael> TabAtkins: I don't recall why we stopped at that point<br> <dael> oriol: I think it was a regular call and we ran out of time<br> <dael> TabAtkins: Question 2- is backdrop a tree abiding pseudo element? Or does it need restrictions<br> <dael> TabAtkins: Consensus from comments is call it tree-abiding. People don't care if it has a before/after. So it's a matter of if it's easier to restrict or leave it in<br> <oriol> q+<br> <ntim> +1 to no before/after<br> <dael> TabAtkins: Prop is backdrop is tree abiding and does not have a before/after element<br> <astearns> ack oriol<br> <dael> oriol: Concern with tree abiding is we need to define where it's originated and there's no clear definition for that. We can pick one which is fine but since it's not clear I have mild concern<br> <dael> TabAtkins: That question is question 3. My possible answers are it's considered to be from the root or say it's after ::after. If you're using counters in the backdrop that's weird. Any place is fine. If there is a use case for something like counters in backdrop having it treated as child of originating element is most sensible<br> <dael> fantasai: How does it get below the element in order?<br> <dael> TabAtkins: By virtue of being in the top layer.<br> <dael> fantasai: Sot ehre's magic that puts it below toplayer<br> <dael> TabAtkins: Yes. Anything that does backdrop also has associated toplayer magic<br> <dael> fantasai: I guess I would have thought of putting it first, but it paints first. But there's magic either way<br> <fantasai> s/but/because/<br> <fantasai> s/way/way, because it has to also paint below the box<br> <dael> TabAtkins: We can put it first. Only deal is, I think this only shows for counters, but if you want counter on element they're incremented by marker or before and being able to see that effect would be good<br> <dael> TabAtkins: That argues for end b/c not expecting to effect anything in element<br> <dael> astearns: But we don't know why anyone would put counter display in backdrop<br> <dael> TabAtkins: Yeah. But needs a definition<br> <astearns> ack fantasai<br> <dael> fantasai: Only tie it would matter is if you're increment stuff referencing from the element.<br> <dael> TabAtkins: Not unusual to things incremeneting from the before<br> <dael> astearns: So we can resolve that backdrop is tree abiding?<br> <dael> TabAtkins: It's tree abiding and it occurs after the ::after of it's originating element<br> <dael> astearns: fantasai you're okay with this?<br> <dael> fantasai: I think it's okay. Good to check if anyone comes up with reasons<br> <dael> ntim: Rational to put it after ::after?<br> <dael> TabAtkins: Needs to live somewhere. For few cases where it matters being able to see effects of something that happened in element, specifically counter or marker, makes sense to have later. But if you've got a reason for earlier it's fine<br> <dael> ntim: Okay. No strong opinions. Where is it placed relative to marker?<br> <dael> fantasai: Should be after. It shold be first or last.<br> <dael> TabAtkins: before and marker are siblings<br> <dael> fantasai: I don't know if it should be first or last but it has to be first or last.<br> <dael> astearns: If anybody has a strong opinion, please speak up. I think I'm ready to resolve it's tree abiding and it's after ::after. If that's wrong can open new issue<br> <dael> ntim: I think WK puts backdrop box as a child of the root element box<br> <dael> ntim: I don't know how easy it is to make it tree abiding<br> <flackr> slight preference for before since after is usually above<br> <dael> fantasai: I'm a little concerned. Might be better to have in box order immediately before<br> <dael> TabAtkins: For rendering it doesn't matter given we have top layer. Making the box generate as a child of the root was important before toplayer so it could avoid overflows and clips. That's no longer necessary<br> <dael> ntim: Simplier for WK to put as child of root element b/c you don't have render being in weird places and having to update when you append a child inside top layer element. Initial WK impl had backdrop as a child of top layer and we moved away from that<br> <dael> ntim: because first of all we have replaced elements that can't have children and the code was more complicated to maintain position<br> <dael> TabAtkins: That was my other suggestion is all backdrops are independent trees so they won't see anything from documents counters. I'm fine with that too<br> <dael> ntim: I think that's better for impl purposes<br> <dael> fantasai: Will they inherit from originating element?<br> <dael> TabAtkins: Yes.<br> <dael> fantasai: Okay, otherwise a fragment that inherits from originating element.<br> <dael> fantasai: Seems weird to spec out, but I trust you can do it.<br> <dael> TabAtkins: ntim to check if you established a counter on the backdrop you woldn't expect to see it anywhere else?<br> <dael> ntim: Not really, not<br> <dael> TabAtkins: Okay, that ameks it easier. Separate tree<br> <dael> astearns: So they are tree abiding elements?<br> <dael> TabAtkins: Thye're siblings of the root tree<br> <dael> oriol: Is it tree abiding if it's a different tree?<br> <dael> TabAtkins: Tree abiding implies it's not a single box you can do stuff to. if it is tree abiding you can do css stuff like it's an element. But if you want to other stuff like width or height it's defined how it works. Tree abiding is the term we use for those types of things<br> <dael> TabAtkins: It lives in a tree. Doesn't need to live in document tree.<br> <dael> astearns: Do we have other tree abiding things not in document tree<br> <dael> TabAtkins: No. Always time for a first<br> <dael> TabAtkins: Important part if is it's a rectangle conceptually and can be styled like one and unlike a selection that we only let a few things apply to<br> <dael> astearns: Concerns about defining this as a tree abiding element that lives in a sibling tree to the root tree<br> <TabAtkins> s/implies it's not/implies it's/<br> <dael> fantasai: As long as we clarify inheritence<br> <dael> TabAtkins: Well defined, inherit from their parent.<br> <dael> fantasai: But they live in the tree. This needs to be clear<br> <dael> TabAtkins: We had hypotheticals where we discussed this<br> <dael> fantasai: Those were hypotheticals<br> <fantasai> s/in the tree/in the tree exactly where they would inherit from/<br> <dael> astearns: We'll need to be careful in defining it.<br> <dael> TabAtkins: I agree that's a good note<br> <dael> astearns: Pro: backdrop is a tree abiding element. It's tree is a sibling of the root tree. It inherits from its originating element<br> <dael> astearns: Obj?<br> <dael> RESOLVED: backdrop is a tree abiding element. It's tree is a sibling of the root tree. It inherits from its originating element<br> <dael> astearns: before/after?<br> <fantasai> +1 to not having ::before/::after<br> <dael> TabAtkins: ntim said not allowing is better. THread was neutral. I'm happy to have it say backdrop has no child pseudo elements unless otherwise spec<br> <dael> astearns: Prop: backdrop does not have a before and after<br> <dael> astearns: Obj?<br> <dael> RESOLVED: backdrop does not have a before and after<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7845#issuecomment-1789844429 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 1 November 2023 23:49:16 UTC