This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Since we're using custom tags now, we need to modify the meaning of type selector to match tag names of all elements in the prototype chain.
Could you explain what this is actually about. (I think you mentioned this last week, and this still feels überscary :) ) Special casing APIs makes them in general worse. Also, we need to make sure to not slow down selector matching.
I think it was Boris who came up with this. http://dev.w3.org/csswg/selectors4/#type-selectors In order for <x-button> (a subclass of HTMLButtonElement) to also match UA styles for <button>, we redefine "element type" to mean: 1) the element itself -- x-button 2) all types it is inherited from -- button.
Tab, what's the likelihood of something like this flying well with CSS WG?
Good question! I dunno. I mean, *ultimately* it's the responsibility of the host language, not CSS, to define the tree that Selectors match over. It can potentially define *whatever it wants* to match the string in a "tag" selector, or a "class" selector. However, we should poke at the CSSWG to make sure other people don't think we're crazy for doing this.
No longer necessary. Elements, derived from built-in HTML elements are required to use type extensions.