Re: State of subclassing and tag names in the component model

Hi Boris,

This is my current thinking, although this blends/steals a lot of ideas
from TPAC:

There are two kinds of components—ones that are a refinement of something
in HTML, like a select element or a button; and ones that have no genuine
peer in HTML.

This is the litmus test: If you were writing this today, would you start
with a div or span? Then your component is probably the second kind.

Custom tag names have a number of downsides:

A. Markup with custom tags could actually be hard to write, because the
HTML parser will have to have permissive behavior around custom tags that
won’t match developer’s intuition of how parsing works. We could let
component authors specify a context for parsing, but that would require
them to understand the parser, which is a high bar.

B. The semantics of custom tags are weak. A UA that doesn’t run JavaScript
would have to assign them a pretty neutral meaning, at least at first. (A
page well-authored for fallback may never expose a UA to this problem
though.)

C. As you point out, existing specs, implementations, stylesheets and
libraries expect certain tag names, and custom tags break that. That is a
difficult practical problem.

Recalling the two kinds of components, I think custom tag names are a bad
fit for the first kind—the kind that have a semantic cousin in HTML. A, B
and C will be problems for these kinds of components.

For the second kind, B and C are less of a problem because the component is
something totally new. Maybe custom tag names could work for those kinds of
components.

I think the way forward is for us to work on components that use an
existing tag name, and identify the component with an attribute, for now. I
think that this is superior to custom tag names for the first kind of
component, and it can trivially be used for the second kind of
component—just use div or span as the tag name.

Dominic

On Tue, Nov 8, 2011 at 6:29 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> All,
>
> At this I've lost track of what the current proposals are on tag names in
> the component model.  I've been thinking about this a bit, and I would like
> us to look at a particular use case: subclassing <img> and adding some
> behavior to it.
>
> An obvious question: Should the localName/tagName of the resulting element
> be "img" or something else?
>
> The way I see it, if it's "img" then everything should Just Work for this
> element and component binding just has to be done via an attribute.
>
> If it's something else, then as far as I can tell we would probably need
> to change various specifications to look at whatever "img" is for this
> element (not the localName anymore).  This likely includes various parts of
> HTML5, possibly selector matching for UA and maybe user stylesheets, and so
> forth.  Furthermore, the result would still not be treated as an image by
> various script libraries out there.  But maybe that's desirable?
>
> In any case, for every single place where one could consider what sort of
> element one has we would need to specify whether it's the localName that's
> being used or whatever other property evaluates to "img" or
> HTMLImageElement in this context.
>
> Is that a reasonable summary of the state of things?
>
> -Boris
>
>