[Bug 18669] Switch from is= to <tag if a decision has been reached among implementers

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