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

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.

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

 From my point of view, this is a smaller problem than allowing elements 
to dynamically change the set of interfaces they implement, say.

> You don't need to prevent transient bindings,

For bindings that affect APIs, not just rendering, I think we'd very 
much like to.

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.

-Boris

Received on Wednesday, 28 September 2011 20:15:48 UTC