Re: Custom tags over wire, was Re: HTMLElement.register--giving components tag names

On 3/09/11 4:47 AM, Dimitri Glazkov wrote:
> On Fri, Sep 2, 2011 at 2:30 AM, Anne van Kesteren<annevk@opera.com>  wrote:
>> Examples of elements that should not be replaced but could be changed by a
>> binding: Having a sortable binding for<table>; Exposing cite="" on
>> <blockquote>; Turning a<select>  listing countries into a map.
> Great! Let's go through them:
>
> * Sortable binding for a table is really just a table subclass with
> some event listeners registered.
>
> * Exposing cite on blockquote sounds like something CSS should do.
> There's no extra behavior, and you're not really creating a new type
> of element. It's just extra boxes.
>
> * Turning select listing countries into a map -- composition to the rescue!:
>
> <x-country-map>
>     <select>
>        <option>Lilliput
>        <option>Blefuscu
>     </select>
> </x-country-map>
>
> > From the author's perspective, you don't actually need the select
> element. If you intend to show a map on cool browsers and select on
> the less cool ones, you are completely uninterested in having your
> select semantics dutifully reproduced. All you need is something that
> does what you need. Besides, the behavior of a map and a select are so
> different than you probably would scrap the former to build the latter
> anyway.

The author wants the select element so that form submission works.

The semantics of select are also quite useful as you might want the 
country-map widget to allow multiple selections, have a default selected 
country, and have a non-comprehensive list of countries to choose from.

As you have indicated, the user needs the select element as the fallback 
presentation.

It would also be useful if user stylesheets could override the behavior 
chosen by the author - either reverting to a browser select widget, or 
something provided by a browser add-on. This capability depends on there 
being a defacto standard for applying the country-map behavior. Which do 
you think would take on more quickly:
a) custom tag-names, or
b) aria or data attributes
I'm almost certain it's b.

My personal opinion is that most of the perceived need for custom 
tag-names is to put presentation into HTML. Kind of like <font> and 
<center> but without the benefit of being standards (de facto or de jure).

Sean

Received on Monday, 5 September 2011 03:40:53 UTC