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

On Wed, Sep 28, 2011 at 3:54 PM, Ian Hickson <ian@hixie.ch> wrote:
>
> On Wed, 28 Sep 2011, Dimitri Glazkov wrote:
> > On Wed, Sep 28, 2011 at 3:21 PM, Ian Hickson <ian@hixie.ch> wrote:
> > > On Wed, 28 Sep 2011, Dimitri Glazkov wrote:
> > > >
> > > > 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.
> > >
> > > New elements are not fine, for reasons that have been discussed in
> > > detail on this thread. You can't just dismiss those problems, they
> > > still exist.
> >
> > Can you tell me what those are? I am probably missing something.
>
> I already mentioned a bunch here:
> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1703.html
>
> And Boris mentioned some here:
> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1721.html
> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1718.html

But... these are all when we are not directly sub-typing from
HTMLElement... Can you explain where there's a fallback problem with
custom elements that are inheriting directly from HTMLElement?

>
> > > > 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.
> > >
> > > There are use cases for which it is not only not a bad thing, but a
> > > fundamental requirement.
> >
> > Can you help me understand these use cases?
>
> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1722.html
>
>
> > Are you referring to the Layout Manager and the SVG Form Controls ones?
>
> Yes, for instance. Basically any use cases that is about presentation
> rather than logic.
>
>
> > Let's use this hypothetical Layout Manager for example:
> >
> > <x-panel>
> > .... content ...
> > <x-splitter></x-splitter>
> > ... content ...
> > </x-panel>
> >
> > As an author of "x-panel", I certainly want to listen to media queries
> > and change the splitter from vertical to horizontal when there's not
> > enough space for horizontal splitting. And what I _don't_ want is some
> > other behavior bound instead to my panel and my behavior unbound.
>
> That's a new widget.

Yup.

>
> I'm talking e.g. about people who want their <select>s to look different
> based on whether it's on a touch device or a mouse device, or who want
> their layout to use one JS layout algorithm on portrait devices and
> another on landscape devices (and want to switch between them
> automatically when the user rotates the device).

You don't need transient behavior attachment in either case. For the
first case, all you need is a select-like widget that can sense a type
of a device. For the second one, it's more likely (and practical) to
build a layout system that knows how to accommodate multiple form
factors, than to expect an author to pick and choose from a bucket of
layout engines and (mis-)apply them for different form factors.

>
>
> > Also, there's probably a class of use cases for pure-decorators that are
> > added and removed transiently. That's not something Component Model
> > intends to tackle or block on.
>
> You've listed use cases for them. I assume you are interested in
> addressing the use cases you listed...

Does my explanation above help you understand that they don't _have_
to be thought of as decorators?

:DG<

>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 28 September 2011 23:22:55 UTC