- From: <bugzilla@jessica.w3.org>
- Date: Fri, 11 Jan 2013 10:29:49 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18669 --- Comment #33 from Daniel Buchner <danieljb2@gmail.com> --- (In reply to comment #27) > The point of <select/map> is that it parses as <select> in legacy UAs, and > in Web-component-supporting UAs it is treated as <select> and immediately > bound to the "map" component. This requires parser changes, but parser > changes significantly less drastic than anything we need for web components > already with <template>. For element creation, you'd create a Map directly > with "new Map()". For selectors, you'd probably use a new pseudo-class a la > ":component(map)" or some such. So, to make sure I am understanding you: you're saying div in <div/map> isn't really like an attribute, in that it is parsed out and not allowed to be dynamically added using setAttribute? If this is true, and you're saying this slash-escaped hack for existing UAs is going to be essentially formalized as an interface, how do I create custom elements imperatively using document.createElement? I assume you're going to submit one of these two responses: 1) We must make YAODAC (Yet Another One-off DOM API Change), this time to document.createElement, to accept document.createElement('div/map'); or 2) We introduce YAWCAC (Yet Another Web Components API Caveat) by leaving createElement as is, and telling devs "for native elements, you can use createElement, but for custom elements you need to use new Map(). Hixie, in the case that map can be applied to several kinds of native elements, what's your plan for how the developer specifies which one to use when invoking the imperative constructor new Map()? Let me guess, YAWCAC? -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Friday, 11 January 2013 10:29:50 UTC