- From: Dimitri Glazkov <dglazkov@chromium.org>
- Date: Wed, 28 Sep 2011 15:43:42 -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: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 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? Are you referring to the Layout Manager and the SVG Form Controls ones? I think you inserted a use case there, which is theming Layout Managers and/or SVG form controls. And I believe you have the approach backwards. From author's perspective, they want the widgets to manage the styling, not the outer document. 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. And there's nothing wrong with allowing to style widgets according to the theme of the site. That's what pseudos (or even more interesting ideas, brainstormed at the Component Model meeting) are for. 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. :DG<
Received on Wednesday, 28 September 2011 22:44:15 UTC