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

On Wed, 28 Sep 2011, Dimitri Glazkov wrote:
> 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?

If an author invents a new element, it doesn't matter what it inherits 
from. It won't have fallback behaviour, it won't have semantics that can 
be interpreted by search engines and accessibility tools, it won't have 
default renderings, and it won't allow for validation to catch authoring 
mistakes. I don't see what inheritance has to do with anything here.

If you're not talking about my e-mail above but bz's first one, then the 
problems still exist, unless you're saying that an author shouldn't be 
allowed to create a custom submit button by inheriting from HTMLElement.

If you're talking about bz's second e-mail, then consider cases such as:

   <p>Foo
   <div> Bar </div>

...vs:

   <p>Foo
   <x-div> Bar </x-div>


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

The point is that the page just uses <select>, and the style is changed in 
the style sheet.


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

It's far more practical for an author to pick different layout tools in 
CSS, than it is for them to (mis-)build a layout system that can do 
multiple form factors.


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

They don't have to be thought of as decorators, but solutions that don't 
make them decorators are IMHO fundamentally flawed.

The way the Web works is that we have split the logic (semantics) from the 
presentation (layout). The former is in the markup and in scripts in the 
markup. The latter is in the CSS layer and images and, potentially, 
scripts in the CSS. This allows authors to cleanly write logic that is 
independent of the presentation, it allows for features such as media 
queries and alternative style sheets, and it supports graceful fallback in 
legacy UAs, accessibility, processing in tools that don't care about the 
presentation layer (such as search engines) or that have their own (such 
as voice browsers), and allows for the presentation to be applied to many 
pages at once and changed on a whim, without having to do changes on every 
page. This is a well-established, successful model. We should continue to 
use it and support it.

-- 
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:55:24 UTC