- From: <bugzilla@jessica.w3.org>
- Date: Fri, 08 Feb 2013 23:07:18 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20913 --- Comment #3 from Dimitri Glazkov <dglazkov@chromium.org> --- (In reply to comment #2) > Being backed "by the proper HTMLButtonElement" on the C++ side while not > having a localName of "button" is, imo, a non-starter. > > There's lots of code in both C++ and JS that examines the localName when > working with the object and assumes that buttons will be "button". So > creating something that's an HTMLButtonElement with a different localName > means that it will work in some ways but not in others, and generally be > broken. > > It's not just style matching that depends on the localName; it's context > menus, creation of special CSS boxes, serialization behavior, editing > behavior. The list is quite long. I agree, I know for a fact we do some of this in WebKit, too. Should we perhaps have two classes of custom elements: 1) "old-style folk" that always get instantiated as <localName is=custom-name> 2) "new-style folk" that always get instantiated as <custom-name>? -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Friday, 8 February 2013 23:07:19 UTC