- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Tue, 10 Dec 2013 15:34:31 +0000
- To: Dominic Cooney <dominicc@google.com>
- Cc: Ryosuke Niwa <rniwa@apple.com>, Hajime Morrita <morrita@google.com>, Dimitri Glazkov <dglazkov@chromium.org>, "public-webapps@w3.org WG" <public-webapps@w3.org>, Jan Miksovsky <jan@quickui.org>
On Mon, Dec 9, 2013 at 12:42 AM, Dominic Cooney <dominicc@google.com> wrote: > You assert that inheriting from built-in elements does not make any sense. > You seem to base this on the claim that hooks (the example being form > submission protocol hooks) are not well defined. Whether hooks are well > defined or not doesn't sufficiently support your assertion, because: > > 1. Not all subtyping relies on hooks. For example, subtyping a built-in > element can add additional API to it. This may make sense. For example, a > social network "endorse" button has a number of additional properties. Yet > it is (or could be) a button. > > 2. The premise that hooks are not defined is also incorrect. Many hooks are > already defined. Here is one example: the INPUT element has input and change > events and a value property. These are sufficient to observe, filter and > change the value of the INPUT element. 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. E.g. the <dialog>'s close() method won't work as defined right now on a subclass of HTMLDialogElement. 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 other point is well made too. If we want to explain the platform we should not dismiss the bits we don't like about it and point to JS frameworks instead. We should try to explain it, quirks included. -- http://annevankesteren.nl/
Received on Tuesday, 10 December 2013 15:35:05 UTC