[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 #17 from Daniel Buchner <danieljb2@gmail.com> ---
(In reply to comment #16)
> (In reply to comment #14)
> > 
> >    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?
> 
> Neither. The term "slideshow" is an opaque string with no defined meaning in
> HTML.
> 
> The above (with <x-slideshow>) is no more meaningful at an HTML level than:
> 
>     <xxx1 class="xxx2 xxx3">
>       <div class="xxx4"> ... </div>
>       <div class="xxx4"> ... </div>
>     </xxx1>
> 
> Now consider if it had been:
> 
>     <ul/xxx1 class="xxx2 xxx3">
>       <li/xxx4> ... </li>
>       <li/xxx4> ... </li>
>     </ul>
> 
> ...or:
> 
>     <article/xxx1 class="xxx2 xxx3">
>       <section/xxx4> ... </section>
>       <section/xxx4> ... </section>
>     </article>
> 
> Now I can distinguish it from:
> 
>     <select/xxx1 class="xxx2 xxx3">
>       <option/xxx4> ... </option>
>       <option/xxx4> ... </option>
>     </select>
> 
> ...because I can tell at a glance, without knowing how the components are
> defined, that the former two are lists of blocks of content, whereas the
> third is a widget with a list of options.

I think you're making the fundamentally incorrect assumption that the use of a
article/foo or <article is="foo"> means that the resulting tag has anything in
common with <article> --> it doesn't!

There is a common mechanism in the spec for telling the browser and any
accessibility tech what existing elements the widget inherits from, and that is
the extends="" attribute on the <element> tag. That is the place to say which
of the existing tags it hails from.

This is crucial and necessary so that developers don't go applying the same
widget willy-nilly to any tag they see (which would be a cluster-f, do I need
to go into the reasons why?)

> > 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.
> 
> I'm not proposing this.
> 
> We clearly need some mechanism so that authors can reuse the logic of
> <input> when extending an <input> element, but that's a separate issue.

No, it's not a separate issue. The idea that an attribute or a slash-delimited
tag name + custom tag name will inherit some characteristics from the origin
tag, but imbue a custom prototype to that element is crazy-pills.

> Personally my proposal would be that in the Web Component's definition, it
> says what kinds of elements can be bound to, so that if you define a "map"

Yep, already does, see above.

> component as applying to <select> elements and you then try to bind it as
> <img/map>, then the binding just doesn't take. (Indeed maybe the solution is

This underscores a huge issue with is="" and foo/bar - they add a fantastically
obtuse layer of silent-fail magic...when there is *absolutely no need* for it.

> to _always_ say what element the binding should be bound to, and actually
> include that as part of its name — so instead of defining a "map" component,

- So Hixie, riddle me this -

Custom element definition:

  <element name="song-recognizer" extends="input">
    <script >
      ...custom widget code here that materially relies upon the traits of an
input element. Also bakes in the desired accessibility inheritance...
    </script>
  </element>

Use of custom element, the is="" or foo/bar way:

  <div/song-recognizer></div/song-recognizer>

 - does this fail? It certaily can't take on a <div>'s proto or traits, because
remember, the custom element has been coded to *materially rely* upon the
traits of <input>

<input/song-recognizer></input/song-recognizer>

 - must I preface all my tags with input even though I defined it as such?

Besides the fact that this is ugly as sin, obviously it allows developers to
slap any custom element on any tag name. Of course we know because of the
*custom element definition* which tag it hails from semantically and for
purposes of accessibility. You are actually proposing that we ignore the tag
name the developer attaches the custom element to? Or not attach it because
they, perhaps without knowing, use it on the wrong tag? Do you understand how
meaningless the leading tag name is if it isn't a custom tag name? What benefit
does this afford? Do you understand how meaningless the leading tag name is if
it isn't a custom tag name? Why is it not enough that we have the
semantics/accessibility baked into the element definition?

> you would actually define a "select/map" component.) But I don't mind how we
> do this. My only concern here is that we not turn the Web into a soup of
> author-defined components with no defined semantics.

Using custom tag names does != component soup. Illustrated as follows:

  <element name="blog-post" extends="article">
    ...SHAZAM my blog-post custom element just inherited all semantics and
accessibility traits from the article tag!...
  </element>

<x-blog-post></x-blog-post> is far better because *it isn't a silent-fail lie*
- whereas, <article/blog-post> is because the dev could do <div/blog-post> and
get truly unexpected results.

> (Incidentally, I don't expect most components to have any role=""
> attributes, even if when it's the right thing to do. But that's a separate
> issue also.)

I expect custom element and devs to extend="ul" to inherit accessibility and
semantics from the UL element, or any other element for that matter.
Additionally, the developer, at their election, can user role="" where
appropriate.

I'll leave you with a comical, unintended consequence of forcing unnecessary,
verbose API cruft on people:

If I define all the required inheritance and accessibility traits in my custom
element definition (and they will), it renders the leading origin tag useless
in an is="" or foo/bar world - as a developer I will then do this:


Definition:

  <element name="foo" extends="input">
    ...Uh oh, is="" and input/foo is about to get hoodwinked!...
  </element>

Then the developer writes:

  <x/foo></x/foo> (adding input doesn't matter here, it is already baked!)

...and why shouldn't I, the forced verbosity does nothing to advance
accessibility or prototypical inheritance.

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

Received on Monday, 31 December 2012 18:46:43 UTC