What should `pseudo(type)` return for elements that can't have pseudo elements?

[danielsakhapov]

Full context: https://github.com/danielsakhapov/CSSPseudoElementDoc?tab=readme-ov-file#22-elements-without-pseudos

Description:
CSSPseudoElement object is returned from pseudo(type) 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 (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) 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 to determine whether the object exists. The discussion is probably needed on if parent and element should be null in that case?