[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 #14 from Daniel Buchner <danieljb2@gmail.com> ---
(In reply to comment #13)
> I'm not at all comfortable with the idea of switching from is= to <tag. For
> exactly the reasons that have been raised so many times around accessibility
> and future extensibility.
> 
> I do sort of like the idea of using <select/foo>. While it initially felt
> very hacky, I can't actually think of any major problems with it. I
> definitely think it's worth exploring.

Jonas, Hixie, I would appreciate actual answers to the questions in this thread
surrounding this *fundamental API decision*. I have conviently listed all the
issues that need answers:

The problems with is=""

1) is="" is being touted as a boon to accessibility, it suffers many flaws:

 - if you add is="foo" to a ul, it *does not* mean that the instance of the foo
custom prototype is taking on the characteristics of an unordered list - this
is essentially a license to throw is="foo" on *anything* - think of the obvious
calamity that ensues...

 - because there is no characteristic/prototypical relationship given <ul
is="foo">, the author *still* will need to specify characteristics via the same
mechanism (and rightly so!) that they would if we used tags --> setting the
role="" property of the custom prototype

2) The is="" interface is an ergonomic landmine

 - Attributes are *assumed* by developers to be mutable, and rightly so! With
is="", you must understand, that changing/removing the value of is="" *does
not* remove or change the now-augmented prototype associated with the element
in question. Devs will and have (literally in front of me) assumed this to be
how it operates. This is terrible ergonomics, just for clarity and honesty to
the developers out there, can we at least rename it from is="" to
footgun=""...seriously...

3) View Source scanning becomes an archeological exercise

 - Let's imagine I choose to view source of a web page. I see the following
section of markup:

   The is="" case: 

   <div class="outer pretty-block" is="slideshow">
     <div class="box-shadowed">
       ...
     </div>

     <div class="box-shadowed">
       ...
     </div>
   </div> 

   The custom tag name case:

   <x-slideshow class="outer pretty-block">
     <div class="box-shadowed">
       ...
     </div>

     <div class="box-shadowed">
       ...
     </div>
   </x-slideshow>

Which one clearly, immediately, obviously tells me as a view source user that
it is a slideshow? God forbid you miss an is="" somewhere, anywhere, in a tag's
possibly long list of attributes, and make a completely incorrect assumption
about the markup you're viewing! The is="" API forces the user to scan a
tangled web of attributes for an attribute that fundamentally changes the
identity/prototype of the tag it is applied to - in a word: facepalm. With tag
names, static source becomes a much more transparent mechanism for
reviewing/editing markup. Empirically speaking, going with is="" is regressive
to the cause of transparent web code.

4) <ul is="foo"> does not mean HTMLFooElement inherits from HTMLUListElement -
and for good reason!

 - Extending from an existing tag's prototype is declared in the <element"> or
document.register interface, not through some casual, chancy application of an
is="" attribute to whatever tag you fancy - this is extremely important.

 - The code a developer applies to the custom prototype of an element (or used
within its scoped script) can, and will on many occasions, materially rely on
inherited native element prototypes. If I generate a custom element that
contains baked-in code to use the inherited this.value mechanism (as inherited
from an element like HTMLInputElement) and it's applied to a tag like <div>,
what is the result? Are we really suggesting an inception-like API where devs
can apply <div is="foo"> in source, but instead of inheriting from
HTMLDivElement it's an extension of HTMLInputElement, and renders as what? This
becomes a nauseating scavenger hunt to unmask the true identity of markup.

---

To account for the supposed accessibility concerns with using tag names, as
previously stated, we have existing element prototypes that can be extended and
infer their accesibiloty characteristics, and the role="" property, which can
be baked into the custom element's prototype - either way, those are the most
reliable mechanisms - and either API route can utilize them.

Before you all make this decision, let's be clear, let's be honest: you lose
nothing on the accessibility side going with tag names, but going with and
attribute like is="" opens a Pandora's Box of API insanity and use-case
gotchas.

Jonas, Hixie, please take some time to think through the questions and concerns
I've outlined above - it is crucial we get this right.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Saturday, 29 December 2012 16:42:25 UTC