- From: François REMY <francois.remy.dev@outlook.com>
- Date: Mon, 26 Aug 2013 20:02:03 -0700
- To: "'Simon Pieters'" <simonp@opera.com>, <www-style@w3.org>
± > By the way, if I can make some suggestion, we should probably expose ± > both "parentNode"/"parentElement" properties on a pseudo-element, as ± > well as a "tagName"/"nodeName" whose value would be "::before" or ± > "::after". Otherwise, you've no idea which pseudo-element you work with ± > if you get a reference to one. ± ± Good point. Are the use cases for this are similar to those of ownerNode (or ± parentElement) on CSSStyleDeclaration? I guess some the use cases could be similar. For now you can hardly use pseudo-elements directly so this is more a move that will make sense when other API will support it as well. For example, I would not imagine how some sort of futuristic version of "querySelectorAll" called with a pseudo-element selector would be able to give you a list of matching pseudo-elements if you can't trace them back to their originating element properly. But, as of now, I don't really have use cases since this API does not exist yet and I didn't really consider what it could bring us. I'm sure Tab has some ideas, though. Anyway, I'm also inclined to say it would have to be used with extreme caution at the beginning because I can already see ENOURMOUS perf issues in webkit/blink just by trying to know if a pseudo-element exists or not (by checking its computed style's "content" property; my own JS implementation is light year faster for some reason which seems to be related to webkit creating the element when I ask for its style, then probably having to manage all them after that). Or maybe this will be a good opportunity for browser vendors to up their game here, I don’t know.
Received on Tuesday, 27 August 2013 03:02:48 UTC