[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.