- From: J. S. Choi <notifications@github.com>
- Date: Sat, 30 Dec 2017 02:05:39 +0000 (UTC)
- To: w3c/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/webcomponents/issues/719/354521723@github.com>
@bkardell A tangential but still-related question: By “much discussion/proposals around what to do [about CSS selectors for `HTMLHeadingElement`s]”, do you mean [Tab Atkins’ CSS Extensions](http://tabatkins.github.io/specs/css-aliases/) or something else? I’m planning to eventually propose a `:heading` pseudo-class, and so I did a literature search for such prior discussions. The only ones that I’ve yet found have only been CSS Extensions (see also [2014-01-29 CSSWG Seattle F2F PM-III minutes](https://lists.w3.org/Archives/Public/www-style/2014Feb/0610.html)) and a [2009 throwaway proposal by Giovanni Campagna on www-style](https://lists.w3.org/Archives/Public/www-style/2009Mar/0286.html). *** The original post presumes that all major UA vendors will ever even reach consensus on implementing customized built-in elements (cf. w3c/webcomponents#509, w3c/webcomponents#648). Assuming that consensus does occur in favor of keeping them, then a CSS pseudo-class like `:element(my-element)` may be useful. `:element(my-element)` would in this case select instances of `MyElem ` and `MyMoreSpecificElem`—i.e., any DOM `Element` whose class inherits from whatever class with which `customElements.define` registers the `my-element` tag. Of course, even then, there might be significant timing problems in the interactions between CSS cascading and custom-element registration… -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/webcomponents/issues/719#issuecomment-354521723
Received on Saturday, 30 December 2017 02:06:03 UTC