- From: Dimitri Glazkov <dglazkov@chromium.org>
- Date: Wed, 28 Sep 2011 16:22:28 -0700
- To: Ian Hickson <ian@hixie.ch>
- Cc: Roland Steiner <rolandsteiner@chromium.org>, WebApps WG <public-webapps@w3.org>, Dominic Cooney <dominicc@chromium.org>
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