On Tue, Dec 10, 2013 at 10:34 AM, Anne van Kesteren <annevk@annevk.nl>wrote:
> I think Ryosuke has a point here though. ES6 brings subclassing to the
> platform, but are not even close to reimagining the platform in terms
> of that.
ES6 does not bring sub classing to the table. It has been there all along
(since ES1) and WebIDL heavily uses it.
Maybe I'm missing your point?
> E.g. the <dialog>'s close() method won't work as defined
> right now on a subclass of HTMLDialogElement.
Why would it not work? Remember that the instance object is going to be a
HTMLDialogElement. Very similar to how people do the __proto__ hack today.
function MyDialog() {
var self = document.createElement('dialog');
self.__proto__ = MyDialog.prototype;
return self;
}
MyDialog.prototype = {
__proto__: HTMLDialogElement.prototype,
};
var el = new MyDialog();
document.body.appendChild(el);
el.close();
The thing that ES6 brings to the table is class side inheritance (doable
today using __proto__) and @@create, which is how the instance is created
so that we don't need the swizzle-proto-return-from-constructor hack.
> So I agree with Ryosuke
> that adding support for subclassing that element would be kind of
> pointless and potentially harm future endeavors in making it better
> (as authors might end up relying on it "sucking").
>
The whole point with custom elements is to unify how people create custom
widgets so that YUI, jQueryUI and ExtJS can all share common components,
since the public API is just an Element. If you agree with that goal we
need to at least subclass HTMLElement. Then people want to do the same
thing for SVGElement of course and then we are back were we started.
--
erik
Received on Tuesday, 10 December 2013 15:54:27 UTC