[css-pseudo-4] Should parent and element attributes of CSSPseudoElement interface be nullable?

[danielsakhapov]

https://drafts.csswg.org/css-pseudo-4/#CSSPseudoElement-interface has

readonly attribute Element element;
readonly attribute (Element or CSSPseudoElement) parent;

but, given the outcome of #3607, and e.g.

fc = div.firstChild;
div.removeChild(fc);
fc.parentElement; <-- is null.

I would expect the following to return null:

.beforePseudo::before { content: "before"; }

before = target.pseudo("::before");
div.classList.remove("beforePseudo");
before.parent; <-- should be null, since the pseudo is now ~"detached from DOM"?

So, I guess that parent and element attributes of CSSPseudoElement interface should be nullable?

@emilio @fantasai ?

[emilio]

Maybe? I think ::before / ::after's relationship with the DOM is not super well defined. Implementation wise we do remove them, but I think per spec they're supposed to be always present?

[danielsakhapov]

Would you expect it to behave the same as for the first child example?

[emilio]

Not sure, I think we need to define whether changing / removing the content property removes the pseudo element or not. Same for display. Also same for elements that don't generate these like input elements. What does the spec say for those?

[emilio]

The problem with your class list example is that it'd require .parent to synchronously run styling right? Which is a bit surprising at least, and a perf footgun

[danielsakhapov]

Right, sorry, I forgot to mention that I didn't include synchronisation lines (like offsetTop) between actions, just to show the need for nullability.

[danielsakhapov]

@emilio
Reading more carefully the pseudo() description:
Return values that represent the same pseudo-element on the same originating element must be, insofar as observable, always the same CSSPseudoElement object. (The UA may drop or regenerate the object for convenience or performance if this is not observable.)
Since we should return the same CSSPseudoElement, even when no pseudo element is created on ultimate originating element per CSS rules, I assume we just set that CSSPseudoElement's element and parent on creation and cache it? So, even when actual pseudo element is removed, this CSSPseudoElement still gives ultimate originating element for element.

My mistake was to treat CSSPseudoElement as live actual pseudo element from a browser engine.

I guess, it can be closed, unless you have any other concern about it?

[danielsakhapov]

Though, it probably makes sense to discuss nullability of parent (or return null from pseudo()) for elements that can't generate pseudo elements, as you've mentioned, since I couldn't find anything about them in spec.

[danielsakhapov]

I'm going to close this issue and come up with an explainer raising a bunch of questions on CSSPseudoElement.
I'll then open a new issue for each question in the explainer, so it'll be easier to track all that.

[emilio]

(Sorry for not getting to this till now)

Yeah, I think conceptually a pseudo-element should be internally represented as an element, sequence<PseudoElement> pair or so, and the .parent should always return the originating element.

But that does raise a bunch of questions about elements that generally don't render these, or what not.

[emilio]

So yeah, opening individual issues for individual questions sounds good to me, thanks @danielsakhapov :)