[css-pseudo] Define ::backdrop

[Loirooriol]

Right now ::backdrop is defined in https://fullscreen.spec.whatwg.org/#::backdrop-pseudo-element

Each element in a top layer has a ::backdrop pseudo-element. This pseudo-element is a box rendered immediately below the element (and above the element before the element in the set, if any), within the same top layer.
It does not inherit from any element and is not inherited from. No restrictions are made on what properties apply to this pseudo-element either.

Well, there are several details that are not clear to me:

• Is it a tree-abiding pseudo-element?
• If it's a tree-abiding pseudo-element, where is it originated? Before ::marker, between ::marker and ::before, between ::before and 1st child, between last child and ::after, after ::after?
• It accepts random properties, e.g. display: list-item. But then:
  • Does it really become a list item?
  • If it becomes a list item, does it increment the implicit list-item counter as usual? If so, it's position in the tree matters.
  • Do counter properties even work in ::backdrop? The properties are defined as applying to "all elements (includes ::before and ::after pseudo-elements)", but the ::backdrop definition says "no restrictions".
  • Does it originate a ::marker pseudo-element?
  • Should ::backdrop::marker be a valid selector?

I think css-pseudo should define ::backdrop and clarify these details.

[bramus]

Additionally: the current spec reads “It does not inherit from any element and is not inherited from.”

This also means that custom properties are not available inside of ::backdrop, as demonstrated through this demo:

:root {
  --brand: 0 50% 40%;
}

dialog {
  background-color: hsl( var(--brand) / 0.5 );
}

dialog::backdrop {
  background-color: hsl( var(--brand) / 0.5 ); /* ❌ Does not work */
  backdrop-filter: blur(0.2rem);
}

This confuses authors as they – and me included as well – expected custom props to be available there, similar to them being available in ::after for example.

My proposal for this specific detail, would be to allow custom properties to inherit down into ::backdrop.

[Loirooriol]

Changing this behavior should have its own issue, now for the fullscreen spec there is whatwg/fullscreen#124

[Loirooriol]

@tabatkins In https://drafts.csswg.org/css-position-4/#backdrop you defined ::backdrop as tree-abiding.
Then the questions from the 1st comment need to be answered.
In https://chromium-review.googlesource.com/c/chromium/src/+/3933059 I assumed that ::backdrop is not tree-abiding and can't be a list item.

[tabatkins]

Ah, thanks for this ping! My initial thoughts:

Is it a tree-abiding pseudo-element?

Yes, in that it's a well-defined box with a definition location, so should accept all the stuff other boxes do.

If it's a tree-abiding pseudo-element, where is it originated? Before ::marker, between ::marker and ::before, between ::before and 1st child, between last child and ::after, after ::after?

None of these; it is generated in the top layer, as an independent box with no particular relationship to its originating element. (But it's rendered just below the originating element.)

It accepts random properties, e.g. display: list-item. But then:
Does it really become a list item?

No opinion. I'm fine with forcing it to be display: block via a UA style rule.

If it becomes a list item, does it increment the implicit list-item counter as usual? If so, it's position in the tree matters.

Right, so having this be impossible is probably reasonable.

Do counter properties even work in ::backdrop? The properties are defined as applying to "all elements (includes ::before and ::after pseudo-elements)", but the ::backdrop definition says "no restrictions".

I suppose they do, but we will indeed need to define the position in the tree.

I propose that they're an isolated context that doesn't see any other counters, and its own counters are also invisible to any other element.

Does it originate a ::marker pseudo-element?

If we force it to display: block, no. If not, yes.

Should ::backdrop::marker be a valid selector?

It should probably be valid regardless of the answer to the previous question, but I suspect we'll end up having it not be capable of matching anything since you won't be able to make it a list item.

[Crissov]

Should ::backdrop::marker be a valid selector?

No.

Not so sure about ::marker::backdrop however.

[tabatkins]

::marker::backdrop can't ever exist, the marker pseudo can't be put in the top layer.

[Loirooriol]

None of these; it is generated in the top layer, as an independent box

Sure, but that's the box generated by the ::backdrop. I was referring to the position of the pseudo-element in the element tree, basically what you later mentioned as "we will indeed need to define the position in the tree".

I propose that they're an isolated context that doesn't see any other counters, and its own counters are also invisible to any other element.

Sounds fine, but maybe not much tree-abiding-ish?

[tabatkins]

Nothing wrong with a tree having many roots. It's still tree-abiding, as in, it has a definite set of boxes with definite locations and boundaries, which do not violate the existing tree-ness of the element/box tree (unlike ::first-line).

[Crissov]

Each element in the top layer has a ::backdrop pseudo-element, for which it is the originating element.

Just to clarify, this means there is no way whatsoever to reveal a box’s backdrop unless the originating element is in the top layer.

I’d find this more generic UA default stylesheet interesting:

::backdrop {
  display: none;
}
:fullscreen::backdrop {
  display: block;
}

On the other hand, I’m wondering whether the use case for this pseudo-element couldn‘t have been covered by something like background-origin: viewport.

On the third hand, I would have preferred if backgrounds had been done with pseudo-elements and the fill or the content property from the start. Also see my comment in #8634 for that.

foo::background(0) {
  content: url("bg.img");
  fill: navy;
}

[Loirooriol]

@Crissov There is no need for that display style since pseudo-elements can be prevented from generating boxes by other means, e.g. li::marker will only be generated if the list item has display: list-item, and we don't need a li:list-item::marker rule with a circular selector.

[tabatkins]

Agenda+ to discuss a few questions about ::backdrop's display and position in the tree:

1. Should we just force ::backdrop to display: block !important; in the UA stylesheet? (This avoids some follow-up questions.)
2. Is ::backdrop indeed tree-abiding, or should we lock it down more?
   • Does it have a ::before/::after?
   • Is it fine for any property to work on it?
3. How should ::backdrop act wrt various tree/sibling-scoped things, like counters?

My preferences are:

1. Yes, ::backdrop doesn't have contents and only exists to hold a color or an image and maybe block mouse events, so there's no need to deal with other display values.
2. Yes, it's tree-abiding. No opinion on ::before/::after; I'm fine if we explicitly say it doesn't generate those.
3. I think the easiest is to say that each backdrop is an independent tree for these purposes, not related to the document tree. It doesn't see counters from the document, and the document doesn't see counters from it; etc. Alternately, backdrop can be a child of the originating element (maybe after the ::after pseudo?); this might be more straightforward, since it does inherit from the originating element now.

[bramus]

1. Yes
2. Tree-abiding: yes. before/after: fine with locking it down.
3. I see ::backdrop as a child of its originating element. It just happens to render in the top-layer.

[brandonmcconnell]

1. I see the rationale in using display: block !important (w/ !important). If we're going to enforce the display: block on the UA, should we consider enforcing other properties that could be used to work around that limitation, like visibility: hidden; pointer-events: none;?
2. I would think tree-abiding too; before/after could go either way, but I don't see any strong cases reasons to prevent using them
3. Agreed with all the general thoughts so far, namely @bramus' take— "::backdrop as a child of its originating element. It just happens to render in the top-layer."

[tabatkins]

No, making the backdrop pointer-events:none is something we def want to support. We're not trying to prevent it from being hidden, just limiting what sort of complexity we can potentially get into for what is always going to be an empty element. (That is, display:none would be okay; it's display:grid or display:list-item we want to avoid if possible.)

[brandonmcconnell]

Sweet, I like that approach! I could definitely see hiding it sometimes.

[Loirooriol]

I'm against display: none !important in UA because I think display: none makes sense. I would be fine forcing non-none (and maybe non-contents) values compute to block in the style adjuster.

[rthrejheytjyrtj545]

How about removing the display magic only on the top layer, and thereby adding a potential third background pseudo-element for each element? Proposal:

• remove everything related to the top layer, except for putting the pseudo-element itself in the top layer, along with the corresponding element and in order relative to it

• the normal value of the content property on ::backdrop evaluates to none for elements not in the top layer, and to the empty string otherwise;

• an important declaration in the user agent layer sets display to block, position to absolute and z-index to calc(-infinity).

[css-meeting-bot]

The CSS Working Group just discussed [css-pseudo] Define ::backdrop, and agreed to the following:

• RESOLVED: All 'display' values other than 'none' or 'contents' on '::backdrop' compute to 'block'.

The full IRC log of that discussion

<TabAtkins> https://github.com//issues/7845#issuecomment-1507536451
<fantasai> TabAtkins: Some questions about how ::backdrop should work in the tree
<fantasai> TabAtkins: First, should it be forced to 'display: block !important' in the UA stylesheet?
<fantasai> TabAtkins: doing so avoids some follow-up questions
<oriol> q+
<fantasai> TabAtkins: given it's just designed to put color behind an element, seems unlikely that giving it any other display type would ever matter
<fantasai> TabAtkins: so first question is, can we force it to 'display: block'?
<fantasai> oriol: I disagree with this
<emilio> q+
<Rossen_> ack oriol
<fantasai> oriol: because I think that 'display: none' makes sense
<fantasai> oriol: I would be fine would be saying that all values except 'none' and maybe 'contents' compute to 'block'
<fantasai> oriol: but I wouldn't do this with a UA !important rule
<fantasai> TabAtkins: another possibility is to lean on 'content: none', which would cause it to not generate
<fantasai> TabAtkins: so we don't need 'display: none' to make it disappear
<fantasai> oriol: I guess that could work
<fantasai> oriol: but 'display: none' tends to work on pseudo-elements
<fantasai> oriol: but I guess 'content: none' could address the use case
<fantasai> TabAtkins: but we could also do special computation rule
<Rossen_> ack emilio
<fantasai> emilio: My question was same as Oriol
<fantasai> emilio: is there a use case to set 'none'
<fantasai> emilio: but I'd rather magically turn to block than rely on 'content: none'
<fantasai> emilio: but as long as 'none' works, fine to make everything else a block
<fantasai> TabAtkins: proposed that all values other than 'none' or 'contents' values compute to 'block'
<fantasai> RESOLVED: All 'display' values other than 'none' or 'contents' on '::backdrop' compute to 'block'.

[css-meeting-bot]

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

The full IRC log of that discussion

<dael> TabAtkins: We discussed question 1 at the F2F. 2 and 3 were not decided at the time.
<dael> TabAtkins: I don't recall why we stopped at that point
<dael> oriol: I think it was a regular call and we ran out of time
<dael> TabAtkins: Question 2- is backdrop a tree abiding pseudo element? Or does it need restrictions
<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
<oriol> q+
<ntim> +1 to no before/after
<dael> TabAtkins: Prop is backdrop is tree abiding and does not have a before/after element
<astearns> ack oriol
<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
<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
<dael> fantasai: How does it get below the element in order?
<dael> TabAtkins: By virtue of being in the top layer.
<dael> fantasai: Sot ehre's magic that puts it below toplayer
<dael> TabAtkins: Yes. Anything that does backdrop also has associated toplayer magic
<dael> fantasai: I guess I would have thought of putting it first, but it paints first. But there's magic either way
<fantasai> s/but/because/
<fantasai> s/way/way, because it has to also paint below the box
<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
<dael> TabAtkins: That argues for end b/c not expecting to effect anything in element
<dael> astearns: But we don't know why anyone would put counter display in backdrop
<dael> TabAtkins: Yeah. But needs a definition
<astearns> ack fantasai
<dael> fantasai: Only tie it would matter is if you're increment stuff referencing from the element.
<dael> TabAtkins: Not unusual to things incremeneting from the before
<dael> astearns: So we can resolve that backdrop is tree abiding?
<dael> TabAtkins: It's tree abiding and it occurs after the ::after of it's originating element
<dael> astearns: fantasai you're okay with this?
<dael> fantasai: I think it's okay. Good to check if anyone comes up with reasons
<dael> ntim: Rational to put it after ::after?
<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
<dael> ntim: Okay. No strong opinions. Where is it placed relative to marker?
<dael> fantasai: Should be after. It shold be first or last.
<dael> TabAtkins: before and marker are siblings
<dael> fantasai: I don't know if it should be first or last but it has to be first or last.
<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
<dael> ntim: I think WK puts backdrop box as a child of the root element box
<dael> ntim: I don't know how easy it is to make it tree abiding
<flackr> slight preference for before since after is usually above
<dael> fantasai: I'm a little concerned. Might be better to have in box order immediately before
<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
<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
<dael> ntim: because first of all we have replaced elements that can't have children and the code was more complicated to maintain position
<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
<dael> ntim: I think that's better for impl purposes
<dael> fantasai: Will they inherit from originating element?
<dael> TabAtkins: Yes.
<dael> fantasai: Okay, otherwise a fragment that inherits from originating element.
<dael> fantasai: Seems weird to spec out, but I trust you can do it.
<dael> TabAtkins: ntim to check if you established a counter on the backdrop you woldn't expect to see it anywhere else?
<dael> ntim: Not really, not
<dael> TabAtkins: Okay, that ameks it easier. Separate tree
<dael> astearns: So they are tree abiding elements?
<dael> TabAtkins: Thye're siblings of the root tree
<dael> oriol: Is it tree abiding if it's a different tree?
<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
<dael> TabAtkins: It lives in a tree. Doesn't need to live in document tree.
<dael> astearns: Do we have other tree abiding things not in document tree
<dael> TabAtkins: No. Always time for a first
<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
<dael> astearns: Concerns about defining this as a tree abiding element that lives in a sibling tree to the root tree
<TabAtkins> s/implies it's not/implies it's/
<dael> fantasai: As long as we clarify inheritence
<dael> TabAtkins: Well defined, inherit from their parent.
<dael> fantasai: But they live in the tree. This needs to be clear
<dael> TabAtkins: We had hypotheticals where we discussed this
<dael> fantasai: Those were hypotheticals
<fantasai> s/in the tree/in the tree exactly where they would inherit from/
<dael> astearns: We'll need to be careful in defining it.
<dael> TabAtkins: I agree that's a good note
<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
<dael> astearns: Obj?
<dael> RESOLVED: backdrop is a tree abiding element. It's tree is a sibling of the root tree. It inherits from its originating element
<dael> astearns: before/after?
<fantasai> +1 to not having ::before/::after
<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
<dael> astearns: Prop: backdrop does not have a before and after
<dael> astearns: Obj?
<dael> RESOLVED: backdrop does not have a before and after

[Loirooriol]

I didn't realize this during the call, but it's possible to have multiple elements in the top layer, each one with its own ::backdrop. Then, if all these ::backdrop are siblings of the root, what's their relative order? Are they ordered e.g. according to the tree order of their originating elements?