Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On Wed, Sep 28, 2011 at 1:02 PM, Ian Hickson <ian@hixie.ch> wrote:
> On Wed, 28 Sep 2011, Dimitri Glazkov wrote:
>>
>> Hi Ian! :)
>>
>> I already enumerated and hopefully addressed most of your concerns in
>> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1156.html
>> and
>> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1187.html,
>> but I am open to other ideas.

> You didn't address my concern, since my concern is that you're encouraging
> people to invent new elements. :-)

I think new elements are completely fine as long as they are
inheriting directly from HTMLElement. It's when we start dealing with
sub-typing HTMLTableElement and such is when they get into trouble.

I am not going to recap what Boris already said in regard to
transitive APIs. It's a Fundamentally Bad Thing, and all existing
instances already in the platform are known/recognized mistakes.

>
>   <select component="map.xml#countrySelector" ...>...
>
> ...or, if the components are predeclared and you want something very
> terse:
>
>   <select is="map" ...>...
>

There's the idea of "becomes" attribute that uses a somewhat similar
approach (http://wiki.whatwg.org/wiki/Component_Model_Progressive_Enhancement).

>
>
>> So, we need a way to express in markup that a particular element is to
>> be created with a particular behavior. Since the tagName is the only
>> identifying property of a DOM element that can't be changed, this brings
>> us to... custom tag names.
>
> Custom tag names suffer from a much larger set of more serious problems
> than any of the solutions you have dismissed, as Boris and myself have
> pointed out just in the last day or so, and as others have pointed out in
> the past.

Custom tags are just a way to explain the sub-typing of DOM in markup.
If there's a better way to do it, let's.

:DG<

Received on Wednesday, 28 September 2011 21:36:11 UTC