W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

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

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 28 Sep 2011 22:54:49 +0000 (UTC)
To: Dimitri Glazkov <dglazkov@chromium.org>
cc: Roland Steiner <rolandsteiner@chromium.org>, WebApps WG <public-webapps@w3.org>, Dominic Cooney <dominicc@chromium.org>
Message-ID: <Pine.LNX.4.64.1109282249110.29849@ps20323.dreamhostps.com>
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


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

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

This is purely presentational and should be triggered from CSS.


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

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 28 September 2011 22:57:50 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:47 GMT