[css-pseudo] Add a property to the `CSSPseudoElement` IDL interface to determine if a pseudo element "exists"

[danielsakhapov]

Full context: https://github.com/danielsakhapov/CSSPseudoElementDoc?tab=readme-ov-file#21-existence-confusion

Description:
CSSPseudoElement object is returned from pseudo(type) if type is parsed correctly, whether the corresponding pseudo element is rendered or not doesn't matter.
Developers might need a clear way to distinguish if the pseudo element is being "live" or rendered.

Possible Solutions:

• A dedicated exists property or isGenerated() method:
  • pseudoElement.exists (nullable boolean, read-only)
  • Pros: Explicit and clear, allows to specify the return value on a per pseudo element basis.
  • Cons: Adds new API surface. Defining "exists" precisely across all pseudo element types can be tricky (e.g., does ::selection "exist" if nothing is selected but it could be styled? - potentially return null here).
• getComputedStyle() inspection:
  • Check getComputedStyle(pseudoElement).display !== 'none'. For ::before/::after, also check getComputedStyle(pseudoElement).content !== 'none'.
  • Pros: Uses existing mechanisms.
  • Cons: Indirect; might not cover all cases (e.g., a pseudo element that exists but has 0x0 dimensions and no visual content). For highlight pseudos, "display" might not be the relevant property. Sometimes depends on the originating element style.
• Layout Information:
  • Methods like a hypothetical pseudoElement.getBoundingClientRects() returning an empty list or specific values could indicate non-existence or non-rendering.
  • Pros: Provides practical information.
  • Cons: Might be expensive to compute just for an existence check.

Recommendation:
Go with exists, as it gives more control for each pseudo element while unifying an interface to get the needed information. As new pseudo elements are added to be returned from pseudo(), the spec will be updated to define the meaning of exists for them.

Otherwise: Relying on getComputedStyle() initially seems pragmatic, given the limited list of pseudos supported currently. For highlight pseudos, "existence" might mean "has associated ranges/segments."

[flackr]

As long as we all agree that the CSSPseudoElement is returned regardless of whether it is currently "rendered", we could punt on this. That said, I think having a property similar to the isConnected property is better than developers inspecting the computed style which seems like it would impose an additional requirement that we compute display to none when the pseudo element isn't rendered, and there would be cases where display would compute to none even when the pseudo was otherwise rendered (e.g. author styled to none).

I assume this also means that the object instance returned remains the same for subsequent calls to pseudo(type) even if that pseudo isn't currently rendered. E.g.

<style>
.has-before::before { content: "::before"; }
</style>
<script>
const before1 = elem.pseudo('::before');
const before2 = elem.pseudo('::before');
assert_equals(before1, before2);
elem.classList.add('has-before');
const before3 = elem.pseudo('::before');
assert_equals(before2, before3);
</script>

[kbabbitt]

+1 to preferring an explicit API for this over inspecting computed style on the pseudo element. IIRC, in most cases style computation on the originating element gives us enough information to determine which pseudos will be generated. It would be unfortunate perf-wise to have to also compute style for a pseudo just to check whether it's generated.

[css-meeting-bot]

The CSS Working Group just discussed Add a property to the `CSSPseudoElement` IDL interface to determine if a pseudo element "exists".

The full IRC log of that discussion

<sakhapov> sakhapov
<ydaniv> sakhapov: want to discuss pseudo-element interface to use it from JS
<ydaniv> ... element.pseudo, if object is valid the the pseudo is used
<ydaniv> ... has several props like using identity for event delegation
<ydaniv> ... ability to distinguish if element is rendered or exists
<ydaniv> ... add property exists per element
<oriol> q+
<ydaniv> ... si add property per element defined and supported
<ydaniv> oriol: not sure if this make sense for some elements
<ydaniv> ... whether this interface would be able to work for any element, or just tree-abiding ones
<ydaniv> ... not sure whether it's well defined
<ydaniv> ... also whether if there's a generated box for this element
<ydaniv> ... you only want to check whether it exists or not
<ydaniv> ... also has perf concerns, to check if has generated boxes
<ydaniv> ... so makes sense to add extra APIs for these
<flackr> q+
<ydaniv> sakhapov: for now defined only for 4-5 elements
<astearns> ack oriol
<ydaniv> ... we can later defined for other elements, and having same interface for element and pseudo
<ydaniv> ... each opseudo is unique and different, so makes sense to define per element, and later generalize
<ydaniv> oriol: so makes sense to define per element if box exists or something different
<ydaniv> sakhapov: yes, for example for :column
<ydaniv> flackr: I think Daniil covered all my points, part of goal here to define the exists and can be different, like whether selection exists
<astearns> ack flackr
<ydaniv> ... part of it is defined whether exists, because if has box is different
<schenney> q+
<ydaniv> sakhapov: gCS for highlight pseudos it returns styles as if active, so not same as box is present
<astearns> ack dbaron
<ydaniv> dbaron: I think this seems reasonable, agree we define existance per element
<ydaniv> ... for customisable select we defined sepcific mechanism, my intuition is that it should return true only if has select on element, .... <missed>
<TabAtkins> Big +1 to dbaron (and I think I feel a bit more strongly about it)
<dbaron> questions: 1. whether ::checkmark existing depends on whether the <select> has appearance:base-select
<dbaron> 2. whether ::checkmark existing depends on whether the popup is open
<astearns> ack schenney
<dbaron> 3. (from alan?) whether ::checkmark existing depends on whether the option is currently checked
<dbaron> (I think yes to 1 but not to 2 and 3, but we probably need to define the underlying principles.)
<ydaniv> schenney: for many pseudos it should return whether active or not has also privacy concerns, so we return regardless same style
<fantasai> Definitely no dependency on #3 -- ::checkmark is intended to be available for styling iconography in the unchecked state as well.
<ydaniv> ... also currently defined 4 pseudos availabe, and we can define for each case
<ydaniv> ... we can punt on the rest later
<astearns> q+
<ydaniv> astearns: a little concerned about having this single member mean different things for different pseudos and whether has a single true on false for different cases
<ydaniv> ... sometimes you want to tell whether there's a box, so I think we should take this back to the issue
<flackr> qq+
<ydaniv> ... define what this might mean per element or whether we can define something genetal
<astearns> ack flackr
<Zakim> flackr, you wanted to react to schenney
<ydaniv> s/genetal/general/
<astearns> ack astearns
<ydaniv> flackr: should define whether something is defined for this check and whether needs better definition, we should be talking about actual use-cases
<kbabbitt> +1 to flackr
<fantasai> +1 flackr
<schenney> +1
<ydaniv> astearns: any comments
<ydaniv> ... taking it back to the issue and define per element and get a clear picture first
<ydaniv> sakhapov: sounds good

[danielsakhapov]

Following the discussion, I gave this issue more thought. Please, take a look and leave a comment, especially about the table!

Use Cases (from my head)

1. Conditional event listeners or observers: Attaching listener/observer/animation only if a pseudo-element exists and is being rendered.
2. Performance optimization: Avoid computing layout-heavy styles, if the pseudo doesn’t affect rendering.
3. Testing: Checking for the presence of visual pseudo content is valuable.
4. Conditional content generation: Dynamically {insert additional}/{change existing} content in e.g. ::before, if it’ll actually be used.

What should CSSPseudoElement.exists mean?

In most layout-related cases (e.g. ::before, ::after, ::marker), "box is generated" sounds most reasonable.

For range-based and semantic pseudos (e.g. ::selection, ::highlight, ::cue, ::grammar-error, ::checkmark), a “is active” or “has matching range” approach is better.

So, to be future proof and being able to define CSSPseudoElement for more pseudo-elements, I suggest:

CSSPseudoElement.exists to return: true / false / null:

• true -> actively present/rendered/... defined on per-pseudo-element basis.
• false -> opposite of true.
• null -> not applicable or indeterminate (e.g., author shouldn’t be relying on it).
  This avoids over-promising, while still providing usefulness in most use cases.

CSSPseudoElement.exists Behavior Table

Pseudo-element	When .exists === true	Notes
::before / ::after	content is non-none and generates a box	false for empty or content: none, null when no style is defined
::first-line	Element has stylable inline text	false for empty/non-text elements, null when no style is defined
::first-letter	Stylable first character present	same as ::first-letter
::placeholder	Placeholder is visible (no user input yet)	false when field is filled, null when no style is defined
::selection	There is an active selection in the element	false if no text is selected, null when no style is defined
::highlight(name)	Named Highlight intersects visible element content	false otherwise, null when no style is defined
::spelling-error	Spellchecker detects error	Depends on UA/platform support
::grammar-error	Grammar issue detected and styled	Depends on UA/platform support
::marker	Element is styled as list-item and marker is rendered	false otherwise, null when no style is defined
::checkmark	Control renders internal checkmark (e.g., via appearance: auto)	Depends on UA and platform conventions
::dropdown	Native dropdown arrow is shown	false otherwise, null when no style is defined
::cue	Active WebVTT cue is displayed	false otherwise, null when no style is defined
::backdrop	Element is modal or in fullscreen state	false otherwise, null when no style is defined
::scroll-marker	content is non-none and generates a box and ::scroll-marker-group exists	false for empty or content: none or no ::scroll-marker-group, null when no style is defined
::scroll-marker-group	Defined in style via property and pseudo style and generates a box	false (or null for consistency?) when no style is defined

Special / Unresolved Cases

Pseudo	Notes
::target-text	Possibly true when fragment-activated text is present
::view-transition-*	Would need clear phase-specific definitions
::part(name)	Shouldn't be represented as CSSPseudoElement probably? true -> shadow tree contains a matching part
::slotted(selector)	Shouldn't be represented as CSSPseudoElement probably? true -> one or more matching nodes are slotted
Unsupported pseudos	CSSPseudoElement won't be obtained for those, but just in case: .exists === null if pseudo not applicable in current context

[danielsakhapov]

@dbaron @tabatkins @emilio @fantasai ptal

[schenney-chromium]

For privacy reasons ::spelling-error, ::grammar-error, ::target-text and ::search-text cannot report anything about whether they are active. An attacker could craft content that identified the user's personal dictionary, or the terms on the page they are interested in. ::selection is sort of questionable too.

[danielsakhapov]

I guess then those pseudos will always return null for privacy reasons