[csswg-drafts] What should `pseudo(type)` return for elements that can't have pseudo elements? (#12159)

danielsakhapov has just created a new issue for https://github.com/w3c/csswg-drafts:

== What should `pseudo(type)` return for elements that can't have pseudo elements? ==
Full context: https://github.com/danielsakhapov/CSSPseudoElementDoc?tab=readme-ov-file#22-elements-without-pseudos

Description:
[CSSPseudoElement](https://www.w3.org/TR/css-pseudo-4/#CSSPseudoElement-interface) object is returned from [pseudo(type)](https://www.w3.org/TR/css-pseudo-4/#window-interface) if `type` is parsed correctly, but what about elements that can't have pseudo elements - e.g. `<input>` and `::before`?

Possible solutions:
* Return a `CSSPseudoElement` object (whose state/computed style then reflects non-generation)
    * **Pros:**
        * API Consistency: `Element.pseudo(validPseudoTypeString)` always returns a `CSSPseudoElement` object. `null` is reserved only for invalid/unrecognized type strings.
        * Separation of Concerns: `Element.pseudo()` provides the handle; [`.exists`](https://github.com/w3c/csswg-drafts/issues/12158) (potentially) on that handle reveals rendering state as per CSS rules.
        * Robust Introspection: Allows developers to get the object and check its computed style (e.g., `display: "none"`, `content: "none"`) to confirm and understand its non-rendered state.
        * Alignment with Highlight Pseudos: Consistent with `::selection` where an object can exist even if no selection is active.
        * Forward Compatibility: If CSS rules change, the API behavior for `Element.pseudo()` remains stable.
    * **Cons:**
        * Indirect "Existence" Check: Developers need to get the object and then inspect its computed styles(or potentially [`.exists`](https://github.com/w3c/csswg-drafts/issues/12158)) to confirm it's not actually rendered, rather than just checking for `null`.
        * Potentially "Useless" Objects: Creates an object that might not correspond to anything visible or affecting layout.
* Return `null`
    * **Pros:**
        * Direct Feedback: Immediately signals to the developer that this specific combination of element and pseudo element type is not valid or won't render.
        * Simpler "Existence" Check: `null` means it doesn't exist in this context; no further checks needed on a pseudo-object.
    * **Cons:**
        * Inconsistent API Signature: `Element.pseudo()` would return `null` for two different reasons (invalid pseudo selector string or valid selector on an incompatible element), making error handling more complex.
        * Less Introspection: Prevents developers from getting a handle to inspect why it doesn't render (e.g., to check default computed styles for such a conceptual pseudo).

**Recommendation:**
Return a `CSSPseudoElement` object. This approach is generally favored because it provides a more consistent and predictable API contract (`null` only for invalid pseudo element type strings), and the author can use e.g. [`exists`](https://github.com/w3c/csswg-drafts/issues/12158) to determine whether the object exists. The discussion is probably needed on if `parent` and `element` should be `null` in that case?

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12159 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 5 May 2025 13:01:34 UTC