18738 2012-08-29 22:01:18 +0000 [Custom]: Specify that type selectors match all derived types 2013-04-10 21:00:27 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - Component Model unspecified PC Linux RESOLVED INVALID P2 normal --- 18720 1 dglazkov dglazkov bugs bzbarsky jackalmage public-webapps-bugzilla oldest_to_newest 73019 0 dglazkov 2012-08-29 22:01:18 +0000 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. 73042 1 bugs 2012-08-30 03:48:30 +0000 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. 77325 2 dglazkov 2012-10-29 21:27:03 +0000 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. 77339 3 dglazkov 2012-10-29 22:15:11 +0000 Tab, what's the likelihood of something like this flying well with CSS WG? 77345 4 jackalmage 2012-10-29 22:49:49 +0000 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. 85886 5 dglazkov 2013-04-10 21:00:27 +0000 No longer necessary. Elements, derived from built-in HTML elements are required to use type extensions.