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

On Wed, 28 Sep 2011, Dimitri Glazkov wrote:
> 
> Hi Ian! :)
> 
> I already enumerated and hopefully addressed most of your concerns in 
> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1156.html 
> and 
> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1187.html, 
> but I am open to other ideas.

You didn't address my concern, since my concern is that you're encouraging 
people to invent new elements. :-)


> To recap 
> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1204.html, 
> the API surface (and thus the behavior) should be something an element 
> is born with. In other words, we need element behavior attachment 
> (http://wiki.whatwg.org/wiki/Behavior_Attachment).

I don't buy the argument that an element's API can't change. We have many 
counter-examples already in the platform, for example <object>'s API 
can change dynamcially as it loads new plugins, anyone fiddling with 
prototypes can change many elements' APIs on the fly, XBL in Mozilla 
causes elements to change APIs on the fly, etc.

Furthermore, we cannot for performance reasons require that the component 
library be loaded before the page is parsed, since that would mean that 
loading an HTML page would be blocked on loading a subresource. We already 
have this problem with both style and scripts, and it is a performance 
nightmare. We're trying to work around it, by introducing features like 
<script async> and background parsing, but it's certainly not a problem we 
want to compound with new features.


> Clearly, CSS-based behavior attachment is transient.

Right. It's the right solution for a whole class of use cases, in 
particular:

 * Layout Manager (since the layout is something that should be 
   controlled primarily from CSS, and can change dynamically based on 
   different media queries matching or on the user changing the selected 
   alternative style sheet set).

 * Rendering Form Controls with SVG (since the idea is to change the 
   style of the widget to fit the site theme, and so again the exact 
   rendering might change based on media queries or alternative style 
   sheet selections).


> Additionally, security experts tell us that CSS-based behavior 
> attachment is a Bad Idea 
> (http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0699.html). 
> So we should nix that.

That's throwing the baby out with the bath water. The very e-mail you cite 
above lists a sufficient solution to the problem.


> Similarly, we can't use selectors with <binding>, since they imply that 
> an element only has behavior when in the document tree, which makes it 
> transient.

This is incorrect. Selectors can match outside document trees. Even on 
single lone elements they can match at least against attributes; in 
subtrees they can even match on ancestors.


> In abstract, we need a mechanism to bestow some properties on a DOM 
> element before it emerges from the construction site. That seems easy -- 
> just do something like this:
> 
> var elementWithBehavior = document.createElement('div',
> newBehaviorImplementation); // HTMLDivElement +
> "newBehaviorImplementation" => baby
> 
> Unfortunately, the parser has no clue about this secret sauce

You don't need to prevent transient bindings, but if you did need to 
prevent them, you could still have this feature by just having an 
attribute that lists the applicable bindings, so that the parser could 
apply them as it loads the element, as in:

   <select component="map.xml#countrySelector" ...>...

...or, if the components are predeclared and you want something very 
terse:

   <select is="map" ...>...


> and the behavior is easily lost in markup roundtrips (or while cloning):
> 
> var someOtherDiv = document.createElement('div');
> someOtherDiv.appendChild(elementWithBehavior);
> document.body.innerHTML = someOtherDiv.innerHTML;
> var ohNoesJustAnOrdinaryDivAgain = document.body.firstChild;

The attribute solution above doesn't suffer from this, since the attribute 
would be cloned at the same time.


> So, we need a way to express in markup that a particular element is to 
> be created with a particular behavior. Since the tagName is the only 
> identifying property of a DOM element that can't be changed, this brings 
> us to... custom tag names.

Custom tag names suffer from a much larger set of more serious problems 
than any of the solutions you have dismissed, as Boris and myself have 
pointed out just in the last day or so, and as others have pointed out in 
the past.


> This new world _feels_ right and I refuse going back to the old one.

Gut feeling and point-blank refusal is not how we should do language 
design. But if you insist: Custom tag names _feel_ wrong and I refuse to 
go to them. :-)

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

Received on Wednesday, 28 September 2011 20:06:14 UTC