[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 #16 from Ian 'Hixie' Hickson <ian@hixie.ch> ---
(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.


> 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. 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" 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 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, 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.

(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.)

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

Received on Sunday, 30 December 2012 19:02:25 UTC