Re: [csswg-drafts] [css-pseudo-4] Decide between Element.pseudo(type) and window.getPseudoElements(elem, type) (#3541)

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)`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: Decide between Element.pseudo(type) and window.getPseudoElements(elem,type)<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/3541<br>
&lt;dael> Rossen_: fantasai can you summarize?<br>
&lt;tantek> regrets+<br>
&lt;dael> fantasai: Two proposals for how to get the pseudoelement object. One was a .pseudo function on Element and the other way window.getPseudoElements<br>
&lt;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<br>
&lt;dael> gregwhitworth: I like heycam|away proposal that hanging it off the element makes sense but passing the domstring<br>
&lt;dael> fantasai: I thought that's what it was, but sure<br>
&lt;dael> TabAtkins: I was also confused by heycam|away It's element.pseudo taking a type<br>
&lt;dael> gregwhitworth: Okay<br>
&lt;fantasai> /pseudo/pseudo()/<br>
&lt;fantasai> s/pseudo/pseudo()/<br>
&lt;dael> Rossen_: Title of the topic is element.pseudo(type)<br>
&lt;dael> Rossen_: I think heycam|away is more or less a summary of that and making a case for it<br>
&lt;dael> Rossen_: Is there a reason why we couldn't want Element.pseudo(type)?<br>
&lt;dael> Rossen_: I know we have gCS hanging off the window<br>
&lt;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<br>
&lt;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<br>
&lt;dael> dbaron: That's what I'm guessing it was<br>
&lt;dael> Rossen_: This is far fetched even today<br>
&lt;dael> florian[m]: Even more than it used to be<br>
&lt;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<br>
&lt;dael> TabAtkins: Yeah<br>
&lt;dael> Rossen_: I totally buy the historic reasoning on this<br>
&lt;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<br>
&lt;dael> fantasai: Are there places we've locked into not having multi presentations<br>
&lt;dael> dbaron: Element width and offset top, those kind of things locked us in well<br>
&lt;dbaron> s/width/offsetWidth/<br>
&lt;dbaron> s/offset top/offsetTop/<br>
&lt;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<br>
&lt;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<br>
&lt;dael> TabAtkins: Without considering this issue typedOM added stylebased elements as well. View will have to bend around reality if they ever happen.<br>
&lt;dael> Rossen_: Back to topic at hand, any reason to not go with Element.pseudo(type) ?<br>
&lt;gregwhitworth> That sounds like consensus to me<br>
&lt;dael> Rossen_: Given all the arguments to how we got to where we are, any objections to resolve to add Element.pseudo(type)?<br>
&lt;dael> RESOLVED: Add Element.pseudo(type)<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3541#issuecomment-459028840 using your GitHub account

Received on Wednesday, 30 January 2019 17:16:04 UTC