Re: [webcomponents] Custom Elements Spec

Ian, it seems you are continuing to confuse two very different things:

1. local semantics;
2. extending existing elements.

They have completely different purposes. Web-developers generally do not need to _extend_ existing elements (purpose of such extending itself is quite mysterious for me).

What we need is local semantics that has more elegant code representation than _common_ container (SPAN or DIV) with a class. For example:

    <x-lorem></x-lorem>

looks far better, compact, readable, and sensible than:

    <span class="x-lorem"></span>

(at the same extent as <p></p> is better and smarter then <div class="p"></div> even if P had no any semantic sense).

Both <x-lorem> and <span class="x-lorem"> have NO global semantics at all like that SELECT element have.

Instead, they have _local_ semantics which purpose is known exclusively for document author/scripts and/or consumers of the document. No any "fallbacks" needed here at all.

Some of possible additional practical benefits of custom tag-names are:

     * browsers could implement more effective markup error correction
       based on equality of tag-name of opening and closing tags;

     * microformats that would not forced to rely on classes,
       but would use tag names instead.

As for markup error correction: for example, in case of multiple nested DIVs, browser cannot unambiguously determine what exact DIV a closing tag is related to:

    <div>
        <div>
        <!-- Closing tag for nested DIV is accidentally absent. -->
    </div><!-- Browser wrongly thinks that parent's closing tag is for nested DIV. -->

With custom tag-names, browser could easily determine exact element that has closing tag absent:

    <x-lorem>
        <x-ipsum>
        <!-- Closing tag for x-ipsum is accidentally absent. -->
    </x-lorem><!-- Browser automatically closes x-ipsum element. -->

Again: local semantics (custom _tag-names_) has nothing to do with "custom elements" in their current form like <select is="example">.

Thanks.

04.05.2012, 08:19, "Ian Hickson" <ian@hixie.ch>:
> On Tue, 1 May 2012, Dimitri Glazkov wrote:
>
>> šCustom tags vs. "is" attribute
>> š- "is" attribute is awkward, overly verbose
>> š- custom tags introduce local semantics
>> š- perhaps start with something as simple as reserving "x-" prefix on
>> šHTML tags for local semantics.
>
> Whether it's
>
> ššš<x-colour-picker fallback="select">
>
> ...or:
>
> ššš<select is="colour-picker">
>
> ...you have the same level of awkwardness. The advantage of the second
> one, aside from being less ugly and generally terser, is that it actually
> has workable fallback in legacy UAs -- the first one would only work in
> UAs that supported components or at a minimum knew enough about components
> to know how the fallback mechanism worked. (Also, the first one runs the
> risk that authors would start forgetting to give a fallback, with its
> resulting implications on accessibility, search engines, etc.)
>
> --
> Ian Hickson ššššššššššššššU+1047E ššššššššššššššš)\._.,--....,'``. šššfL
> http://ln.hixie.ch/ ššššššU+263A ššššššššššššššš/, šš_.. \ šš_\ š;`._ ,.
> Things that are impossible just take longer. šš`._.-(,_..'--(,_..'`-.;.'

Received on Friday, 4 May 2012 18:41:25 UTC