[css-pseudo] Define ::backdrop
Nobody has claimed this yet.
- Dominant language
- Bikeshed
- Stars
- 4.9k
- Forks
- 816
- PR merge metrics
- PR metrics pending
Description
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::markerand::before, between::beforeand 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-itemcounter 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::backdropdefinition says "no restrictions". - Does it originate a
::markerpseudo-element? - Should
::backdrop::markerbe a valid selector?
I think css-pseudo should define ::backdrop and clarify these details.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the css-pseudo specification and the Fullscreen specification's ::backdrop definition cited in the issue. Resolve the listed questions about tree position, applicable properties, counters, list items, and ::marker, then update the specification with normative definitions covering those behaviors.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- css
- Domain
- documentation, frontend
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100