[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.