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
