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

On Wed, 28 Sep 2011, Boris Zbarsky wrote:
> On 9/28/11 4:02 PM, Ian Hickson wrote:
> > I don't buy the argument that an element's API can't change.
> 
> To be more precise, such changes are very undesirable.
> 
> > We have many counter-examples already in the platform, for 
> > example<object>'s API can change dynamcially as it loads new plugins
> 
> This is actually a serious problem in practice, for both implementors 
> and consumers.  The behavior here is not very interoperable outside the 
> simplest cases last I checked.
> 
> > XBL in Mozilla causes elements to change APIs on the fly
> 
> We consider this to have been a design mistake that complicates both 
> implementation and use.  We have absolutely no desire to perpetuate it.

There are specific problems in both those cases because of interaction 
with the C++ layer, as far as I can tell. The pure JS side of things, 
which is all that is needed for what we're talking about here, needs 
nothing more than just adding a prototype, something which is not only 
well-supported by all browsers, but defined in increasingly careful 
detail. Interoperability is only improving here, and there seems to be no 
desire to remove it -- quite the opposite, we're actively working on 
making it more useful for authors.

IMHO this is the kind of thing that it makes imminent sense for a binding 
layer to make use of.


> > 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.
> 
> I agree that it can cause performance problems, but as you note we 
> already have this with <script>, and speculative parsers are getting 
> pretty good.

If you add an RTT to the page load, it doesn't matter how good your parser 
is. You're going to be slower than not having the RTT unless your page is 
absolutely huge.


> Using an attribute to declare the binding could work if we make its 
> value immutable or if we make changes to its value have no effect.

For use cases consisting of creating new or augmented widgets, that's fine 
by me. We already have plenty of precedent for attributes whose changes do 
nothing, for example <script src> and, most recently, <html manifest="">.

For use cases that are intrinsically presentational and dynamic, like 
layout managers, I don't think the markup should need to be changed 
(except in the <head>, to opt-in to the binding and style sheets).

Those use cases probably don't need the elements to actually expose an 
API, though, so maybe that's a non-issue. They do need to be able to hook 
event handlers, read existing APIs, and modify the presentation.

-- 
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:05:52 UTC