- From: <bugzilla@jessica.w3.org>
- Date: Tue, 15 Jan 2013 01:58:12 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18669 --- Comment #41 from Daniel Buchner <danieljb2@gmail.com> --- (In reply to comment #39) > FWIW, while I used to agree that fallback in the markup of the form: > > <newfeature> foo <oldfeature> bar </newfeature> > > ...was the way to go, what I've seen of authors using new features in HTML > suggests that in practice that's not how authors do down-level shims. For > what I've seen, they tend to just use JS to swap in their HTML instead. Let's take a look at those two cases: 1) What devs will do in legacy UAs: If I'm creating something that inherits from a tag with actual functionality or contains native browser elements (select, input, etc) writing <input is="x-superinput" /> in my original HTML source is unlikely to be what developers do with or without Web Components. The reason a developer would even do such an extension of <input> with a custom element, is to accesses/extends its native methods, or injects additional DOM elements to modify its visual appearance - two things that are basically impossible to do in a browser that doesn't support advanced element APIs like Shadow DOM, etc. Additionally, let's take on the <select is="map"> case. If I were to create a canvas map of the world, and extend the select element to show my canvas representation instead, how would <select is="map"> help me as a developer? Long story short, it wouldn't. Developers creating components intended to support legacy UAs will code a custom element <x-superselect> that includes their <canvas> map element a <select> element as default content, where it makes sense for their use-case. 1) No JS available: The number of users without JS hovers around 1%. But due to the real-world use-case solution developers turn to above, even requiring <input is="x-superinput"> won't help, because developers writing jQuery plugins and UI enhancements will not code their pages this way regardless. The developers who care to degrade their content for noscript browsers are not the same ones who would be using this API. I would argue that our target audience here is web app developers. At Mozilla, we've staked the marketing of our entire component's initiative on the proposition that use of our components is exclusively for folks who can target browsers that meet various "app-ready" requirements - JS on, polyfill capable I am not aware of a single web apps coded for the Chrome and Firefox app marketplaces, that works, or is intended for, a noscript environment --- Do keep in mind, the custom element polyfill only works in recent browsers, and if developers can't polyfill it, they won't be using it - further reducing the relevance of noscript environments and legacy UAs in this conversation. Once you square the case of JavaScript disabled with reality, and the fact that developers will (and already do) include <input /> within their inflated <x-superinput> elements for various other requirements they have, we are left with near-zero actual use-case/user impact. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Tuesday, 15 January 2013 01:58:14 UTC