W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

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

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 28 Sep 2011 21:25:48 -0400
Message-ID: <4E83C91C.4020808@mit.edu>
To: Ian Hickson <ian@hixie.ch>
CC: public-webapps@w3.org
On 9/28/11 7:02 PM, Ian Hickson wrote:
> There are specific problems in both those cases because of interaction
> with the C++ layer, as far as I can tell.

Those are there, sure.  But they're not the only problems...

> 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

I wouldn't call it "well" supported.

In particular proto chain changes can cause various deoptimizations to 
happen in JITs.

> but defined in increasingly careful detail.

I'm not aware of anything that defines mutable prototype chains. 
Pointer please?  There has been desire to maybe standardize it in ES, 
but no real action yet.

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

I'm not aware of any work to make changing the prototype chain more 
useful to anyone...

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

Ah, good point.  OK, this seems like the way to go then.

Note that unlike <script src> this value would never have an effect when 
set dynamically; we'd just have some other API for scripted component 
attachment.

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

Yeah, I think it's fine to restrict such use cases to not adding any API 
to the elements.

-Boris
Received on Thursday, 29 September 2011 01:26:30 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:47 GMT