http://dvcs.w3.org/hg/webcomponents/rev/fd5cd6d8f9f3

Section 5.2 shows an example with is=

(In reply to comment #2)
> Section 5.2 shows an example with is=

Do you mean in explainer? I will update that later. It's out of sync on lots of things right now.

Yes I meant the explainer, it is what people find on google when they type web components. :)

Ok.

Hixie protests going with tags in bug 18863:

-- begin --
Ian 'Hixie' Hickson 2012-12-14 22:45:31 UTC
I still think that this whole thing of allowing authors to just make up element names is a REALLY BAD IDEA. It's the whole XML fiasco all over again. People are just going to make up their own elements, with no fallback, no semantics, no way for search engines to know what's going on, no way for accessibility tools to work out what's going on, no way for older UAs to work out what's going on, no way to quickly swap out one widget set and swap in a new one, etc.

I really think this is the single biggest mistake of the Web Components work.
-- end --

I would really like to reach some sort of consensus here. Neither "is" nor tags solution is without warts. We need to definitively determine which one has fewer warts and go with that. I thought we've done this, but not widely enough. Let's do it again, then.

I think it's bad to move this spec along to FPWD when Ian is actively against this part.

I've been shopping both "is" and custom tags to developers. The biggest problem with attribute approach is that it's basically cruft: nobody expects it to be the _identity_ of the element. Here's the best illustration of the confusion: http://www.youtube.com/watch?v=JNjnv-Gcpnw&feature=player_detailpage#t=1585s

Watch how both the presenter and the member of the audience immediately presume that not reacting to changes to "is" attribute is a bug.

For the identification and parsing of Custom Elements I strongly favor the use of tag names vs an attribute, such as is="", for the following reasons:

1) In terms of developer ergonomics, for both conceptual understanding and in practical use, it is much easier to deal with and "x-modal" tag vs a random tag with is="x-modal" applied.

2) To use an attribute to signify the prototypical identity of an element is an unexpected inference laced with vagary, it introduces a whole host of other problems, as 3, 4, and 5 will highlight in detail.

3) Developers assume attribute values to be mutable, and that they have an effect when changed. Though you may be able to cite one-off cases where this is not the case, the common paradigm developers are used to would make this instance of a secretly locked, immutable attribute value, arguably one of the most convoluted APIs ever produced.

4) Developers worth their salt will assume prototypical inheritance from the tag on which the is="" attribute is applied - this is a head-fake for developers. The extends linkage is created in the Custom Element definition, and if we use attributes, a developer will be left to wonder what mix of prototype they are being dealing with.

5) What happens when a developer uses removeAttribute() understandably believing removal of the is="" attribute restores the target element's prototype to whatever tag it was applied to? No other attribute I am aware of leaves such a strong, secretive, lasting effect on an element.

To mitigate semantic concerns of some who favor the is="" attribute, I would point developers at role="" for accessibility and semantic expression. Additionally, the Custom Element API already has the extend concept baked in, which allows custom tags to inherit the prototypes of existing, semantic elements.

Using an attribute for this would be an ***extremely poor API choice***. It opens the door to countless gotchas and landmines developers will never expect. Honestly, after taking stock of the pros/cons at play in this decision, I don't see how anyone would think using an attribute for this purpose is a good idea.

I'd be fine with not using an attribute if we have some other solution. My concern is that people will abandon the use of semantic HTML in favour of Web components, in much the same way that they used <font> or <div style="">s. This hurts accessibility, it hurts search engines, it hurts maintainability, and it hurts backwards-compatibility (graceful degradation). I would like to avoid this by requiring that authors use regular HTML elements that they then _augment_ using Web components.

One way to do that is an is="" attribute on creation. Another is new syntax, e.g.:

   <select/map>

...where "select" is the HTML semantic, and "map" is the component. (This would parse as <select map=""> in legacy UAs, but in new UAs we could make it something special that doesn't use attributes.)

I understand that whatever we do, people will end up doing stupid things like <div/textfield> instead of extending <textarea> or <input>, or whatever. People will always get it wrong. But please please please let's at least make it possible to do it right and let's encourage it.

(Note that in the video above, the presenter says she wants to be able to change the binding live. She calls it "absolutely crucial". :-) )

(In reply to comment #8)
> I'd be fine with not using an attribute if we have some other solution. My
> concern is that people will abandon the use of semantic HTML in favour of
> Web components, in much the same way that they used <font> or <div
> style="">s. This hurts accessibility, it hurts search engines, it hurts
> maintainability, and it hurts backwards-compatibility (graceful
> degradation). I would like to avoid this by requiring that authors use
> regular HTML elements that they then _augment_ using Web components.

1) What prevents the developer, or would even dissuade them, from using normal, semantic elements *inside* their components?

2) The whole accessibility/browser/search engine issue being raised seems like a boogieman --> Is role="navigation" not just as capable of expressing to browsers, search engines, etc. these associations?

3) If a developer uses role="", how is graceful degradation affected?

4) Why are you assuming the browser will act on <nav is="x-supernav"> as if it hails from the nav element's prototype? The generated custom element prototype does not inherit the prototype of the element that is="" is applied to, that extend flow happens in the <element> declaration - so again, how is this a concern when you have role=""?

5) If you are assuming that we should allow is="" to, by simple addition to the element and magical inference, merge or inherit the custom element's defined prototype, what happens when a developer sees that it is an attribute and thinks they can throw it on any element they choose? I see a whole fun Pandora's Box of unexpected behavior and bugs just lying in wait there...

> (Note that in the video above, the presenter says she wants to be able to
> change the binding live. She calls it "absolutely crucial". :-) )

What she doesn't realize, is that it isn't really "absolutely" crucial, and even if it was, it doesn't mean we need to make this an attribute to do so. There are other options (that are arguably more intuitive) to accomplish custom element switching in a true custom tag world, here are a couple:

1) We already have a document method perfect for this case: document.renameNode - http://www.w3.org/TR/DOM-Level-3-Core/core.html#Document3-renameNode

2) The developer can create the other type of custom element they want to switch to, and drop the child elements into it.

I'd love to get some feedback to these possible solutions and questions, because *every single developer* I've talked to (and we've gotten a *lot* of feedback) have balked at the attribute route. I've heard it called: "unicorn magic", "opaque", "massive inference", "a View Source headache" etc - and if we don't have to go that route then I would strongly advise we avoid doing so.

FWIW document.renameNode() is not implemented, is not in the latest DOM standard, and given bug 13971 does not look like it will be added soon. (Does not matter much either way though, I think.)

(In reply to comment #10)
> FWIW document.renameNode() is not implemented, is not in the latest DOM
> standard, and given bug 13971 does not look like it will be added soon.
> (Does not matter much either way though, I think.)

I am aware renameNode is not implemented in agents today - the point is, saying "we want component switching behavior" != "we need to use attributes component declaration".

It is arguable that such behavior would be a 80% case, and the developer can simple create a different element and drop the children in - the idea there is some prohibition on switching is an invented issue.

Haha, lots of fat-fingery and grammatical errors in that last comment - excuse me :)

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.

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

(In reply to comment #9)
> 
> 1) What prevents the developer, or would even dissuade them, from using
> normal, semantic elements *inside* their components?

Generally speaking, I wouldn't expect there to _be_ semantics that make sense inside a component. Consider for example if the author is making a telephone text field where as you type it fills the template in (something done a lot these days with hacky JavaScript and underscores, in a rather painful fashion). What semantics would you expect to see inside the component? It's all pixels at that point. (Which is fine.) The semantic is "this is a text field", and that's at the level of the whole component, not the insides.

Don't forget that sometimes the component won't be used. Just like how JS is sometimes disabled, and CSS sometimes not used, components will sometimes not be used. Whether this is because it's a legacy UA, or a simple spider, or an accessibility tool that only looks at the outer DOM — HTML should still work.


> 2) The whole accessibility/browser/search engine issue being raised seems
> like a boogieman --> Is role="navigation" not just as capable of expressing
> to browsers, search engines, etc. these associations?

I'm not especially concerned about people making new widgets to replace <nav>. Such widgets would almost certainly just be presentational things and should be bound via CSS anyway, it's a non-issue.

It's the components that introduce widget variants, and so forth, that I'm more worried about. There's no "role" that defines an <input type=text>. <input type=text> has all kinds of complicated behaviours like caret placement, spelling checking, form submission, etc, which a component will need to provide but which a <div> does not provide.


> 3) If a developer uses role="", how is graceful degradation affected?

role="" is not magic fairy dust that makes everything work. It's a very coarse mechanism to label elements with how they should be reported in screen readers, essentially; it doesn't _do_ anything. Just because you mark something as a checkbox with role="" doesn't mean it's an accessible checkbox. You still have to implement all the key handling and form submission and mouse handling and so on.


> 4) Why are you assuming the browser will act on <nav is="x-supernav"> as if
> it hails from the nav element's prototype?

I don't think I do assume that.


> 5) If you are assuming that we should allow is="" to, by simple addition to
> the element and magical inference, merge or inherit the custom element's
> defined prototype, what happens when a developer sees that it is an
> attribute and thinks they can throw it on any element they choose? I see a
> whole fun Pandora's Box of unexpected behavior and bugs just lying in wait
> there...

Not sure what you mean here.


> > (Note that in the video above, the presenter says she wants to be able to
> > change the binding live. She calls it "absolutely crucial". :-) )
> 
> What she doesn't realize, is that it isn't really "absolutely" crucial, and
> even if it was, it doesn't mean we need to make this an attribute to do so.

I'm not saying it's crucial. I'm just saying that the video doesn't support the point that it was cited to support in the comments above.


> There are other options (that are arguably more intuitive) to accomplish
> custom element switching in a true custom tag world, here are a couple:
> 
> 1) We already have a document method perfect for this case:
> document.renameNode -
> http://www.w3.org/TR/DOM-Level-3-Core/core.html#Document3-renameNode

That doesn't achieve the Web Components requirements as far as I can tell (e.g. the node changes identity).


> 2) The developer can create the other type of custom element they want to
> switch to, and drop the child elements into it.

Not sure what you mean.


> I'd love to get some feedback to these possible solutions and questions,
> because *every single developer* I've talked to (and we've gotten a *lot* of
> feedback) have balked at the attribute route. I've heard it called: "unicorn
> magic", "opaque", "massive inference", "a View Source headache" etc - and if
> we don't have to go that route then I would strongly advise we avoid doing
> so.

I've proposed an alternative to an attribute.

I don't mind what the syntax is. My desire is just that Web Components layer on top of HTML semantics rather than being a sibling in the architectural cake.

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

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

I land in the same place that Daniel does, but I'm hoping there is a middle ground.

I understand the need to allow for common semantic information, but ultimately I believe the syntactical cruft of 'is' attribute or '<input/x-fancy>' is too much to bear.

A simple argument is that only a small fraction of custom elements will actually match any standard semantics. The majority will extend either 'div' or 'span'. A look at any major website will reveal how much <div class='xxx'> is in use today. This may be considered a flaw, but custom elements is not the right place to solve it.

It seems worth noting that there is confusion in the discussion about the nature of 'semantic'. I believe the argument is about machine-readable semantics. IOW, how can a user-agent do things like auto-filling forms if the form elements are custom? This is not the same as developer or human-readable semantics, which tend to argue the other way (i.e. a human will understand what x-slideshow means). 

As I mentioned I expect the majority of custom elements will not extend highly-semantic elements. Extending structural elements like <section> or <article> doesn't make a great deal of sense. Extending <input> or <select> per se is also impractical, although custom elements may commonly facade the APIs of those elements, which is a gray area.

Would it be possible to invert the problem? Instead of saying all custom elements must have a standard tag name with attached customization info, could we instead allow optional semantic markers? For example with an 'as' attribute, <x-fancy-input as='input'>? Maybe this is a big conceptual change, but this kind of solution at least would put the work where it's needed.

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

Hixie, 

True enough, but slideshow does have a meaning in the definition of the web component and that definition provides the exact sort of meaning you are looking for and in a declarative way very similar to what you/jonas are asking for.  

It may be worth considering two things separately here:  

a) In terms of things like robots, search engines, non-browser agents.. Are you/jonas really hard sold on the idea that this is a significant problem? This feels kind of similar to rdf or microdata (in this very limited sense) in that given the right pieces (which I think the draft provides) techs like search engines will start taking advantage of it once it is there even if they don't now...  and they are no worse off for it than they are now where they are also currently hopeless with the current myriad of approaches to these problems.  I think that this alone shouldn't be a deal-breaker as it could unnecessarily/unfairly limit the potential scope of solutions. 

b) In terms of older browsers/browsers which have important features disabled... Is this more or less of a problem in your mind than a)?  Again, I'm not sure that this makes it any worse than the current situation and with evergreen browsers and the fact that it isn't worth it for many apps/sites to have almost infinite fallbacks I'm not sure how important this appears to potential users, but I understand that that is not your perspective... To be honest, even leaving that aside - I can see some kind of argument for wanting some nice declarative manner for specifying fallback content, even mid-upgrade if your script determines that the browser is missing some important feature which would entail the same kind of consideration.  Is it possible that if we provided a solution for that, we might somehow be able to make it answer all of b) - and would that be enough for you to give it (even begrudgingly maybe) your blessing?   


Quick aside: I've said this in the past to (almost) all of you online or off, but I am not convinced that every custom component even has an element that it can 'extend' and gain anything worthwhile in terms of usability or anything like that.  In fact, since they can be composed, this gets harder and harder I think.  This argues - to me at least, that the approaches you and jonas are talking about are very limiting in terms of what would be possible, unless somehow we make an explicit "fallback" idea,  but I could be missing something important.  If so, help me understand?

IMHO the fallback element is more critical than the Web component. The component is a way to augment an element with more power, but it's just a variant of the fallback element.

To clarify, when I say "<input/foo>", I mean that's literally an <input> element, with the "foo" component bound to it. It's tag name is "input". It implements HTMLInputElement.

I'm fine with saying that the component can declare what element it's allowed to be bound to, so that "<div/foo>" just fails to bind (same as "<div>").

Just having the fallback defined in the component is insufficient because it's in the page that you need to know what kind of element it is, for fallback in legacy UAs or non-Web-component UAs, for validation, for authoring sanity, for semantic analysis, etc. Requiring that someone who's editing the page know how all the components are defined is poor, IMHO.

(In reply to comment #20)
> IMHO the fallback element is more critical than the Web component. The
> component is a way to augment an element with more power, but it's just a
> variant of the fallback element.

 > To clarify, when I say "<input/foo>", I mean that's literally an <input>
> element, with the "foo" component bound to it. It's tag name is "input". It
> implements HTMLInputElement. 
> I'm fine with saying that the component can declare what element it's
> allowed to be bound to, so that "<div/foo>" just fails to bind (same as
> "<div>").

I'm not saying this to throw it back and downplay what you are saying - I'm just curious:  How many things do you think really could do this vs how many things will likely use div as the fallback element and be not actually very useful in any way without a component?


> Just having the fallback defined in the component is insufficient because
> it's in the page that you need to know what kind of element it is, for
> fallback in legacy UAs or non-Web-component UAs, for validation, for
> authoring sanity, for semantic analysis, etc. Requiring that someone who's
> editing the page know how all the components are defined is poor, IMHO.

I think you misunderstood me there.. 

I am saying that all other concerns about what we mean by "is" or anything else aside: I can see some kind of argument that allowing the _page author_ to provide a fallback could be a nice feature even if you don't only consider old browsers.  For example: It might be the case that only during the process of upgrade you could find out that this browser doesn't support one thing that is just too critical not to have.  It might be nice if you could just throw an exception (or something) and prevent the upgrade, causing the fallback provided by the author.  I actually have something like this in one of my projects and it's handy because when something fails they are actually in the best position to say what should happen. I was suggesting that daniel and others think about it in those terms and see what they think about something more along the lines of embed/object or noscript kind of fallback which would address that case:  You aren't saying "This _is_ the embedded object" you are saying "This is what you get because the embedded object (for whatever reason) couldn't be embedded."  


My position here is that I expect that the majority of cases won't actually be as simple as "extend  input" or "extend select" in a very meaningful way (look at pretty much all of the examples shown at Google IO), but what Dimitri has provided with <element> and shadow and maybe even template gives a lot of ability to go way into it and determine what it really is with new tech. And that in the "unsupported" scenario - you probably don't _want_ to just fall back to the div you probably want to fall back to something else entirely...


I suppose there is an opportunity for the component to take fallback as input in some cases, but I think that isn't always true either.  

I'd like to hear what others think about the value of author defined "fallback" being: a) the same element b) something else - or c) irrelevant, it is just ignored.  Maybe this is the wrong place for such a discussion.

Hi! I'm Angelina, the presenter in the video that was referenced earlier in the thread. About the presentation in the video specifically, with a little bit of background:

I had read in the spec (or the explainer, can't remember which) that the is="" attribute is specifically not mutable; I cannot removeAttribute() and have my element restored to it's original prototype. I even tried this in my own experiments just for the hell of it and it failed as expected; I like to see what I can get away with in my spare time and I make a point to try and break or use things I'm not supposed to. When I was on the spot at the talk, I didn't remember this. I'm sorry that I didn't; I was very nervous like I am every time I speak in front of an audience. 

What is most interesting after the fact, I think, is how I chose to answer the developer's question in a way that I thought made the most sense. I made an educated guess (that turned out to be wrong) because most of the common attributes I work with are mutable. This may or may not be the case for other developers, but you can bet that at least some others will make the same mistake. I knew that technically the attribute affects the DOM tree as rendered, so I thought that changing it would change the tree as rendered appropriately when applied or unapplied. Other developers will make this assumption. It's the kind of mistake you do once though, then read the docs, and hopefully learn your lesson. It makes sense for some attributes to be immutable (script src, input type), and maybe there are good reasons for it in this case but to the average developer on the other side of these APIs, it is confusing.

In the video I talk about potential use cases for responsive web layouts. My idea when I incorrectly understood the is="" attribute was that I might be able to re-purpose a <nav> element on the fly if I detect a viewport size less than some size n. Width is less than 768? Bam, <nav> gets an attribute <nav is="mobile-menu"> and encapsulated somewhere in my mobile-menu is some code that takes the children of my nav element and turns it into a drop down. I understand basic re-rendering can be done by the application/removal of decorators, but actually I want to be able to apply/unapply behavior for my menu via script as well, and so I want to be able to use a full-fledged custom element. Knowing that I can't use the is="" attribute the way I had hoped, this makes me a sad panda. 

Someone said earlier that I didn't realize that the is="" attribute is not crucial to acquire the behavior that I'm looking for. I'm well aware that there is more than one way to skin a cat - er, yak. :) I did say 'absolutely crucial' in the video, but that's about being able to interact with my component in a certain way, and if the is="" attribute is not the way to do that, then the is attribute is not absolutely crucial and I care about it a lot less. 

I'd love to be able to declare my component, and then change an attribute on it like the data attribute in such a way that signals the component to be able to behave in the way I need. For example, when I detect a mobile user:

<x-adaptive-menu data-layout="mobile"></x-adaptive-menu>

That being said, now would be a good time to weigh in on this whole custom-tag-vs-attribute component decision:

One of the most confusing things when I started learning about shadow DOM and web components was the relationship between the host element with is="". I quickly learned that in the case that I have <element name="pants" extends="ul">, then for <article is="pants"> 'article' is not anything. It's a husk. It's a vessel. That's it. It (maybe) provides you with some children which you may or may not use. What I have is a pants element that has the prototype of an unordered list, not an article, and honestly that's really confusing when you look at the markup. You can expect other developers to assume that prototypal inheritance comes from the tag on which the is="" attribute and custom element are applied because that's what's in the markup. You effectively make the true prototype of the custom element obfuscated from the document source, but what's worse is that there's this lie, as it's been said, of it being something that it's not. That is sitting there waiting to confuse someone who doesn't know better yet. It is awfully unintuitive. 

On the concern about semantics when it comes to custom tags: at some point earlier a fear was expressed about developers using custom elements everywhere rather than semantic ones. Someone else pointed out that this is already a problem and that custom elements is not the place to solve it. I agree that this is not the place where we try and solve this issue. It's not your responsibility what tool a developer uses from the toolbox you've given them. 

If you tell a developer that they will build the best house with a hammer and nails but instead they just smash everything with a brick and put some paint on it, then I guess you might feel a bit bad for the person buying and using the house in the end but it's not on you. It's not your responsibility how the tool was used just because you made the tool and gave it to someone. You might think to try and create better tools, maybe tools that avoid certain pitfalls; this is good as we should always strive towards better tools. But keep in mind that even if you try and create those better tools, there's still no guarantee every developer will care to understand them and use them. There are many developers for whom webwork is a paycheck and the bare minimum of effort and understanding is all that is put forth. Those developers will continue to make everything a div forever with inline scripts and styles and whatever else they do that shuns the current web development paradigm no matter what we do. I don't know how to solve this problem, but I do know this isn't the place to do it.

If we're worried about semantics and we agree that role="" is not a panacea for those who DO care (I care!), then I think that this approach gives me the good feelings I'm looking for:

<x-fancy-input as='input'>

Let me specify the overall semantic value of my custom tag as an attribute if role="" is just a suggestion for screen reading software so that machines will parse my tag in a meaningful way for indexing the like. If I don't tag a custom component, then it's nothing special; maybe it's parsed with about as much semantic value as a div.

"Generally speaking, I wouldn't expect there to _be_ semantics that make sense inside a component. "

I would.

I understand that a screen reader should be able to traverse the tree as rendered for it's purposes; does/would a search engine do the same? If this is the case, then I definitely want to be able to have some semantic information in my component. For example, I might have a dynamic component in a magazine's web page that has a hierarchy of heading tags and content; maybe this component is updated with breaking stories and their summaries. Maybe I'm using a comment template component too, which has <em> tags used by the thread participants. I'd want all of this to be crawlable and parseable by the search engine. Just because I don't want my component's content to be mucked with by scripts in my parent scope doesn't mean I don't want search engines to be able to crawl it, and that means I'd probably want to be semantic in my components too. Perhaps there should be an attribute that tells the search engine whether or not to crawl/parse the content of the tree as rendered? If this can't happen, then I need to rethink how I'd use components some more.

I'm in the custom tags camp over the attribute camp. I used the is="" attribute in my demo because I happen to have a working polyfill supporting this, and also because I thought it was the direction that things were likely to go in, not because I like that approach personally.


Cheers,

- Angelina

(In reply to comment #0)
> It would appear a consensus of at least two implementing groups have agreed
> that it will be custom elements (tags, not attributes).

Who are the two groups?

(In reply to comment #7)
> 1) In terms of developer ergonomics, for both conceptual understanding and
> in practical use, it is much easier to deal with and "x-modal" tag vs a
> random tag with is="x-modal" applied.

Note that if is="" is used, there is no need for the x-. You could just say is="modal".

As far as conceptual understanding goes, developers already need to understand <input type="foo">.

> 4) Developers worth their salt will assume prototypical inheritance from the
> tag on which the is="" attribute is applied - this is a head-fake for
> developers. The extends linkage is created in the Custom Element definition,
> and if we use attributes, a developer will be left to wonder what mix of
> prototype they are being dealing with.

So why wouldn't we make the custom element inherit from the element designated by the tag name in terms of the APIs available?

> To mitigate semantic concerns of some who favor the is="" attribute, I would
> point developers at role="" for accessibility and semantic expression.

There is a crucial distinction: role="" is understood by the user agent while the user agent has no clue of the semantics of is="".

(In reply to comment #8)
> I'd be fine with not using an attribute if we have some other solution. My
> concern is that people will abandon the use of semantic HTML in favour of
> Web components, in much the same way that they used <font> or <div
> style="">s. This hurts accessibility, it hurts search engines, it hurts
> maintainability, and it hurts backwards-compatibility (graceful
> degradation). I would like to avoid this by requiring that authors use
> regular HTML elements that they then _augment_ using Web components.

I have this concern, too, at least for document-oriented Web content. It's unclear to me how much of a lost cause Gmail is. That is, if it is practical to try to redeem Gmail from the land of <span role=button class=foo> to <input type=button is=foo>.

> One way to do that is an is="" attribute on creation. Another is new syntax,
> e.g.:
> 
>    <select/map>
> 
> ...where "select" is the HTML semantic, and "map" is the component. (This
> would parse as <select map=""> in legacy UAs, but in new UAs we could make
> it something special that doesn't use attributes.)

I think we shouldn't go crazy with parser changes like that. (I'm generally worried that people get too eager to change the parser these days.)

To point out just one problem with your proposal, the component part could collide with an HTML built-in attribute in legacy browsers, and it would be in elegant to rely on authors to avoid such collisions. To avoid collisions, you could reintroduce the x- convention and write <select/x-map>. But once you go there, you might as well write <select x-map> to get the same result in legacy browsers. Once you get there, we might as well not make parser changes and are back to using attributes—but using attribute names instead of values. <select x-map> has at least slightly nicer to look at than <select is=map> and a lot nicer than <select is="x-map">.

Additionally, even though XML is not fashionable right now, I think we should avoid burning bridges with XML with gratuitous incompatibility on the DOM level—in this case non-NCName element names. Let's not forget that we all also implement XHTML and the rise of HTML5 has been made less scary to XML-minded people by promoting the use of an HTML parser at the start of an XML pipeline. And more important than making HTML less scary politically, leveraging XML machinery for non-browser HTML processing makes a lot of technical sense. (That's how Validator.nu works.) Let's not pulled the rug from under all that.

(In reply to comment #9)
> 1) What prevents the developer, or would even dissuade them, from using
> normal, semantic elements *inside* their components?

What's the expected accessibility exposure model for Web Components? Is the component's (shadow?) tree supposed to be exposed to accessibility APIs are not? (For XBL2, the answer was not, which might be affecting people's presuppositions when discussing this.)

> 3) If a developer uses role="", how is graceful degradation affected?

If degradation is in the attribute, it's easier to leave the degradation out.

If you have <nav x-supernav> or <nav is=supernav>, you have to have some elements name there, so you might as well use the right one.

If you have <x-supernav role=navigation>, it's much easier to forget or optimize out the role part.

> 4) Why are you assuming the browser will act on <nav is="x-supernav"> as if
> it hails from the nav element's prototype? The generated custom element
> prototype does not inherit the prototype of the element that is="" is
> applied to

Why not?

> 1) We already have a document method perfect for this case:
> document.renameNode -
> http://www.w3.org/TR/DOM-Level-3-Core/core.html#Document3-renameNode

As Anne pointed out, we don't really have document.renameNode().

I'm going to attempt to break out of this Ground Hog's Day-esque loop of explaining the same things over and over...I digress - here goes:

> > 1) In terms of developer ergonomics, for both conceptual understanding and
> > in practical use, it is much easier to deal with and "x-modal" tag vs a
> > random tag with is="x-modal" applied.
> 
> Note that if is="" is used, there is no need for the x-. You could just say
> is="modal".
> 
> As far as conceptual understanding goes, developers already need to
> understand <input type="foo">.


I can see where someone could think this is a good example, but it is entirely different. We're not just talking about a mutable attribute that has a scoped affect on a specific element proto, we're talking about an attribute that actually defines the proto object identity of the tag itself.


> > 4) Developers worth their salt will assume prototypical inheritance from the
> > tag on which the is="" attribute is applied - this is a head-fake for
> > developers. The extends linkage is created in the Custom Element definition,
> > and if we use attributes, a developer will be left to wonder what mix of
> > prototype they are being dealing with.
> 
> So why wouldn't we make the custom element inherit from the element
> designated by the tag name in terms of the APIs available?


Are you forgetting these are actually extended protos? Let's say I'm coding a custom element, "x-importer", to inherit from an existing native element, HTMLScriptElement, and my custom element code materially relies upon the inherited proto methods/getters/setters. Why can't I just slap is="x-importer" on any ol' element on the page? Well shucks, do I need to go further here folks?

Long story short - no, nope, nada, noski, no-siree-bob, not ever - should we allow a pig pen of false interoperability that lies to developers by virtue of some transient, immutable attribute that may or may not produce an extended proto that works for the internal custom element's code definition.

"Yo dawg, I heard you liked inexplicable failures in your custom elements, so I let the web play pin the proto-tail on the element-donkey with attributes." - Xzibit


> > To mitigate semantic concerns of some who favor the is="" attribute, I would
> > point developers at role="" for accessibility and semantic expression.
> 
> There is a crucial distinction: role="" is understood by the user agent
> while the user agent has no clue of the semantics of is="".


You're basically saying that is _is_ meaningless to the user agent currently...err...I agree? Obviously if a UA can be coded to understand an is="" linkage, they can be coded to look at what a tag extends, defaulting to HTMLSpanElement - as the spec describes.

Let's be clear: If the true desire of some on this thread is to provide devs a way to specify *optional*, *additional* semantics that extends="", role="", and semantic elements inside a custom element can't, then sure, lets include an optional attribute like is="" as="" dat="" shiz="" - but there's no need to ram the whole API into a terrible, sure-to-be-fail-prone attribute interface to assuage the desire for nth degree semantics that may or many not be an issue with a subset of components.

Moral of the story: make it optional, make it passive - if not you're creating 10 real-deal, additional problems that will #FacePalm devs left and right, all for the cause of something that could be an issue for a subset of use-cases.


> (In reply to comment #8)
> > I'd be fine with not using an attribute if we have some other solution. My
> > concern is that people will abandon the use of semantic HTML in favour of
> > Web components, in much the same way that they used <font> or <div
> > style="">s. This hurts accessibility, it hurts search engines, it hurts
> > maintainability, and it hurts backwards-compatibility (graceful
> > degradation). I would like to avoid this by requiring that authors use
> > regular HTML elements that they then _augment_ using Web components.
> 
> I have this concern, too, at least for document-oriented Web content. It's
> unclear to me how much of a lost cause Gmail is. That is, if it is practical
> to try to redeem Gmail from the land of <span role=button class=foo> to
> <input type=button is=foo>.


Oooweee, good example! --> <input type=button is=foo />

Riddle me this: Under an is="" world, what happens when a developer jumps into source, sees this cool button, that materially relies on extending <input>, and logically, obviously, tries to do this: <button is="foo">. I can hear the subtle explosions inside the <element name="foo"> definition script now...BOOM!


> (In reply to comment #9)
> > 1) What prevents the developer, or would even dissuade them, from using
> > normal, semantic elements *inside* their components?
> 
> What's the expected accessibility exposure model for Web Components? Is the
> component's (shadow?) tree supposed to be exposed to accessibility APIs are
> not? (For XBL2, the answer was not, which might be affecting people's
> presuppositions when discussing this.)


The browser has knowledge and control of all the objects, whether in shadow roots or not, I can't state with 100% confidence that a browser can use elements in the Shadow DOM just the same, but I can't see any reason why not. Dimitri?


> > 4) Why are you assuming the browser will act on <nav is="x-supernav"> as if
> > it hails from the nav element's prototype? The generated custom element
> > prototype does not inherit the prototype of the element that is="" is
> > applied to
> 
> Why not?


Hopefully we don't need to rehash this ever again...


> > 1) We already have a document method perfect for this case:
> > document.renameNode -
> > http://www.w3.org/TR/DOM-Level-3-Core/core.html#Document3-renameNode
> 
> As Anne pointed out, we don't really have document.renameNode().

So implement it! We're talking about augmenting the platform to account for an attribute, is there some moratorium on adding helpful methods?

Please excuse any frustration, all of these issues have already been explained several times in this thread - it becomes an Ad nauseam task to continually restate them.

Hixie:

With regard to your (an Jonas, etc) latest proposal, did you happen to try it out?

I just did, and as it turns out, all existing browsers fail to parse a tag name with slashes in the string when used against createElement, querySelector, and I suspect other such APIs. This is a non-starter - it would eliminate any possibility of polyfills (which we already have: https://github.com/mozilla/web-components/blob/master/document.register.js) - and torpedo our component building initiative at Mozilla.

In my mind, any proposal that blocks us from providing a polyfill for current browsers is out of the question.

After someone piped up that the proposal to use <foo/bar>, was really intended to mean foo[bar] (how developers *actually* write and refer to attributes on the web), I thought I'd correct my own comment...then highlight that all the problems from is="" would still apply, including a few additional issues - here's rundown:

el.removeAttribute('x-foo') --> This does nothing - a lie via years of developer inference on how the platform generally works

document.querySelector('x/x-foo') --> This throws an error - marking up elements as custom elements in source becomes a one-off fudge, all other interaction would require 'x[x-foo]'

Polyfills become ridiculous:

You would need to run logic on all *nodes detected* to inspect *all of their attributes* for any that started with 'x-' to know to upgrade them - a performance-destroying imposition

You'd need to wrap a litany of DOM methods and objects to block-and-throw when the developer makes the *perfectly reasonable assumption* that they can remove or add custom element boolean attributes - this includes removeAttribute, NamedNodeMap methods, and a host of other interfaces.

In the end, it is all a tedious, largely irrelevant, exercise considering the majority of components won't have a native tag they are semantically akin to. This will manifest itself as: <x/x-foo></x>

The point of <select/map> is that it parses as <select> in legacy UAs, and in Web-component-supporting UAs it is treated as <select> and immediately bound to the "map" component. This requires parser changes, but parser changes significantly less drastic than anything we need for web components already with <template>. For element creation, you'd create a Map directly with "new Map()". For selectors, you'd probably use a new pseudo-class a la ":component(map)" or some such.

(In reply to comment #27)
> The point of <select/map> is that it parses as <select> in legacy UAs, and
> in Web-component-supporting UAs it is treated as <select> and immediately
> bound to the "map" component.

So localName would say "select"?

What syntax would you use in XHTML?

How would you represent the binding to "map" in DOM Core Level 2-only server-side munging or XDM or Infoset?

It _seems_ as if Hixie and Jonas suggest that if we changed <x-foo where the base of foo (imagine it is select) is defined elsewhere to <select/foo (where select has to match the related extends value essentially) then we are pretty close otherwise because for some reason the parser in browsers will currently parse that as <select foo and therefore provide cover for most of the concerns that Ian had and still kinda "looks" like a tag - the major diff being "/" instead of "-".

If that is not the case, please let me know - but assuming that it is, here are some additional thoughts/observations/concerns/questions... Please let me know where I am on/off in your opinions...




* Most of the examples we've been discussing are kind of incomplete.  If we are trying to take advantage of the unchanged parser, we'd really have to include the "x-" anyway, right? else we are adding an attribute in the main namespace and that could go very badly.  Thus, we're not really talking about <select/map>, we are talking about <select/x-map>.  Not that that matters in a substantial way I just want to be clear.

* I'd also like to note that we are not illustrating the close tag... Since we are taking advantage of the parser quirk, this means that <select/x-map>...</select/x-map>  parses (we tried it) - but so is <select/x-map>...</select>.  So which would those proposing advocate is taught?  

    * The former is actually really hard for anything but the html parser to parse (including humans) and given Hixie's concerns about microparsers and things in search engines, etc. I think he might like to take note that all of the tools we (Daniel and I) played with in considering how to make this work had problems:  Syntax highlighters screwed up, auto-completion/correction doing whacky things, etc.

    * The later isn't _as bad_ but still problematic in numerous ways.  Visually it is unlike anything else in html today - both in the sense that authors (and many tools) see "/" in a tag and think "close" and the start and end "tag" don't appear to match.  

* In order to do anything remotely useful with fallback content, in a legacy browser at least, you would have to understand what is going on under the covers... you'd have to get that qsa or css would require "select[x-foo]", for example.

---- all of the above makes me feel like hixie/jonas et-all are just confusing things by adding a slash at all since "<select x-map" is identical, fully equivalent, vanilla html that doesn't suffer from the problems above.  It is, however, less good in numerous ways than "<select is=map" or "<select is=x-map" because that always has a known attribute which has a ton of advantages in terms of simplicity and what we can do with it.


Are we all on the same page thus far?


If so, the advantages (feel free to add/comment):

  - If done perfectly, with simple cases it will yield something expectable/predictable and maybe even semi-functional in legacy UA (aside:  that might not be what the author actually wants - I know I sometimes wouldn't).


And the disadvantages:

  - Many (maybe most) of them will be built on meaningless semantic elements like div or span (again, I will point you to google io's examples where complex inputs are build on divs, not other inputs and ask that someone please explain how to do those otherwise and why they would expect page authors to be smarter than the presenters).  As Daniel mentioned: at this point they may simply opt to use "x" since an unknown element is technically about as good.

  - Maybe most importantly to me:  This doesn't help the problem for legacy UAs in any way that Web Components can and will be nested/composed.  Composition is one of the most attractive features of Web Components to many authors who have long argued that it has been missing for a long time and you can bet it will be used.

  - This adds the complexity of having to know significantly more information in order to use a component and considerably more verbose input.  If the types don't agree in page and in definition, upgrade will fail - this also argues to me at least that authors will have a strong desire to subvert this limitation by going with a standard "x" or something.



Is there any reason that someone could not achieve fallback in hixie's map example by simply developing their component so that the input was allowed to have the outer element?  In other words - if you wanted fallback - you could just:

<x-map>
   <select name="country">
       <option>FR</option>
       <option>UK</option>
       <option>US</option>
   </select>
</x-map>

Legacy browsers will show the x-map and presumably new system would upgrade on parse too... If so - what's the problem that the <select/map solves?

> Is there any reason that someone could not achieve fallback in hixie's map
> example by simply developing their component so that the input was allowed
> to have the outer element?  In other words - if you wanted fallback - you
> could just:
> 
> <x-map>
>    <select name="country">
>        <option>FR</option>
>        <option>UK</option>
>        <option>US</option>
>    </select>
> </x-map>
> 
> Legacy browsers will show the x-map and presumably new system would upgrade
> on parse too... If so - what's the problem that the <select/map solves?

RIGHT ON!

This is a far better answer to this issue. In cases were the component's actual optimal content is not inherently accessible, you could provide developers with a 100% optional feature to streamline things just a bit more:

<x-map>
  <select fallback name="country">
      <option>FR</option>
      <option>UK</option>
      <option>US</option>
  </select>
</x-map>

If a developer used a fallback marker, the browser could skip tokenization of those elements, which also conveniently removes the need for component authors to bake code into their component definitions to deal with fallback content that is unnecessary in their optimal render cases.

This is THE best solution that has been presented thus far, all the attribute avenues have ***huge*** cons that are far more problematic than the issues they solve (for the fractional-percentage cases they target).

This completely fails to address the concern I have, which is that the component element should be the fallback element and that if you can't not give the fallback (the binding just won't bind if there isn't the right fallback given).

hsivonen: I think it's fine for this not to work in XML, or require XML changes, or use an attribute like xml:component="" in XML. It's not going to be used in XML much anyway in practice. I've already had browser vendors ask me how they can just drop XML support; I don't think we can, at least not currently, but that's the direction things are going in, not the opposite.

(In reply to comment #31)
> This completely fails to address the concern I have, which is that the
> component element should be the fallback element and that if you can't not
> give the fallback ***(the binding just won't bind if there isn't the right
> fallback given)***

The binding ergonomics that you infer here are a massive head-fake for source viewers, consumers of third-party components, and a whole host of other potential users/viewers. The idea that the browser "just won't bind" is an off-handed, let-them-eat-cake dismissal of all the monotonous, confusing, fruitless, unintuitive annoyances it hoists upon developers.

Force-feeding one possible accessibility implementation in the face of other (truly optional) options that also serve that use-case (see Brian's comment 29 above) at the expense of a superior product is trading a handknife for a footgun. There are real, material issues introduced by using either is="" or tag-escaped-attribute-fakery that person after person has called out and opposed.

Let's be very clear about this: we are holding hostage a far more ergonomic API that is relatively easy to polyfill, doesn't lie to developers or require deep understanding of component mechanics/definitions to use, and is preferred ~10 to 1 by those on this thread (and other channels) who have weighed the options.

We should use the existing method Brian suggested, that the platform currently supports, for declaring fallback content. It doesn't ram-rod a single, subset concern on the rest of the system - that's a *benefit* in my book.

(In reply to comment #27)
> The point of <select/map> is that it parses as <select> in legacy UAs, and
> in Web-component-supporting UAs it is treated as <select> and immediately
> bound to the "map" component. This requires parser changes, but parser
> changes significantly less drastic than anything we need for web components
> already with <template>. For element creation, you'd create a Map directly
> with "new Map()". For selectors, you'd probably use a new pseudo-class a la
> ":component(map)" or some such.


So, to make sure I am understanding you: you're saying div in <div/map> isn't really like an attribute, in that it is parsed out and not allowed to be dynamically added using setAttribute? If this is true, and you're saying this slash-escaped hack for existing UAs is going to be essentially formalized as an interface, how do I create custom elements imperatively using document.createElement? I assume you're going to submit one of these two responses:

1) We must make YAODAC (Yet Another One-off DOM API Change), this time to document.createElement, to accept document.createElement('div/map');

or

2) We introduce YAWCAC (Yet Another Web Components API Caveat) by leaving createElement as is, and telling devs "for native elements, you can use createElement, but for custom elements you need to use new Map(). 

Hixie, in the case that map can be applied to several kinds of native elements, what's your plan for how the developer specifies which one to use when invoking the imperative constructor new Map()? Let me guess, YAWCAC?

(In reply to comment #31)
> hsivonen: I think it's fine for this not to work in XML, or require XML
> changes, or use an attribute like xml:component="" in XML. It's not going to
> be used in XML much anyway in practice. I've already had browser vendors ask
> me how they can just drop XML support; I don't think we can, at least not
> currently, but that's the direction things are going in, not the opposite.

I took this part to the mailing list:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-January/038632.html

> So, to make sure I am understanding you: you're saying div in <div/map>

This should have read: "map in <div/map>"

Here's an alternative proposal that dglazkov and I came up with over lunch.

Provide two alternatives for authors to pick from:

1. Extending an existing element, using the declaration syntax:
     <element extends="ul" name="mylib-speciallist">
   ...and the use syntax:
     <ul is="mylib-speciallist">...</ul>
   Changing the is="" attribute doesn't do anything (and we provide an API to
   expose the element's original 'is' value somehow). This is suboptimal (as
   noted earlier) but it avoids even less pleasant changes to the HTML parser
   and differences between HTML and XML syntax.

2. Creating new elements that inherit straight from CustomElement (which
   inherits from Element, like HTMLElement, and has things like .style,
   focus(), and tabindex=""), using the declaration syntax:
     <element name="mylib-myelement">
   ...and the use syntax:
     <mylib-myelement>

(Both types would also be able to extend other components; whether it's the kind of component that extends an existing element type or creates a new element depends on the which is at the root of the hierarchy.)

This is on top of the existing decorator alternative also available:

3. Decorators. These can't provide a new API. Declaration:
     <decorator name="mylib-mybutton">
   Use:
     /*CSS*/ input[type=button] { binding: url(mylib.html#mylib-mybutton); }
     <input type=button>

We also discussed a third alternative for authors to use, which we'd not provide in v1 but might provide in v2:

4. Providing a new type="" value for <input> (and maybe <button>, we didn't 
   discuss that). Declaration (straw man, we didn't discuss syntax):
     <inputtype name="mylib-map">
   Use:
     <input type="mylib-map">

I think this manages to hit the main use cases:

A. Just changing the shadow tree of existing elements (e.g. making prettier buttons) is handled by decorators, #3.

B. Extending semantics of existing elements, providing more API surface and with a mostly presentational shadow DOM (e.g. making a <select> of country names be rendered as a graphical map), is provided by #1.

C. Creating precomposed groups of elements, maybe providing some API surface, with a shadow DOM that is mostly semantic elements (e.g. something like <input type=file> or a group of datetime controls that exposes start and end times), is provided by #2.

D. New controls that fit the <input> model but don't map to existing semantics (e.g. a type=bugzilla-bugid or something), are eventually provided by #4.

E. Completely new semantics, e.g. a platform game's graphics area and key handling (essentially, mini applications) are handled by #2.

F. Creating new widgets in SVG, which render as SVG fragments and react to UI events to change the graphics, and expose an API (e.g. a clickable "switch" button in a train layout UI), are handled by #2 with a minor tweak to the SVG processing algorithm that says that if an element's parent is an SVG node (or another component to which this applies), its shadow tree is processed as if the element was a <g> with that shadow tree as descendants.

It avoids most of the key pitfalls that were worrying people with earlier suggestions. The main ones it doesn't avoid are that the #1 syntax above might still mislead authors into thinking they can change the is="" attribute, but that is somewhat mitigated by providing a syntax without is="" as well (#2). The syntax is as terse as possible for #2, and relatively terse for #1 but clearly not ultimately terse. Where there is a real standard semantic, we still expose it, though we don't force it where that doesn't make sense. By preventing authors from extending elements when they don't expose the semantic in the original markup, we discourage people from using #2 when #1 is easier. Unfortunately we don't prevent misuse of #2, but discouraging it is probably as good as we can do in practice (people can always extend <div>...).

To avoid stepping on the HTML vocabulary, we use a hyphen ("-") in the element name as an indicator that the element is a custom element, and HTML reserves all element names without a hyphen for future use. For consistency, we'd also require a hyphen in the name of is="" values. We'd document the syntax as being "libraryname-componentname", which encourages avoiding cross-library clashes.

(In reply to comment #34)
> (In reply to comment #31)
> > hsivonen: I think it's fine for this not to work in XML, or require XML
> > changes, or use an attribute like xml:component="" in XML. It's not going to
> > be used in XML much anyway in practice. I've already had browser vendors ask
> > me how they can just drop XML support; I don't think we can, at least not
> > currently, but that's the direction things are going in, not the opposite.
> 
> I took this part to the mailing list:
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-January/038632.html

(In reply to comment #36)
> Here's an alternative proposal that dglazkov and I came up with over lunch.
> 
> Provide two alternatives for authors to pick from:
> 
> 1. Extending an existing element, using the declaration syntax:
>      <element extends="ul" name="mylib-speciallist">
>    ...and the use syntax:
>      <ul is="mylib-speciallist">...</ul>
>    Changing the is="" attribute doesn't do anything (and we provide an API to
>    expose the element's original 'is' value somehow). This is suboptimal (as
>    noted earlier) but it avoids even less pleasant changes to the HTML parser
>    and differences between HTML and XML syntax.
> 
> 2. Creating new elements that inherit straight from CustomElement (which
>    inherits from Element, like HTMLElement, and has things like .style,
>    focus(), and tabindex=""), using the declaration syntax:
>      <element name="mylib-myelement">
>    ...and the use syntax:
>      <mylib-myelement>
> 
> (Both types would also be able to extend other components; whether it's the
> kind of component that extends an existing element type or creates a new
> element depends on the which is at the root of the hierarchy.)
> 
> This is on top of the existing decorator alternative also available:
> 
> 3. Decorators. These can't provide a new API. Declaration:
>      <decorator name="mylib-mybutton">
>    Use:
>      /*CSS*/ input[type=button] { binding: url(mylib.html#mylib-mybutton); }
>      <input type=button>
> 
> We also discussed a third alternative for authors to use, which we'd not
> provide in v1 but might provide in v2:
> 
> 4. Providing a new type="" value for <input> (and maybe <button>, we didn't 
>    discuss that). Declaration (straw man, we didn't discuss syntax):
>      <inputtype name="mylib-map">
>    Use:
>      <input type="mylib-map">
> 
> I think this manages to hit the main use cases:
> 
> A. Just changing the shadow tree of existing elements (e.g. making prettier
> buttons) is handled by decorators, #3.
> 
> B. Extending semantics of existing elements, providing more API surface and
> with a mostly presentational shadow DOM (e.g. making a <select> of country
> names be rendered as a graphical map), is provided by #1.
> 
> C. Creating precomposed groups of elements, maybe providing some API
> surface, with a shadow DOM that is mostly semantic elements (e.g. something
> like <input type=file> or a group of datetime controls that exposes start
> and end times), is provided by #2.
> 
> D. New controls that fit the <input> model but don't map to existing
> semantics (e.g. a type=bugzilla-bugid or something), are eventually provided
> by #4.
> 
> E. Completely new semantics, e.g. a platform game's graphics area and key
> handling (essentially, mini applications) are handled by #2.
> 
> F. Creating new widgets in SVG, which render as SVG fragments and react to
> UI events to change the graphics, and expose an API (e.g. a clickable
> "switch" button in a train layout UI), are handled by #2 with a minor tweak
> to the SVG processing algorithm that says that if an element's parent is an
> SVG node (or another component to which this applies), its shadow tree is
> processed as if the element was a <g> with that shadow tree as descendants.
> 
> It avoids most of the key pitfalls that were worrying people with earlier
> suggestions. The main ones it doesn't avoid are that the #1 syntax above
> might still mislead authors into thinking they can change the is=""
> attribute, but that is somewhat mitigated by providing a syntax without
> is="" as well (#2). The syntax is as terse as possible for #2, and
> relatively terse for #1 but clearly not ultimately terse. Where there is a
> real standard semantic, we still expose it, though we don't force it where
> that doesn't make sense. By preventing authors from extending elements when
> they don't expose the semantic in the original markup, we discourage people
> from using #2 when #1 is easier. Unfortunately we don't prevent misuse of
> #2, but discouraging it is probably as good as we can do in practice (people
> can always extend <div>...).
> 
> To avoid stepping on the HTML vocabulary, we use a hyphen ("-") in the
> element name as an indicator that the element is a custom element, and HTML
> reserves all element names without a hyphen for future use. For consistency,
> we'd also require a hyphen in the name of is="" values. We'd document the
> syntax as being "libraryname-componentname", which encourages avoiding
> cross-library clashes.


Also no existing tools should be hurt by this approach... I am gonna have to read this again, but so far I think I am good with it.  Someone show me if I've missed something.

- What this solves -

* Provides for subset of accessibility issues that fit specially crafted usage assumptions with short-term relevance - which can also be solved via Brian Kardell's proposal in Comment 29, of optional, source-included fallback content.


- Where it falls down -

* Forces two interfaces on developers that fork due to a hard prohibition of a single feature, that may or may not even apply.

* Legacy UAs do not allow access to Shadow DOM and other things that are the probable reason developers would even want to extend native elements, thus the likelihood that <input type="text" is="x-super-input" /> will show up in legacy UAs is slim - it's much more likely you will see this: <x-supertext> { DEFAULT CONTENT INCLUDES AN <INPUT> } </x-supertext>

* If linked documents are parsed, this whole issue goes away in the medium-to-long term as Web Component implementation proliferates, leaving us with a fractured, sub-optimal API, and years and years of fist-shaking over what was decided back in the ol' days (36 months ago)

* Polyfills become much harder

* Devs are required to always think in two modes, extend vs non-extend, which has significant thought and code-writing overhead (hmm...do I need to querySelector for select[is="x-foo"], or just x-foo?)

* Raises the fundamental barrier to entry for coders new to the web platform and its interface

* Turns source viewing into a fun game of "Where's Web Component Waldo?"

* Doesn't for one second prevent the far better solution of optionally including fallback content within the tag itself - this will be used a lot when developers take stock of their options and square them with code-reality.

* Much of the concern is organically avoided by developers who will self-select use of decorators for cases where is="" would have them do <select is="x-foo">

* Decorators can, at some point, include transient method/accessor hooks while active on an element - another option that would render is="" obsolete.

---

I feel this hybrid proposal is unnecessary, based on faulty assumptions of the rate of native-element-inheriting tag use in legacy UAs, and ill-concieved, based on the steady feedback over the past few months from developers both inside and outside Mozilla. In my opinion, and the opinion of developers who have/will use this feature, this is the wrong course of action.

A petition for compromise based on a reality-driven assessment of likely rates of developer usage/use-cases:

Remove the soon-to-be-useless prohibition on extending native elements from #2, the true custom tag syntax.

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.

(In reply to comment #36)
> Here's an alternative proposal that dglazkov and I came up with over lunch.
> 
> Provide two alternatives for authors to pick from:
> 
> 1. Extending an existing element, using the declaration syntax:
>      <element extends="ul" name="mylib-speciallist">
>    ...and the use syntax:
>      <ul is="mylib-speciallist">...</ul>
>    Changing the is="" attribute doesn't do anything (and we provide an API to
>    expose the element's original 'is' value somehow). This is suboptimal (as
>    noted earlier) but it avoids even less pleasant changes to the HTML parser
>    and differences between HTML and XML syntax.
> 
> 2. Creating new elements that inherit straight from CustomElement (which
>    inherits from Element, like HTMLElement, and has things like .style,
>    focus(), and tabindex=""), using the declaration syntax:
>      <element name="mylib-myelement">
>    ...and the use syntax:
>      <mylib-myelement>
> 
> (Both types would also be able to extend other components; whether it's the
> kind of component that extends an existing element type or creates a new
> element depends on the which is at the root of the hierarchy.)
> 
> This is on top of the existing decorator alternative also available:
> 
> 3. Decorators. These can't provide a new API. Declaration:
>      <decorator name="mylib-mybutton">
>    Use:
>      /*CSS*/ input[type=button] { binding: url(mylib.html#mylib-mybutton); }
>      <input type=button>
> 
> We also discussed a third alternative for authors to use, which we'd not
> provide in v1 but might provide in v2:
> 
> 4. Providing a new type="" value for <input> (and maybe <button>, we didn't 
>    discuss that). Declaration (straw man, we didn't discuss syntax):
>      <inputtype name="mylib-map">
>    Use:
>      <input type="mylib-map">
> 
> I think this manages to hit the main use cases:
> 
> A. Just changing the shadow tree of existing elements (e.g. making prettier
> buttons) is handled by decorators, #3.
> 
> B. Extending semantics of existing elements, providing more API surface and
> with a mostly presentational shadow DOM (e.g. making a <select> of country
> names be rendered as a graphical map), is provided by #1.
> 
> C. Creating precomposed groups of elements, maybe providing some API
> surface, with a shadow DOM that is mostly semantic elements (e.g. something
> like <input type=file> or a group of datetime controls that exposes start
> and end times), is provided by #2.
> 
> D. New controls that fit the <input> model but don't map to existing
> semantics (e.g. a type=bugzilla-bugid or something), are eventually provided
> by #4.
> 
> E. Completely new semantics, e.g. a platform game's graphics area and key
> handling (essentially, mini applications) are handled by #2.
> 
> F. Creating new widgets in SVG, which render as SVG fragments and react to
> UI events to change the graphics, and expose an API (e.g. a clickable
> "switch" button in a train layout UI), are handled by #2 with a minor tweak
> to the SVG processing algorithm that says that if an element's parent is an
> SVG node (or another component to which this applies), its shadow tree is
> processed as if the element was a <g> with that shadow tree as descendants.
> 
> It avoids most of the key pitfalls that were worrying people with earlier
> suggestions. The main ones it doesn't avoid are that the #1 syntax above
> might still mislead authors into thinking they can change the is=""
> attribute, but that is somewhat mitigated by providing a syntax without
> is="" as well (#2). The syntax is as terse as possible for #2, and
> relatively terse for #1 but clearly not ultimately terse. Where there is a
> real standard semantic, we still expose it, though we don't force it where
> that doesn't make sense. By preventing authors from extending elements when
> they don't expose the semantic in the original markup, we discourage people
> from using #2 when #1 is easier. Unfortunately we don't prevent misuse of
> #2, but discouraging it is probably as good as we can do in practice (people
> can always extend <div>...).
> 
> To avoid stepping on the HTML vocabulary, we use a hyphen ("-") in the
> element name as an indicator that the element is a custom element, and HTML
> reserves all element names without a hyphen for future use. For consistency,
> we'd also require a hyphen in the name of is="" values. We'd document the
> syntax as being "libraryname-componentname", which encourages avoiding
> cross-library clashes.


Clarrification question... extends in element... is it really prohibited on custom elements?  And also, could it potentially extend something which, in turn, extends custom element - or is it really just vanilla "custom element"?

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

(In reply to comment #40)
> (In reply to comment #36)
> > Here's an alternative proposal that dglazkov and I came up with over lunch.
> > 
> > Provide two alternatives for authors to pick from:
> > 
> > 1. Extending an existing element, using the declaration syntax:
> >      <element extends="ul" name="mylib-speciallist">
> >    ...and the use syntax:
> >      <ul is="mylib-speciallist">...</ul>
> >    Changing the is="" attribute doesn't do anything (and we provide an API to
> >    expose the element's original 'is' value somehow). This is suboptimal (as
> >    noted earlier) but it avoids even less pleasant changes to the HTML parser
> >    and differences between HTML and XML syntax.
> > 
> > 2. Creating new elements that inherit straight from CustomElement (which
> >    inherits from Element, like HTMLElement, and has things like .style,
> >    focus(), and tabindex=""), using the declaration syntax:
> >      <element name="mylib-myelement">
> >    ...and the use syntax:
> >      <mylib-myelement>
> > 
> > (Both types would also be able to extend other components; whether it's the
> > kind of component that extends an existing element type or creates a new
> > element depends on the which is at the root of the hierarchy.)
> > 

Since I cannot appear to edit my last question, I want to clarrify:  the element defined in #1 above
With 

    <element extends="ul" name="mylib-speciallist">

Is the proposal that we actually prohibit or merely discourage people from just using:

    <mylib-speciallist>

Clearly you would loose a band of information in some cases early on as hixie explained, but ... what happens if you do this?  Does it throw or does it work or what?

I feel like "one basic syntax covering all use cases" should be a requirement.

We are already in a position where the problem is over-constrained. trying to work around that by having multiple, partial, solutions, seems likely to produce something that had very poor developer ergonomics (the classic "design by committee" mistake).

I think the correct next step is to work out which of the requirements is least harmful to bend a little so that we can find the optimal solution even if it doesn't strictly fulfill all the conditions.

I’ve been poring over replies on bug and various private mails and chats, trying to pieces together the landscape. As far as I can see it, there are two major opposing camps (and as it usually happens, many stragglers and undecideds):

1) The "liberal" camp, whose dwellers see custom tags as HTML’s salvation. They cite top sites and their wholly imperative architecture as the evidence of “the battle of HTML” already have been lost and the need for flexibility/carrot to entice the authors back to declarative land. The emerged, reborn markup will not be “HTML as we know it”, but it will be closer to HTML than imperative code.

2) The "conservative" camp, where the custom tags are seen as a looming threat to the existing HTML semantics. They cite the general success of existing HTML semantics on the Web (Google search as one example) and the danger of custom tags to incentivise the authors to invent their own semantics and obscuring HTML semantics in the process.

For conservatives, the worst-case scenario includes a whole new breed of markup where documents no longer contain any recognizable HTML semantics, and as such does not seem much better than the imperative approach that top sites use now. 

To prevent this, the conservatives insist that custom elements must come with guides or hurdles that direct the authors to keep HTML semantics exposed as long as reasonably possible.

For liberals, the worst-case scenario is that the hurdles are too tall and the majority of authors simply rejects custom elements, continuing the same practices.

Essentially, the liberals ask to "Say what you mean" with custom tags, and conservatives worry that it will result in "I heard you, but I have no clue what it means".

One can suppose that the discourse boils down to the height of hurdles erected in order to guide the authors.

In the latest proposal (https://www.w3.org/Bugs/Public/show_bug.cgi?id=18669#c36), the hurdles are:

1) To encourage using existing HTML semantics, the author has to use “is” syntax to extend existing HTML elements

2) To discourage replacing HTML semantics with whole new vocabularies, the author may only inherit from CustomElement (which is Element with some useful bits of HTMLElement) when making new tags.

Summarizing preliminary developer ergonomics analysis of the proposal in https://www.w3.org/Bugs/Public/show_bug.cgi?id=18669#c36:

* Two distinct syntaxes for custom elements, while isn’t anything new for HTML, is a usability problem. Opinions on the severity of this problem vary.

* The proposal has a strong “either-or” force of slotting libraries into either only providing things that extend existing HTML elements or only providing a set of custom tags.

* The “is” syntax is awkward (a thing that’s like a tag name but is an attribute that you can’t change) and more verbose than the custom tag.

(In reply to comment #45)
> Summarizing preliminary developer ergonomics analysis of the proposal in
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18669#c36:
> 
> * Two distinct syntaxes for custom elements, while isn’t anything new for
> HTML, is a usability problem. Opinions on the severity of this problem vary.
> 
> * The proposal has a strong “either-or” force of slotting libraries into
> either only providing things that extend existing HTML elements or only
> providing a set of custom tags.
> 
> * The “is” syntax is awkward (a thing that’s like a tag name but is an
> attribute that you can’t change) and more verbose than the custom tag.

"Opinions on the severity of this problem vary" - this is a crucial distinction, because depending on our assumption set and *valid* use-cases, we could be forking the API for a problem that may never materialize or would fade away organically at a fairly rapid pace.

The existence of a use-case is merely an interesting starting point for analysis and exploration - whether or not it affects decisions or outcomes should be based on the expected rate of occurrence vs the severity of effect. Do you pass a law mandating all pedestrians must wear helmets simply because tripping is a *possible* use-case?

(In reply to comment #44)
> 1) The "liberal" camp, whose dwellers see custom tags as HTML’s salvation.
> They cite top sites and their wholly imperative architecture as the evidence
> of “the battle of HTML” already have been lost and the need for
> flexibility/carrot to entice the authors back to declarative land. The
> emerged, reborn markup will not be “HTML as we know it”, but it will be
> closer to HTML than imperative code.

If the goal is to have declarative code but to give up on the HTML semantics, then we should do that, we shouldn't try to cling to vestiges of HTML (e.g. making it possible to extend <ul>, using the HTML parser, etc).


> For conservatives, the worst-case scenario includes a whole new breed of
> markup where documents no longer contain any recognizable HTML semantics,
> and as such does not seem much better than the imperative approach that top
> sites use now. 

I think the worst-case scenario is to have documents no longer contain any recognizable HTML semantics while still having all the problems with HTML today — being forced to work around the HTML vocabulary, having the HTML parser's wacky quirks always fighting with us, etc. Making entirely new vocabularies, maybe even new syntaxes, isn't out of the question IMHO.


I don't have a problem with us attempting to create a new mechanism by which you can create widget libraries, using the DOM, CSS, JS, SVG as a framework on which to hang in, possibly with a new syntax that's actually nice for designing UIs (rather than the SGML-derived mess we have now). I don't have a problem with us making a system that leverages HTML's strength as a semantic vocabulary, giving a way to extend the platform while building on top of what it is already.

What I object to is designing something that essentially gives lip service to the latter while really trying to do the former. That's the worst of both worlds; people will make their own vocabularies, but will be constrained by HTML's quirks and warts.

After discussing the alternate proposal presented by Ian and Dimitri, we (Alex Russell, Dimitri Galzkov, Elliott Sprehn, Ian, Matt McNulty, Scott Miles, Tab Atkins, and myself) have arrived at a slightly modified proposal that we feel balances the various concerns raised by those who have participated in the discussion thus far. Please provide commentary and feedback to ensure this proposal accounts for the necessary requirements and use-cases:

--- Custom Element Instantiation ---

Custom elements can be instantiated using either a custom tag, or the application of a custom element name using the is="" attribute. Using the is="" attribute to apply a custom element definition to a native element _will not_ affect proto inheritance of the custom element.

--- Custom Element Declaration ---

Custom elements will continue to be defined via the <element> tag or the document.register DOM interface. Extension of native element prototypes will occur only by way of the HTMLElementElement's extends attribute or the document.register interface's prototype option.

Custom element names must include a dash somewhere in the string - this is a modification to the current spec draft which forced a more specific "x-" prefix.

--- Extension of Native Elements ---

There will be no prohibition on the extension of native elements regardless of which of the two supported custom element instantiation methods the developer uses.

--- Reasons for Two Instantiation Methods ---

There are many valid use-cases that highlight the need for both custom instantiation options, some are technical, others are semantic in nature - here are a couple examples:

- Extension of elements such as <td>, that heavily depend on a delicate technical dance between various parts of the browser's implementation stack and the HTML parser.

- Semantic fallback support for developers/applications that require content be evaluated and understood by all manner of parsing agent.

The spec editor will provide an explanation for each of the custom element declaration options that details what each option was designed to allow for, and includes examples that highlight where the use of one is advisable over the other.

(In reply to comment #48)
> After discussing the alternate proposal presented by Ian and Dimitri, we
> (Alex Russell, Dimitri Galzkov, Elliott Sprehn, Ian, Matt McNulty, Scott
> Miles, Tab Atkins, and myself) have arrived at a slightly modified proposal
> that we feel balances the various concerns raised by those who have
> participated in the discussion thus far. Please provide commentary and
> feedback to ensure this proposal accounts for the necessary requirements and
> use-cases:
> 
> --- Custom Element Instantiation ---
> 
> Custom elements can be instantiated using either a custom tag, or the
> application of a custom element name using the is="" attribute. Using the
> is="" attribute to apply a custom element definition to a native element
> _will not_ affect proto inheritance of the custom element.
> 
> --- Custom Element Declaration ---
> 
> Custom elements will continue to be defined via the <element> tag or the
> document.register DOM interface. Extension of native element prototypes will
> occur only by way of the HTMLElementElement's extends attribute or the
> document.register interface's prototype option.
> 
> Custom element names must include a dash somewhere in the string - this is a
> modification to the current spec draft which forced a more specific "x-"
> prefix.
> 
> --- Extension of Native Elements ---
> 
> There will be no prohibition on the extension of native elements regardless
> of which of the two supported custom element instantiation methods the
> developer uses.
> 
> --- Reasons for Two Instantiation Methods ---
> 
> There are many valid use-cases that highlight the need for both custom
> instantiation options, some are technical, others are semantic in nature -
> here are a couple examples:
> 
> - Extension of elements such as <td>, that heavily depend on a delicate
> technical dance between various parts of the browser's implementation stack
> and the HTML parser.
> 
> - Semantic fallback support for developers/applications that require content
> be evaluated and understood by all manner of parsing agent.
> 
> The spec editor will provide an explanation for each of the custom element
> declaration options that details what each option was designed to allow for,
> and includes examples that highlight where the use of one is advisable over
> the other.


This is exectly where I thought we were in dimitri/hixie compromise until I clarrified with them on irc that that was not the case.  This addresses the concerns I brought up there and I think seems reasoanble.  I'm good with it.  Wish I had been able to be in the room to hear what it took to get there - good job guys.

Looks good to me. The spec should have a non-normative section that tries to explain to authors that for use cases on the "application" end of the spectrum it's probably ok to use the element name form, and that for use cases on the "document" end of the spectrum it's better to use the is="" form so that tools don't have to process the component declarations to work out what's going on. (On top of the more immediate problem authors will run into with not being able to use custom tags in situations like <table>, of course.)

https://dvcs.w3.org/hg/webcomponents/rev/cbe7b22fbdec (there will be more before it's all fixed up).

https://dvcs.w3.org/hg/webcomponents/rev/26e3c5a64368

The thrust of the issue is now resolved. There are few remaining issues that I will track separately.

*** Bug 14967 has been marked as a duplicate of this bug. ***