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

On Tue, 11 Oct 2011, Dimitri Glazkov wrote:
> On Tue, Oct 11, 2011 at 11:25 AM, Erik Arvidsson <arv@chromium.org> wrote:
> > By splitting I meant (and I think Ian did as well) that we have
> > decorators that does not change the interface and then we have
> > components which can change the shadow tree and define a new interface
> > (API).
> >
> > The decorators can be attached and detached at runtime using css and
> > maybe even an imperative API. The decorators cannot change the
> > interface.
> >
> > The components have to be defined before first access and elements are
> > created tied to a specific interface.
> 
> +1. However, Hixie just one message ago indicated that he doesn't see 
> distinction between components and decorators (or bindings). So I think 
> there's still some clarification work to do.

I don't see a distinction between the word "component" and the word 
"binding". The term "binding" comes from the point of view of the linking 
of a definition to an element. The term "component" comes from the point 
of view of the definition itself. Microsoft has historically used the term 
"component" ("HTC" stands for "HTML Component"), whereas Mozilla has 
historically used the term "binding" ("XBL" stands for "(something) 
Binding Language", for various values of "something").

These aren't the only terms that have been used to describe this, by the 
way. The term "behaviour" has long been used (indeed "behavior" the CSS 
property used to link to an HTC component, and was originally the property 
used to link to an XBL binding, and that term was used by the CSS working 
group to refer to the concept; e.g. "BECSS" stands for "Behavioral 
Extensions to CSS"). The CSS working group also worked on a technology 
called "Action Sheets", which is in the same space.

The main development in this space recently has been the idea of the split 
Erik describes in the text quoted above. That is, that a component, or 
binding, can be an API-defining component or API-defining binding, 
permanently bound using is="" at element-creation time; and a component, 
or binding, can be a decorator component or decorator binding, bound from 
CSS (or using is="", or via an API), in a potentially transient manner, 
but not defining an API.

Or to use a table:

                             | Decorator binding or | Permanent binding or
                             | decorator component  | permanent component
-----------------------------+----------------------+----------------------
 Can be bound at element-    |         YES          |        YES
  creation time (is="")      |                      |
-----------------------------+----------------------+----------------------
 Can be bound from CSS       |         YES          |        NO
-----------------------------+----------------------+----------------------
 Can be bound from an API    |         YES          |        NO
-----------------------------+----------------------+----------------------
 Can be rebound to another   |         YES          |        NO
  binding later              |                      |        
-----------------------------+----------------------+----------------------
 Can have the binding        |         YES          |        NO
  removed altogether         |                      |        
-----------------------------+----------------------+----------------------
 Can define a shadow tree    |         YES          |        YES
-----------------------------+----------------------+----------------------
 Can define ARIA roles for   |         YES          |        YES
  the element and shadow tree|                      |
-----------------------------+----------------------+----------------------
 Can define scope styles     |         YES          |        YES
-----------------------------+----------------------+----------------------
 Can define event handlers   |         YES          |        YES
-----------------------------+----------------------+----------------------
 Can run script from timers  |         YES          |        YES
-----------------------------+----------------------+----------------------
 Can manipulate the DOM via  |         YES          |        YES
  script                     |                      |        
-----------------------------+----------------------+----------------------
 Can define a public API     |         NO           |        YES
-----------------------------+----------------------+----------------------
 Must be declared in the     |         YES          |        YES
  page before the binding    |                      |        
  can be used                |                      |        
-----------------------------+----------------------+----------------------

Since these are so close to each other, I don't see much value in having 
different solutions for decorating bindings (used for presentation, 
changing what existing widgets look and feel like) vs permanent 
API-defining bindings (used to introduce new widgets). Indeed all of the 
existing solutions -- HTC, XBL (both the original version and the various 
XBL2 variants), ActionSheets, etc, can all be relatively easily 
shoe-horned into this new concept to support both transient and permanent 
bindings/components with their various subtle differences.

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

Received on Tuesday, 11 October 2011 19:24:43 UTC