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

On Wed, Sep 28, 2011 at 4:52 PM, Ian Hickson <ian@hixie.ch> wrote:
>
> 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.

Yes! That's what inheriting directly from HTMLElement implies. It's
not a button (from the browser's perspective, at least), since it does
not have the API and expected behavior of HTMLButtonElement.

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

Can you be a bit more specific and explain the problem you're trying
to highlight with this example?

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

Amen, you're preaching to the choir here. (And I hope you know that, too!)

The purpose of components is to extend semantics of markup beyond
what's available in HTML, not create presentational custom elements.

In every layout manager in existence today, you have:
a) a markup structure to represent the skeletal basis of the layout;
b) a built-in behavior to react to environment changes
(portrait/landscape, resize, scroll, etc.)
c) an API to manipulate the layout programmatically (turn page,
advance to next panel, etc.)

If we only had a), pure CSS should be tasked with enabling this.

If we only had a) and b), I could somewhat see a layout manager
implemented as a decorator, even though it's unlikely that the layout
binding will ever change during the lifetime of a document. It's cool
to imagine how there will be different bindings applied to the DOM
structure owned by a layout manager to produce different layouts, but
in reality I expect the reaction logic encapsulated within one
binding.

Once you're operating on the layout programmatically, you need logical
primitives that explain and expose the functionality of a layout
manager to DOM scripting. You need DOM objects that are Panes,
Containers, Splitters, etc. In this case, you have to go with element
behavior attachment.

:DG<

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

Received on Thursday, 29 September 2011 17:37:09 UTC