- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 28 Sep 2011 16:15:19 -0400
- To: public-webapps@w3.org
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