[css-pseudo] more clearly define which pseudo-elements are tree-abiding or part-like

[dbaron]

css-pseudo-4 defines the terms "tree-abiding pseudo-element" and (a stricter subset) "part-like pseudo-element". Some pseudo elements fall into these categories.

These cause various things to be allowed. In particular, I think the current list is that tree-abiding pseudo-elements are:

• allowed to change the results of getComputedStyle
• allowed after ::slotted()
• support the content property [ Edit: this is what the spec says but it probably doesn't match reality ]

and part-like pseudo-elements do all of the above and also:

• support any CSS properties except those that say otherwise
• can be followed by most pseudo-classes and any pseudo-elements (not yet specified, see [css-pseudo][css-shadow-parts] Define "part-like pseudo-element" concept #10083)

However, there are multiple specifications that define pseudo-elements, some of which define pseudo-elements that probably belong in one of these categories but don't say so, and some of which define pseudo-elements as tree-abiding when they may want the newer part-like definition instead.

We should audit all pseudo-elements and make sure that they're defined appropriately. We should probably also get a group resolution on the result of that audit, since the changes in feature support for many of these pseudo-elements are substantive. (The initial introduction of the part-like term defined a bunch of pseudo-elements as part-like, and I think we could probably use a resolution to approve that.)

[dbaron]

I think we also need to consider whether more information is needed in the spec to define a part-like pseudo-element (such as what type of element it is, which can affect which pseudo classes it supports).

[tabatkins]

I think we also need to consider whether more information is needed in the spec to define a part-like pseudo-element (such as what type of element it is, which can affect which pseudo classes it supports).

Yeah, this information is needed. I think we can default to making them a "generic" element which possesses no special qualities, but we should introduce a term making it easy to have a part-like "defer" to a real element (possibly in another tree, including a fully UA-generated/controlled one) for the purpose of its properties. That latter would cover ::part(), obviously, and also things like the new base-appearance form pseudos.

[dbaron]

I think I'm inclined to suggest the following (though there are a bunch that I'm unsure about):

part-like:

• ::part()
• ::file-selector-button
• ::details-content
• ::picker()
• ::slotted() (?)

tree-abiding:

• ::after and ::before
• ::backdrop (↓?)
• ::marker
• ::placeholder
• ::scroll-marker-group and ::scroll-marker (?)
• ::view-transition, ::view-transition-group(), ::view-transition-image-pair(), ::view-transition-new(), ::view-transition-old() (↑?)

neither:

• ::attr()
• ::content
• ::cue, ::cue(), ::cue-region, ::cue-region() (?)
• ::first-letter
• ::first-line
• ::selection, ::grammar-error, ::spelling-error, ::highlight()
• ::nth-fragment()
• ::prefix, ::postfix
• ::shadow (?)
• ::target-text

[css-meeting-bot]

The CSS Working Group just discussed [css-pseudo] more clearly define which pseudo-elements are tree-abiding or part-like.

The full IRC log of that discussion

<fantasai> Related: https://github.com//pull/10839/files
<dholbert> dbaron: we introduced this concept of ::part-like pseudo-elements
<dholbert> dbaron: there's a few different ways to think about it; I like to think it's a pseudo-element where underneath there's actually an element. So you can do most things with it
<dholbert> dbaron: ::part lets you use a pseudo element that was part of the shadow tree
<dholbert> dbaron: we're adding another way to do for form-controls that's similar
<dholbert> dbaron: we've added tree-abiding pseudo elements. they support a smaller set of things. General assumption: we can make a tree out of them
<dholbert> dbaron: they're not things like ::selection that cross the tree in random ways
<dholbert> dbaron: they're like ::before which lives in the tree at this place, and it has clearly-defined before/after siblings
<dholbert> dbaron: we have a lot of pseudo-elements in different specs. We need to be sure the ones that should be defined as ::part-like are defined that way, and same for tree-abiding, and we should say which ones aren't those things too
<dholbert> dbaron: I tried to make a list of which pseudo-elements go in each bucket
<emilio> q+
<dholbert> dbaron: I'd like other folks to take a look, especially the ones that I put question marks next to
<dholbert> dbaron: this is in the last comment in the issue, https://github.com//issues/10794#issuecomment-2379912294
<Rossen6> ack fantasai
<dholbert> fantasai: there are multiple categories of pseudo-elements. we should be sure the names for the categories are reasonable
<dholbert> fantasai: "tree-abiding" seems reasonable. we have some that are restricted in terms of which properties they can take (e.g. ::before vs ::marker)
<dholbert> fantasai: "tree-abiding and takes any property", "tree-abiding but restricted", and "part-like" -- are those the 3 categories?
<dholbert> dbaron: we've already allowed pseudo elements to have hand-written restrictions
<dholbert> dbaron: everything not in the ::part-like bucket has some restrictions hand-written at its definition
<dholbert> dbaron: there are also a bunch of general rules about how selectors combine, more than about what properties are used
<dholbert> dbaron: ::part-like pseudo elements do allow any properties, but the more interesting part is about how you can combine selectors
<dholbert> dbaron: anything that's not part-like has custom prose saying which properties are allowed
<kbabbitt> q+
<Rossen6> ack emilio
<flackr> w.r.t. having a known location in the tree, see https://drafts.csswg.org/css-animations-2/#animation-composite-order
<dholbert> emilio: I think your list is pretty reasonable. I don't think all the tree-abiding pseudos support the content property
<dholbert> dbaron: that was me reading the spec, not checking reality
<dholbert> dbaron: I looked through all the specs for things that reference those definitions
<dholbert> dbaron: in reality support for the content property does not match the spec
<dholbert> emilio: ::backdrop might not be implemented as an element in all engines... as a box, in all engines?
<dholbert> fantasai: that's how it should be defined. There's no reason for it to have an element backing...
<dholbert> emilio: not sure if all impls make it an element. if they don't make it an element, I'm not sure it should be tree-abiding?
<andreubotella> q+
<dholbert> fantasai: it does fit in the tree. stuff that's not tree-abiding is stuff that crosses element boundaries. ::first-letter, ::first-line, all that stuff
<kbabbitt> q-
<dholbert> emilio: ::cue might be ::part-like
<dholbert> emilio: and also [...]
<dholbert> emilio: for now we can go with -- if an engine doesn't implement it as a part, we can consider it not-part-like, and we can sort out more later
<dholbert> emilio: my other intuition for part-like vs. not is whether there's an actual dom element behind it, that isn't created by layout
<dholbert> emilio: (::before and ::after and ::marker are special)
<dholbert> emilio: but generally, my list would match yours, except for maybe ::backdrop and ::cue
<Rossen6> ack andreubotella
<emilio> perhaps ::placeholder could be part-like
<emilio> Once we define how `<input>` is laid out
<emilio> One of these days ;)
<dholbert> andreubotella: you could think of ??? as selecting something in the flattened element tree, tree-abiding as selecting something in the box tree
<kbabbitt> s/???/part-like/
<dholbert> andreubotella: do these pseudo-elements have some particular distinction? does it make sense to group them in this way, depending on what they select into?
<jarhar> q?
<dholbert> andreubotella: first and last select into the fragment tree, and nth-fragment also
<kbabbitt> s/first and last/::first-line and ::nth-fragment()/
<dholbert> andreubotella: does it make sense to treat these as a separate category? or are the restrictions on those similar enough to the groups you've defined already?
<dholbert> dbaron: It may well make sense to describe that as a category
<dholbert> dbaron: I'm not aware of any common definition, so I'm hesitant to define spec terms if we don't have a reason to do so
<dholbert> dbaron: but the classification makes some sense
<jarhar> q+
<kbabbitt> I think dbaron's list makes sense for the selectors that I understand
<dholbert> dbaron: might be premature to take a resolution on this one. but I'd encourage discussion on the issue
<Rossen6> ack jarhar
<dholbert> jarhar: for the classification question/concepts: hopefully this is related... On Mon or Tues at a joint meeting, I brought up whether new pseudo elements for customizable select should be before-like or part-like
<dholbert> jarhar: there weren't spec concepts for this but it's important for implementation
<dholbert> jarhar: if I want to make it part-like, I need to wire it to shadow tree, real element in the tree, etc
<dholbert> jarhar: would be useful to have some kind of distinction for implementors, to help steer impl strategies
<dholbert> jarhar: (on new pseudos)
<emilio> q+
<dholbert> emilio: that's the main distinction. tree-abiding may encompass other things that are like generated content
<dholbert> emilio: we want to make part-like be things that have an element behind, unrelated to the styling of the parent
<dholbert> emilio: that's how a lot of the form-control shadow trees are implemented
<Rossen6> ack emilio
<dholbert> emilio: I'm pretty sure gecko/webkit have same kinds of assumptions about generated content. It'd be kinda hard to support a lot of these pseudo-classes on before/after
<dholbert> emilio: depending on how we decide to make a pseudo-element work, you need to take one approach or the other to implmeent it
<dholbert> fantasai: could you implement a tree-abiding as a part-like pseudo-element?
<dholbert> emilio: you could, it'd be more restricted
<dholbert> emilio: if you have an actual DOM element, you can implement a part-like and tree-abiding pseudo-element
<dholbert> fantasai: you can't implement a part-like pseudo without an actual element backing it, without a lot of work
<dholbert> fantasai: ...
<dholbert> emilio: that's how placeholder is implemented in webkit and blink
<fantasai> s/.../but you could implement tree-abiding as a part-like pseudo-element with some disabled features/
<dholbert> emilio: we could change how gecko works to work that way too
<dholbert> emilio: but that's not great if we don't define what tree it is and what it works
<dholbert> Rossen6: let's move on