[css-pseudo-4] Decide between Element.pseudo(type) and window.getPseudoElements(elem,type)

[fantasai]

See https://lists.w3.org/Archives/Public/www-style/2014Nov/0035.html

Similarly, CSSOM defines Element.pseudo(type) while CSS Pseudo-Elements defines Window.getPseudoElements(elem, type) for what seems to be the same purpose. [Also, I notice that Window.getPseudoElements() takes a type, then returns a list that can be filtered by type which seems odd to me.]

I don't know what the pros and cons of each style of interface is, and I couldn't find any discussion about it in the archives, so I think we still need to decide? Also if we're going with the latter, that parenthetical needs to be addressed.

[fantasai]

Any informed opinions @tabatkins @dbaron ? Because I have no idea.

[heycam]

FWIW the PseudoElement interface and Element.pseudo() function have already been removed from the CSSOM spec. I feel like a function on Element rather than on Window is more ergonomic, but I also think it will be more common to want to get a specific pseudo rather than a list of all the pseudos that are available on the element, so maybe an API like this would be better:

partial interface Element {
    CSSPseudoElement? pseudo(CSSOMString type);
};

The old PseudoElement interface did not allow writable access to the inline style for the pseudo. The CSSPseudoElement interface does. Though the style member on CSSPseudoElement now should probably be replaced with:

CSSPseudoElement includes ElementCSSInlineStyle;

(And then perhaps ElementCSSInlineStyle should be renamed to CSSInlineStyle, since it would no longer be used just for elements.)

[css-meeting-bot]

The CSS Working Group just discussed Decide between Element.pseudo(type) and window.getPseudoElements(elem,type), and agreed to the following:

• RESOLVED: Add Element.pseudo(type)

The full IRC log of that discussion

<dael> Topic: Decide between Element.pseudo(type) and window.getPseudoElements(elem,type)
<dael> github: https://github.com//issues/3541
<dael> Rossen_: fantasai can you summarize?
<tantek> regrets+
<dael> fantasai: Two proposals for how to get the pseudoelement object. One was a .pseudo function on Element and the other way window.getPseudoElements
<dael> fantasai: They were in different specs, never discussed which we wanted though one was dropped. I wanted to know which should go in pseudo element spec
<dael> gregwhitworth: I like heycam|away proposal that hanging it off the element makes sense but passing the domstring
<dael> fantasai: I thought that's what it was, but sure
<dael> TabAtkins: I was also confused by heycam|away It's element.pseudo taking a type
<dael> gregwhitworth: Okay
<fantasai> /pseudo/pseudo()/
<fantasai> s/pseudo/pseudo()/
<dael> Rossen_: Title of the topic is element.pseudo(type)
<dael> Rossen_: I think heycam|away is more or less a summary of that and making a case for it
<dael> Rossen_: Is there a reason why we couldn't want Element.pseudo(type)?
<dael> Rossen_: I know we have gCS hanging off the window
<dael> dbaron: I think one historic reason is people envisioned multi presentations of same doc but we've abandoned that. Given that hang off element makse sense. It's simplier
<dael> Rossen_: To reiterate, if you have multip presentation where we resolve a MQ 2 ways due to view, one is small and the other is large for ex. based on this you might cascade styles differently so in one case you have a pseudo and the other not
<dael> dbaron: That's what I'm guessing it was
<dael> Rossen_: This is far fetched even today
<dael> florian[m]: Even more than it used to be
<dael> dbaron: Early API designs envisioned you might use a single doc object in 2 presentations. That's the thing we've admitted we're not going to do
<dael> TabAtkins: Yeah
<dael> Rossen_: I totally buy the historic reasoning on this
<dael> Rossen_: If we already have a decision I don't know where it's recorded that we're not persuing the multi view. I don't think there's much choice here besides hanging off element
<dael> fantasai: Are there places we've locked into not having multi presentations
<dael> dbaron: Element width and offset top, those kind of things locked us in well
<dbaron> s/width/offsetWidth/
<dbaron> s/offset top/offsetTop/
<dael> Rossen_: Even if we get to a point where we have to disambiguate...If there was a case where we need to support multi view you should be able to get element somehow. Provided there's an api to return the element for a given view, hanging off the element is still valid. Hiding the view information and give all the elements and you figure out which is which is worse ergonomics for such API
<dael> plinss: I was an original proponent for multi view and idea was it's literally the same element so there's no different version per element. But I do accept it's way late in the life of the wbe to change that and we have many APIs presuming one view. I'm not thrilled about adding more APIs that lock us in if we ever want to fix. BUt if we're dealing with functions you can add an argument for an extra view and if it's not passe dyou get default. We can work around
<dael> TabAtkins: Without considering this issue typedOM added stylebased elements as well. View will have to bend around reality if they ever happen.
<dael> Rossen_: Back to topic at hand, any reason to not go with Element.pseudo(type) ?
<gregwhitworth> That sounds like consensus to me
<dael> Rossen_: Given all the arguments to how we got to where we are, any objections to resolve to add Element.pseudo(type)?
<dael> RESOLVED: Add Element.pseudo(type)

[fantasai]

@heycam Can I get your review on this https://drafts.csswg.org/css-pseudo-4/#cssom ? If it ever actually regenerates...

Also, lmk if I should delete all the issues left in this section of the draft yet? Given Mozilla is implementing, we should probably be a little more confident about what we're doing here, I think.

[heycam]

We need some wording about the identity of the object returned by pseudo(), for example whether it's required to be the same object each time you call it on an element with a given type.

Now that I think about it, if we do require that the same object is returned, what does it mean for the CSSPseudoElement object if we restyle the element and the pseudo goes away (and so null would be returned from another call to pseudo())? Is the CSSPseudoElement detached in some way? If we restyle again and the pseudo-element is recreated, does the old CSSPseudoElement remain functional? Might it be simpler to always return an object for a supported pseudo type, regardless of whether the pseudo currently exists?

I wonder if we should leave ::selection off this list. It feels like a pretty different thing from ::before, ::after, ::first-letter, and ::first-line, all of which basically have a box corresponding to them (at least for Gecko). Or would it be allowed to return a CSSPseudoElement for ::selection but not to support e.g. Web Animations targeting it?

The sentence

The EventTarget interface [DOM-LEVEL-2-EVENTS] must be implemented by all instances of CSSPseudoElement as a conformance requirement of this module.

is redundant with the CSSPseudoElement implements EventTarget; line in the IDL, so we probably don't need it.

If the answer to #3540 is to remove .style, then yes I think all the issues in this section can be removed. If no, then we should do what that issue says, and make the rules in there cascade normally. (For the purposes of getting what we need for Web Animations targeting we don't need .style, but I'll let @birtles reply definitively in the other issue.)

Otherwise the change looks good to me, thanks.

[fantasai]

Split off your first two issues into #3607 (Identity of Element.pseudo()) and #3540; fixed the cascade issue and removed the redundant sentence.

[fantasai]

Thanks for the review~