Custom form elements (was Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax))
On Dec 7, 2013, at 4:38 PM, Dominic Cooney domin...@google.com wrote: Built-in HTML elements have lots of hooks to modify their behaviour (for example, HTMLVideoElement's autoplay attribute.) The analogy is extending a Java class which has private and public final members, but no protected or public non-final ones. If someone were to make proposals about adding more hooks to the web platform to enable more subtyping use cases (for example, a protocol for participating in form submission) I would look forward to working with them on those proposals. Let's say you have the ability to define a custom element inheriting from a form element, but completely replace its rendering and behavior with custom shadow DOM. Is that actually sufficient to participate correctly in form submission? I don't think it is. In particular, I don't see how a custom element could inherit from HTMLInputElement, fully support the interface, and correctly submit a value that is specified via a completely custom mechanism. Also, even if it worked, inheriting from HTMLInputElement is a particularly clunky approach to participating in form submission. To actually correctly support the interface, you need your component to support every input type. But that is way overkill if you only want to replace a single kind of input, or define a new type of your own. The more convenient approach would be to ignore type-switching and as a consequence make a subclass that does not respect the Liskov Substituton Principle and is therefore bad OO. I think giving custom elements a specific API for participating in form submission, to enable defining new kinds of form elements, would be a better approach to this problem and ultimately easier to use. It is also much more relevant as a way to explain how the way the Web platform works. Built-in form elements participate in form submission by having special hooks to participate in form submission, not by inheriting from other form elements. Regards, Maciej
Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
On Dec 10, 2013, at 12:24 PM, Elliott Sprehn espr...@chromium.org wrote: On Tue, Dec 10, 2013 at 8:00 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Dec 10, 2013 at 3:54 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/10/13 10:34 AM, Anne van Kesteren wrote: E.g. the dialog's close() method won't work as defined right now on a subclass of HTMLDialogElement. Why not? I assumed that actual ES6 subclassing, complete with invoking the right superclass @@create, would in fact produce an object for which this would work correctly. At least any situation that doesn't lead to that is a UA/spec bug. Well for one because the specification at the moment talks about a dialog element and does not consider the case where it may have been subclassed. The pending dialog stack is also for dialog elements only, not exposed in any way, etc. The way the platform is set up at the moment is very defensive and not very extensible. When extending native elements like that you use type extensions, so it'd be dialog is=my-subclass and the tagName is still DIALOG. Registering something that extends HTMLDialogElement but isn't a type extension of dialog does not work, in the same way that doing __proto__ = HTMLDivElement doesn't magically make you into a div today. The document.register method does not seem to support what you describe as currently spec'd, but does have an API doing the thing that won't actually work, i.e. registering my-subclass to be a subclass of HTMLDialogElement. Regards, Maciej
Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
On Mon, Dec 9, 2013 at 12:42 AM, Dominic Cooney domin...@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/
Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
On Tue, Dec 10, 2013 at 10:34 AM, Anne van Kesteren ann...@annevk.nlwrote:
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
Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
On 12/10/13 10:34 AM, Anne van Kesteren wrote: E.g. the dialog's close() method won't work as defined right now on a subclass of HTMLDialogElement. Why not? I assumed that actual ES6 subclassing, complete with invoking the right superclass @@create, would in fact produce an object for which this would work correctly. At least any situation that doesn't lead to that is a UA/spec bug. -Boris
Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
On Tue, Dec 10, 2013 at 3:53 PM, Erik Arvidsson a...@chromium.org 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? ES6 does bring it to the table. Just see how all the methods of built in objects have been carefully redesigned to take advantage of it. We haven't done that on the platform side. -- http://annevankesteren.nl/
Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
On Tue, Dec 10, 2013 at 3:54 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/10/13 10:34 AM, Anne van Kesteren wrote: E.g. the dialog's close() method won't work as defined right now on a subclass of HTMLDialogElement. Why not? I assumed that actual ES6 subclassing, complete with invoking the right superclass @@create, would in fact produce an object for which this would work correctly. At least any situation that doesn't lead to that is a UA/spec bug. Well for one because the specification at the moment talks about a dialog element and does not consider the case where it may have been subclassed. The pending dialog stack is also for dialog elements only, not exposed in any way, etc. The way the platform is set up at the moment is very defensive and not very extensible. -- http://annevankesteren.nl/
RE: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
From: a...@google.com a...@google.com on behalf of Erik Arvidsson a...@chromium.org On Tue, Dec 10, 2013 at 10:34 AM, Anne van Kesteren ann...@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? Perhaps the situation is better stated as: ES6 brings a mechanism for creating exotic objects to the table, without opting out of the normal JavaScript meta-object protocol and inheritance model. (Namely, by returning exotic objects from @@create.) Somewhat relatedly, it also brings mechanisms for truly private state via weak maps, which was not possible for non-exotic prototype-using objects before ES6, and finally it allows you to create a large class of exotic objects that you couldn't previously, via proxies. All this means we are now much more capable of expressing WebIDL-derived APIs in terms of the same JavaScript semantics programmers have access to, whereas in the ES5 timeframe only spec-writers and implementers had access to those. As such it is possible to create such APIs that allow subclassing by using these new JavaScript constructs to expose their lifecycle and internals, whereas before they would often simply opt-out of trying to expose a usable JavaScript interface, by e.g. throwing errors whenever people tried to compose them with normal JavaScript concepts like subclassing. The task of retrofitting this kind of support onto the platform is another matter entirely. For example, WebIDL doesn't have an easy way to express `return new this.constructor(...)`---as a subclassing-friendly class would often do---as a result of its declarative type-ish nature. We have had related discussions when defining [Elements][1], and they were never truly resolved. Other places this has cropped up include promises and streams, both of which are designed in subclassing-friendly fashion, but at the price of using ES formalism instead of WebIDL. This is probably just a matter of people putting in the right work to make WebIDL, and the relevant specs consuming it, better. But it's a large task that's still underway. Nevertheless, it would be unfortunate to use the in-progress nature of making the web platform more JavaScript-friendly as an argument for making it more JavaScript hostile (by prohibiting element subclassing). [1]: http://dom.spec.whatwg.org/#collections:-elements
Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
On Tue, Dec 10, 2013 at 4:10 PM, Domenic Denicola dome...@domenicdenicola.com wrote: Nevertheless, it would be unfortunate to use the in-progress nature of making the web platform more JavaScript-friendly as an argument for making it more JavaScript hostile (by prohibiting element subclassing). Well, the question is more what we should focus on first and whether doing it in the wrong order will be future hostile. I'm also somewhat skeptical that if we don't go through the exercise of explaining a couple of existing elements first, the generic mechanism they are all supposed to end up with will be correct. -- http://annevankesteren.nl/
Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
On Tue, Dec 10, 2013 at 11:15 AM, Anne van Kesteren ann...@annevk.nlwrote: On Tue, Dec 10, 2013 at 4:10 PM, Domenic Denicola dome...@domenicdenicola.com wrote: Nevertheless, it would be unfortunate to use the in-progress nature of making the web platform more JavaScript-friendly as an argument for making it more JavaScript hostile (by prohibiting element subclassing). Well, the question is more what we should focus on first and whether doing it in the wrong order will be future hostile. I'm also somewhat skeptical that if we don't go through the exercise of explaining a couple of existing elements first, the generic mechanism they are all supposed to end up with will be correct. I agree and have previously sketched how large parts of document.register can be made to work with @@create without adding anything to the platform (besides @@create). The things that are still magic are the lifetime callbacks and how the parser first creates the JS objects. We carefully crafted document.register with ES6 classes in mind. It is not a coincidence that both constructor functions and the dict used today ind doc.reg have a prototype property. -- erik
Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
On Tue, Dec 10, 2013 at 8:00 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Dec 10, 2013 at 3:54 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/10/13 10:34 AM, Anne van Kesteren wrote: E.g. the dialog's close() method won't work as defined right now on a subclass of HTMLDialogElement. Why not? I assumed that actual ES6 subclassing, complete with invoking the right superclass @@create, would in fact produce an object for which this would work correctly. At least any situation that doesn't lead to that is a UA/spec bug. Well for one because the specification at the moment talks about a dialog element and does not consider the case where it may have been subclassed. The pending dialog stack is also for dialog elements only, not exposed in any way, etc. The way the platform is set up at the moment is very defensive and not very extensible. When extending native elements like that you use type extensions, so it'd be dialog is=my-subclass and the tagName is still DIALOG. Registering something that extends HTMLDialogElement but isn't a type extension of dialog does not work, in the same way that doing __proto__ = HTMLDivElement doesn't magically make you into a div today. - E
Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
On Dec 10, 2013, at 9:20 AM, Erik Arvidsson a...@chromium.org wrote: On Tue, Dec 10, 2013 at 11:15 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Dec 10, 2013 at 4:10 PM, Domenic Denicola dome...@domenicdenicola.com wrote: Nevertheless, it would be unfortunate to use the in-progress nature of making the web platform more JavaScript-friendly as an argument for making it more JavaScript hostile (by prohibiting element subclassing). Well, the question is more what we should focus on first and whether doing it in the wrong order will be future hostile. I'm also somewhat skeptical that if we don't go through the exercise of explaining a couple of existing elements first, the generic mechanism they are all supposed to end up with will be correct. I agree and have previously sketched how large parts of document.register can be made to work with @@create without adding anything to the platform (besides @@create). The things that are still magic are the lifetime callbacks and how the parser first creates the JS objects. We carefully crafted document.register with ES6 classes in mind. It is not a coincidence that both constructor functions and the dict used today ind doc.reg have a prototype property. Let us look at some examples. http://www.whatwg.org/specs/web-apps/current-work/#dom-document-body says on setting, document.body would in step 3: Otherwise, if the body element is not null, then replace that element with the new value in the DOM, as if the root element's replaceChild() method had been called with the new value and the incumbent body element as its two arguments respectively, then abort these steps. Now, with custom elements, authors can easily override replaceChild's behavior. Yet, UAs will continue to use its internal implementation of replaceChild() for the purpose of this algorithm. If some author is creating an element that inherits from HTMLInputElement like people have been suggesting, then it needs to support every supported types of the input element per Liskov substitution principe to be a proper subclassing. I don't see authors possibly supporting all of the existing types, let alone future types we'll be adding in the future. Now recall our experience with translate content attribute where we broke some JS library made that supported its own version of translate content attribute. With custom elements, authors are encouraged to add similar attributes on subclasses of HTMLElement. It means that anytime we're adding a new property on HTMLElement, we have to be very careful in checking whether a given name is used or not. Allowing subclassing from subclasses of HTMLElement would mean that we're increasing this API surface concern to all of them. That's a lot of new constraints we'll be adding to the extensibility of the Web platform from the browser vendors. Other GUI frameworks and platforms get away with this because those frameworks wouldn't get upgraded automatically. It's true that authors could already do this by modifying the prototype chain of HTMLElement and their subclasses, but that's by no means a natural and encouraged way of programming on the Web today. With custom elements, we'll be encouraging that. - R. Niwa
Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
On Dec 8, 2013, at 4:42 PM, Dominic Cooney domin...@google.com wrote: On Sun, Dec 8, 2013 at 7:25 PM, Ryosuke Niwa rn...@apple.com wrote: On Dec 7, 2013, at 4:38 PM, Dominic Cooney domin...@google.com wrote: On Fri, Dec 6, 2013 at 3:34 PM, Ryosuke Niwa rn...@apple.com wrote: On Dec 5, 2013, at 10:09 PM, Hajime Morrita morr...@google.com wrote: On inheritance around HTMLElement family, there seems to be a confusion between interface side inheritance and implementation side inheritance. Right. Differentiating the two is very important. For Custom Elements, the inheritance is not only about interface, but also about implementation. The implementation is more complex and flux in detail, thus worth being shared between different elements. Actually, the implementation of built-in HTML elements, which are usually done in C++, uses inheritance heavily, at least Blink and (I believe) WebKit. The reason we can use inheritance heavily is because we have control over both parent and child classes, and there are careful distinctions between public, protected, and private member functions and member variables in those classes. Unfortunately, custom elements can't easily inherit from these builtin HTML elements because builtin elements do not provide protected functions, and they don't expose necessary hooks to override internal member functions to modify behaviors. Built-in HTML elements have lots of hooks to modify their behaviour (for example, HTMLVideoElement's autoplay attribute.) The analogy is extending a Java class which has private and public final members, but no protected or public non-final ones. If someone were to make proposals about adding more hooks to the web platform to enable more subtyping use cases (for example, a protocol for participating in form submission) I would look forward to working with them on those proposals. The problem here is that until such hooks are well defined, inheriting from builtin elements doesn't make any sense. So let's not support that until such proposal is made and implemented. 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. If the only use case was to add new JavaScript property, then we wouldn't need custom elements at all. Authors could already do this by simply adding properties on builtin elements. As for the social endorse button, I've never seen a popular SNS share buttons implemented using HTML button elements; most of them add their own DOM to add icons, etc... 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. This can't possibly be an explanation for whether hooks are well defined or not doesn't sufficiently support your assertion. HTML input elements have a lot more internal states than just the value. To list a few: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#concept-input-value-dirty-flag http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#concept-input-checked-dirty-flag In mentioning hooks, was merely observing that we could define more hooks to enable even more use cases. In addition, consider how inheriting views work in AppKit, UIKit, .net and MFC. When a view T inherits from another view S, T doesn't simply put S into a subregion of T; S intrudes into T's view and modifies what's been displayed or places extra content after or before T draws itself. I can not discern a specific point you are making here. You are drawing an analogy to various UI frameworks but you have not completed the analogy. I think if you completed the analogy it would end up being a claim about Shadow DOM. You may have confused extending an element and having Shadow DOM. As Rafael Weinstein points out here: http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0883.html, whether an element has Shadow DOM is orthogonal to whether it is a Custom Element or not. I also disagree with your implied argument about Shadow DOM. Then we simply continue to disagree about this point. I have a hard time understanding how this bizarre mixture of inheritance and composition is considered as the minimal subset of features while adding one optional argument to document.register to
Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
On Tue, Dec 10, 2013 at 6:38 AM, Ryosuke Niwa rn...@apple.com wrote: On Dec 8, 2013, at 4:42 PM, Dominic Cooney domin...@google.com wrote: On Sun, Dec 8, 2013 at 7:25 PM, Ryosuke Niwa rn...@apple.com wrote: On Dec 7, 2013, at 4:38 PM, Dominic Cooney domin...@google.com wrote: On Fri, Dec 6, 2013 at 3:34 PM, Ryosuke Niwa rn...@apple.com wrote: On Dec 5, 2013, at 10:09 PM, Hajime Morrita morr...@google.com wrote: On inheritance around HTMLElement family, there seems to be a confusion between interface side inheritance and implementation side inheritance. Right. Differentiating the two is very important. For Custom Elements, the inheritance is not only about interface, but also about implementation. The implementation is more complex and flux in detail, thus worth being shared between different elements. Actually, the implementation of built-in HTML elements, which are usually done in C++, uses inheritance heavily, at least Blink and (I believe) WebKit. The reason we can use inheritance heavily is because we have control over both parent and child classes, and there are careful distinctions between public, protected, and private member functions and member variables in those classes. Unfortunately, custom elements can't easily inherit from these builtin HTML elements because builtin elements do not provide protected functions, and they don't expose necessary hooks to override internal member functions to modify behaviors. Built-in HTML elements have lots of hooks to modify their behaviour (for example, HTMLVideoElement's autoplay attribute.) The analogy is extending a Java class which has private and public final members, but no protected or public non-final ones. If someone were to make proposals about adding more hooks to the web platform to enable more subtyping use cases (for example, a protocol for participating in form submission) I would look forward to working with them on those proposals. http://goto.google.com/dc-email-sla The problem here is that until such hooks are well defined, inheriting from builtin elements doesn't make any sense. So let's not support that until such proposal is made and implemented. 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. If the only use case was to add new JavaScript property, then we wouldn't need custom elements at all. Authors could already do this by simply adding properties on builtin elements. If you do this on the Interface Prototype Object of a built-in element, the API will appear on all elements of that type. So that is not a feasible solution for many use cases. If you try to do this on a per-instance basis, that means you have to track instances. As I pointed out here: http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0893.html that is very difficult for the author to do correctly. Custom Elements puts the responsibility for this in the UA which has full knowledge of when elements are being created. As for the social endorse button, I've never seen a popular SNS share buttons implemented using HTML button elements; most of them add their own DOM to add icons, etc... This is why it is important to be able to subtype built-in elements. Some authors prefer buttons to be buttons because of the better default handling by accessibility technology. Tangentially, this is also why it is important to be able to add Shadow DOM to built-in elements. It should be possible to elaborate the UI of a button but still get the benefits of encapsulated styles, encapsulation from accidental access through casual DOM walking or simple CSS selectors, etc. 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. This can't possibly be an explanation for whether hooks are well defined or not doesn't sufficiently support your assertion. HTML input elements have a lot more internal states than just the value. To list a few: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#concept-input-value-dirty-flag http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#concept-input-checked-dirty-flag I did not claim that all possible hooks are defined. I claimed that some hooks are defined. These enable some use cases. I was observing that
Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
Ryosuke Niwa wrote: As for the social endorse button, I've never seen a popular SNS share buttons implemented using HTML button elements; most of them add their own DOM to add icons, etc... Right you are. And there's a deeper reason why like (endorse, LOL) buttons use iframes: the ability to set 3rd party cookies. /be
Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
On Mon, Dec 9, 2013 at 5:50 PM, Brendan Eich bren...@secure.meer.netwrote: Ryosuke Niwa wrote: As for the social endorse button, I've never seen a popular SNS share buttons implemented using HTML button elements; most of them add their own DOM to add icons, etc... Right you are. And there's a deeper reason why like (endorse, LOL) buttons use iframes: the ability to set 3rd party cookies. They don't actually need to be able to set cookies, but they do need to be able to _read_ them. For example some widgets show your username and your face next to the button so it'd say: Like this as +Elliott Sprehn, or Leave a comment as Elliott. - E
Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
On Dec 9, 2013, at 5:12 PM, Dominic Cooney domin...@google.com wrote: On Tue, Dec 10, 2013 at 6:38 AM, Ryosuke Niwa rn...@apple.com wrote: On Dec 8, 2013, at 4:42 PM, Dominic Cooney domin...@google.com wrote: On Sun, Dec 8, 2013 at 7:25 PM, Ryosuke Niwa rn...@apple.com wrote: On Dec 7, 2013, at 4:38 PM, Dominic Cooney domin...@google.com wrote: On Fri, Dec 6, 2013 at 3:34 PM, Ryosuke Niwa rn...@apple.com wrote: On Dec 5, 2013, at 10:09 PM, Hajime Morrita morr...@google.com wrote: On inheritance around HTMLElement family, there seems to be a confusion between interface side inheritance and implementation side inheritance. Right. Differentiating the two is very important. For Custom Elements, the inheritance is not only about interface, but also about implementation. The implementation is more complex and flux in detail, thus worth being shared between different elements. Actually, the implementation of built-in HTML elements, which are usually done in C++, uses inheritance heavily, at least Blink and (I believe) WebKit. The reason we can use inheritance heavily is because we have control over both parent and child classes, and there are careful distinctions between public, protected, and private member functions and member variables in those classes. Unfortunately, custom elements can't easily inherit from these builtin HTML elements because builtin elements do not provide protected functions, and they don't expose necessary hooks to override internal member functions to modify behaviors. Built-in HTML elements have lots of hooks to modify their behaviour (for example, HTMLVideoElement's autoplay attribute.) The analogy is extending a Java class which has private and public final members, but no protected or public non-final ones. If someone were to make proposals about adding more hooks to the web platform to enable more subtyping use cases (for example, a protocol for participating in form submission) I would look forward to working with them on those proposals. The problem here is that until such hooks are well defined, inheriting from builtin elements doesn't make any sense. So let's not support that until such proposal is made and implemented. 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. If the only use case was to add new JavaScript property, then we wouldn't need custom elements at all. Authors could already do this by simply adding properties on builtin elements. If you do this on the Interface Prototype Object of a built-in element, the API will appear on all elements of that type. So that is not a feasible solution for many use cases. If you try to do this on a per-instance basis, that means you have to track instances. As I pointed out here: http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0893.html that is very difficult for the author to do correctly. Custom Elements puts the responsibility for this in the UA which has full knowledge of when elements are being created. But one of Google representatives stated that the current goal of web components, which we may not necessarily agree with, is to provide the minimum set of features for JS frameworks to build on top of it. If that were the goal, why are we bothering to add this API at all? In fact, why do we even bother to add any new API at all for web components if our primary target was framework authors. Ember.js, Angular JS, etc... all work great already because they add an abstraction layer on top of DOM. As currently argued by many representatives of Google, we'll be adding a bunch of APIs for frameworks to define declarative syntax, etc... each of which may or may not be interoperable with one another thereby making it impossible for us to later introduce one unified API. If that were true, then web components specifications don't satisfy the previously claimed goal of letting multiple frameworks and libraries to co-exist at all. Recall that [t]he WebApps Working Group is chartered to develop specifications for webapps, including standard APIs for client-side development, and a packaging format for installable webapps. This work will include both documenting existing APIs such as XMLHttpRequest and developing new APIs in order to enable richer web applications. We have a serious problem with the goal itself if the primary goal of web components features were to satisfy needs and use cases of JS
Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
On Dec 9, 2013, at 8:45 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Dec 10, 2013 at 3:33 PM, Ryosuke Niwa rn...@apple.com wrote: In fact, why do we even bother to add any new API at all for web components if our primary target was framework authors. Ember.js, Angular JS, etc... all work great already because they add an abstraction layer on top of DOM. As currently argued by many representatives of Google, we'll be adding a bunch of APIs for frameworks to define declarative syntax, etc... each of which may or may not be interoperable with one another thereby making it impossible for us to later introduce one unified API. If that were true, then web components specifications don't satisfy the previously claimed goal of letting multiple frameworks and libraries to co-exist at all. Responding to an I don't think we need to add that much sugar right now opinion with a Well then why bother adding any sugar at all?!? is never helpful. This is not an all-or-nothing thing, it's a search for the right level of sugaring to bake into the browser. And I'm claiming that the right level of sugaring should be decided based on needs of authors, not just of framework authors. - R. Niwa
Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
On Dec 7, 2013, at 4:38 PM, Dominic Cooney domin...@google.com wrote: On Fri, Dec 6, 2013 at 3:34 PM, Ryosuke Niwa rn...@apple.com wrote: On Dec 5, 2013, at 10:09 PM, Hajime Morrita morr...@google.com wrote: On inheritance around HTMLElement family, there seems to be a confusion between interface side inheritance and implementation side inheritance. Right. Differentiating the two is very important. For Custom Elements, the inheritance is not only about interface, but also about implementation. The implementation is more complex and flux in detail, thus worth being shared between different elements. Actually, the implementation of built-in HTML elements, which are usually done in C++, uses inheritance heavily, at least Blink and (I believe) WebKit. The reason we can use inheritance heavily is because we have control over both parent and child classes, and there are careful distinctions between public, protected, and private member functions and member variables in those classes. Unfortunately, custom elements can't easily inherit from these builtin HTML elements because builtin elements do not provide protected functions, and they don't expose necessary hooks to override internal member functions to modify behaviors. Built-in HTML elements have lots of hooks to modify their behaviour (for example, HTMLVideoElement's autoplay attribute.) The analogy is extending a Java class which has private and public final members, but no protected or public non-final ones. If someone were to make proposals about adding more hooks to the web platform to enable more subtyping use cases (for example, a protocol for participating in form submission) I would look forward to working with them on those proposals. The problem here is that until such hooks are well defined, inheriting from builtin elements doesn't make any sense. So let's not support that until such proposal is made and implemented. In addition, consider how inheriting views work in AppKit, UIKit, .net and MFC. When a view T inherits from another view S, T doesn't simply put S into a subregion of T; S intrudes into T's view and modifies what's been displayed or places extra content after or before T draws itself. I have a hard time understanding how this bizarre mixture of inheritance and composition is considered as the minimal subset of features while adding one optional argument to document.register to eliminate the most common boilerplate is considered as building a framework and bundling orthogonal features. Where did use cases and developer ergonomics go? - R. Niwa
RE: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
± If someone were to make proposals about adding more hooks to the web ± platform to enable more subtyping use cases (for example, a protocol for ± participating in form submission) I would look forward to working with them ± on those proposals. ± ± I am very interested in such proposals and I think others are as well. We run ± into the usual time-budget issues, but if we can find someone who is willing ± to champion a particular cause (like form submission) I would be very willing ± to help that champion work through designs and shepherd them through the ± process. ± ± CC'ing public-nextweb as this is the sort of stuff we love over there. There's definitely something we should do about that. That being said, things have to be prioritized and I'm not sure overloading the FORM tag's behavior is absolutely necessary right now. Indeed, inheritage can always be emulated in ECMAScript using some Object.setPrototypeOf(...) magic and composition. It is very likely that [[ creating some x-form element ]] + [[ adding some real form element into its shadow dom ]] + [[ forwarding all events/method calls back forth from the shadow to the main dom tree ]] + [[ hooking onsubmit to perform some pre-submit processing, to map non-input elements in the main tree into real input elements in the shadow tree ]] would to the trick to cover a large majority of the use cases. This is somewhat cumbersome but that would work, and doesn't seem to be an unsurmountable amount of work. Meanwhile, there are other problems in the platform that still lack any proper solution. That being said, I'm open to review any proposal in that space, it is great to see the discussion rolling! My two cents would be that we could add some @@InputElement symbol that, when present on a tag, make it participate to the form submission process (aka, we use its name and value properties to add it to the request body). Best regards, François
Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
On Sun, Dec 8, 2013 at 7:25 PM, Ryosuke Niwa rn...@apple.com wrote: On Dec 7, 2013, at 4:38 PM, Dominic Cooney domin...@google.com wrote: On Fri, Dec 6, 2013 at 3:34 PM, Ryosuke Niwa rn...@apple.com wrote: On Dec 5, 2013, at 10:09 PM, Hajime Morrita morr...@google.com wrote: On inheritance around HTMLElement family, there seems to be a confusion between interface side inheritance and implementation side inheritance. Right. Differentiating the two is very important. For Custom Elements, the inheritance is not only about interface, but also about implementation. The implementation is more complex and flux in detail, thus worth being shared between different elements. Actually, the implementation of built-in HTML elements, which are usually done in C++, uses inheritance heavily, at least Blink and (I believe) WebKit. The reason we can use inheritance heavily is because we have control over both parent and child classes, and there are careful distinctions between public, protected, and private member functions and member variables in those classes. Unfortunately, custom elements can't easily inherit from these builtin HTML elements because builtin elements do not provide protected functions, and they don't expose necessary hooks to override internal member functions to modify behaviors. Built-in HTML elements have lots of hooks to modify their behaviour (for example, HTMLVideoElement's autoplay attribute.) The analogy is extending a Java class which has private and public final members, but no protected or public non-final ones. If someone were to make proposals about adding more hooks to the web platform to enable more subtyping use cases (for example, a protocol for participating in form submission) I would look forward to working with them on those proposals. http://goto.google.com/dc-email-sla The problem here is that until such hooks are well defined, inheriting from builtin elements doesn't make any sense. So let's not support that until such proposal is made and implemented. 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. In mentioning hooks, was merely observing that we could define more hooks to enable even more use cases. In addition, consider how inheriting views work in AppKit, UIKit, .net and MFC. When a view T inherits from another view S, T doesn't simply put S into a subregion of T; S intrudes into T's view and modifies what's been displayed or places extra content after or before T draws itself. I can not discern a specific point you are making here. You are drawing an analogy to various UI frameworks but you have not completed the analogy. I think if you completed the analogy it would end up being a claim about Shadow DOM. You may have confused extending an element and having Shadow DOM. As Rafael Weinstein points out here: http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0883.html, whether an element has Shadow DOM is orthogonal to whether it is a Custom Element or not. I also disagree with your implied argument about Shadow DOM. I have a hard time understanding how this bizarre mixture of inheritance and composition is considered as the minimal subset of features while adding one optional argument to document.register to eliminate the most common boilerplate is considered as building a framework and bundling orthogonal features. Where did use cases and developer ergonomics go? The use cases were discussed on this list in 2010. As for ergonomics, this is subjective, but I spent a day last week building a Polymer app and the ergonomics were splendid. I have played with X-Tags in the past and they're great too. Dominic
Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
On Fri, Dec 6, 2013 at 3:34 PM, Ryosuke Niwa rn...@apple.com wrote: On Dec 5, 2013, at 10:09 PM, Hajime Morrita morr...@google.com wrote: On inheritance around HTMLElement family, there seems to be a confusion between interface side inheritance and implementation side inheritance. Right. Differentiating the two is very important. For Custom Elements, the inheritance is not only about interface, but also about implementation. The implementation is more complex and flux in detail, thus worth being shared between different elements. Actually, the implementation of built-in HTML elements, which are usually done in C++, uses inheritance heavily, at least Blink and (I believe) WebKit. The reason we can use inheritance heavily is because we have control over both parent and child classes, and there are careful distinctions between public, protected, and private member functions and member variables in those classes. Unfortunately, custom elements can't easily inherit from these builtin HTML elements because builtin elements do not provide protected functions, and they don't expose necessary hooks to override internal member functions to modify behaviors. Built-in HTML elements have lots of hooks to modify their behaviour (for example, HTMLVideoElement's autoplay attribute.) The analogy is extending a Java class which has private and public final members, but no protected or public non-final ones. If someone were to make proposals about adding more hooks to the web platform to enable more subtyping use cases (for example, a protocol for participating in form submission) I would look forward to working with them on those proposals. Evidently, in the current Custom Elements specification, the interface is inherited but the implementation (DOM) is composed via shadow element. There is a lot more to the implementation of an element than what is in its Shadow DOM. By analogy, Blink has lots of C++ code implementing built-in elements and relatively few of them have Shadow DOM. It is also incorrect to think all elements have Shadow DOM. In fact, we've come to a conclusion that shadow element is an unnecessary complexity because composition is the preferred mechanism to build complex objects on the Web, and if someone is using inheritance, then the subclass should have access to the shadow DOM of the superclass directly instead of it being magically projected into the shadow element. In fact, this is how inheritance works in other GUI frameworks such as Cocoa, .net, etc… Additionally, we don't have something like shadow element inside Blink or WebKit for our builtin elements. If our goal is to explain and describe the existing features on the Web platform, then we sure shouldn't be introducing this magical mechanism. If we had a subclass that truly wanted to contain its superclass in some non-trivial fashion, then we should be using composition instead. If the container class needed to forward some method calls and property accesses to the contained element, then it should just do. And providing a convenient mechanism to forward method calls and property access in JavaScript is an orthogonal problem we should be solving anyway. - R. Niwa -- http://goto.google.com/dc-email-sla
RE: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
From: Dominic Cooney [mailto:domin...@google.com] If someone were to make proposals about adding more hooks to the web platform to enable more subtyping use cases (for example, a protocol for participating in form submission) I would look forward to working with them on those proposals. I am very interested in such proposals and I think others are as well. We run into the usual time-budget issues, but if we can find someone who is willing to champion a particular cause (like form submission) I would be very willing to help that champion work through designs and shepherd them through the process. CC'ing public-nextweb as this is the sort of stuff we love over there.
[webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
On Nov 11, 2013, at 4:12 PM, Dimitri Glazkov dglaz...@chromium.org wrote: 3) The approach pollutes global name space with constructors. This had been voiced many times as unacceptable by developers. 4) How does build a custom element that uses name-card as its base element? What about div or any other HTML element? The last one remains to be the hardest. The tortured inheritance support is what killed element in the first place. We can't ignore the inheritance, since it is clearly present, in both DOM and JS. If we attempt to punt on supporting it, our decisions cut off the opportunities to evolve this right in the future, and will likely leave us with boogers like multiple syntaxes for inheritance vs. non-inheritance use cases. What exactly are you referring to by inheritance support? Inheritance from all builtin elements (e.g. subclasses of HTMLElement)? Or inheritance from custom elements authors have defined? And could you give us a pointer for a list of concrete use cases? - R. Niwa
Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
On Thu, Dec 5, 2013 at 7:55 PM, Ryosuke Niwa rn...@apple.com wrote: On Nov 11, 2013, at 4:12 PM, Dimitri Glazkov dglaz...@chromium.org wrote: 3) The approach pollutes global name space with constructors. This had been voiced many times as unacceptable by developers. 4) How does build a custom element that uses name-card as its base element? What about div or any other HTML element? The last one remains to be the hardest. The tortured inheritance support is what killed element in the first place. We can't ignore the inheritance, since it is clearly present, in both DOM and JS. If we attempt to punt on supporting it, our decisions cut off the opportunities to evolve this right in the future, and will likely leave us with boogers like multiple syntaxes for inheritance vs. non-inheritance use cases. What exactly are you referring to by inheritance support? Inheritance from all builtin elements (e.g. subclasses of HTMLElement)? Or inheritance from custom elements authors have defined? Sure, both are fine. Why should we treat them differently? And could you give us a pointer for a list of concrete use cases? Look at any mature Web framework. They all have hierarchies of objects: http://docs.sencha.com/extjs/4.2.2/#!/api http://quickui.org/catalog/ The latter is undergoing a complete rewrite to be custom element-based, so you might find it useful to study: https://github.com/JanMiksovsky/quetzal If the atomic unit of your framework is a DOM element, then DOM elements must support being extended via inheritance. Jan Miksovsky (cc'd) is a good person to talk about inheritance properties of custom elements. :DG
Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
Thanks. On Dec 5, 2013, at 8:30 PM, Dimitri Glazkov dglaz...@chromium.org wrote: On Thu, Dec 5, 2013 at 7:55 PM, Ryosuke Niwa rn...@apple.com wrote: On Nov 11, 2013, at 4:12 PM, Dimitri Glazkov dglaz...@chromium.org wrote: 3) The approach pollutes global name space with constructors. This had been voiced many times as unacceptable by developers. 4) How does build a custom element that uses name-card as its base element? What about div or any other HTML element? The last one remains to be the hardest. The tortured inheritance support is what killed element in the first place. We can't ignore the inheritance, since it is clearly present, in both DOM and JS. If we attempt to punt on supporting it, our decisions cut off the opportunities to evolve this right in the future, and will likely leave us with boogers like multiple syntaxes for inheritance vs. non-inheritance use cases. What exactly are you referring to by inheritance support? Inheritance from all builtin elements (e.g. subclasses of HTMLElement)? Or inheritance from custom elements authors have defined? Sure, both are fine. Why should we treat them differently? For the following reasons to list a few: We don't have any subclass of HTMLElement that can be instantiated and has subclasses. Author scripts can't access internal states of builtin elements; e.g. dirtiness of values in HTMLInputElement. Methods and properties of builtin elements are not designed to be overridden by subclasses. Behaviors of builtin elements will be changed by UAs in the future without author-defined subclasses being upgraded accordingly, thereby violating Liskov substitution principle. And could you give us a pointer for a list of concrete use cases? Look at any mature Web framework. They all have hierarchies of objects: http://docs.sencha.com/extjs/4.2.2/#!/api http://quickui.org/catalog/ It seems like both of these libraries only support inheritance from their own elements, not form builtin elements. The latter is undergoing a complete rewrite to be custom element-based, so you might find it useful to study: https://github.com/JanMiksovsky/quetzal If the atomic unit of your framework is a DOM element, then DOM elements must support being extended via inheritance. Jan Miksovsky (cc'd) is a good person to talk about inheritance properties of custom elements. Great. - R. Niwa
Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
On Thu, Dec 5, 2013 at 8:50 PM, Ryosuke Niwa rn...@apple.com wrote: Thanks. On Dec 5, 2013, at 8:30 PM, Dimitri Glazkov dglaz...@chromium.org wrote: On Thu, Dec 5, 2013 at 7:55 PM, Ryosuke Niwa rn...@apple.com wrote: On Nov 11, 2013, at 4:12 PM, Dimitri Glazkov dglaz...@chromium.org wrote: 3) The approach pollutes global name space with constructors. This had been voiced many times as unacceptable by developers. 4) How does build a custom element that uses name-card as its base element? What about div or any other HTML element? The last one remains to be the hardest. The tortured inheritance support is what killed element in the first place. We can't ignore the inheritance, since it is clearly present, in both DOM and JS. If we attempt to punt on supporting it, our decisions cut off the opportunities to evolve this right in the future, and will likely leave us with boogers like multiple syntaxes for inheritance vs. non-inheritance use cases. What exactly are you referring to by inheritance support? Inheritance from all builtin elements (e.g. subclasses of HTMLElement)? Or inheritance from custom elements authors have defined? Sure, both are fine. Why should we treat them differently? For the following reasons to list a few: 1. We don't have any subclass of HTMLElement that can be instantiated and has subclasses. Not sure why this matters? 1. Author scripts can't access internal states of builtin elements; e.g. dirtiness of values in HTMLInputElement. Again, not sure why this matters either. 1. Methods and properties of builtin elements are not designed to be overridden by subclasses. Okay, that seems like an implementation detail of HTML. Again, doesn't preclude seeking consistency between inheritance from custom elements or HTML elements. 1. Behaviors of builtin elements will be changed by UAs in the future without author-defined subclasses being upgraded accordingly, thereby violating Liskov substitution principle. Sure, it's probably a bad idea to inherit from any HTML element (other than HTMElement). The Custom Elements spec is deeply steeped in the idea that we bring new functionality by explaining how the platform works (see http://extensiblewebmanifesto.org/). If we just side-load some new platform magic to accommodate a few specific use cases, we're not doing the right thing. :DG
Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
On inheritance around HTMLElement family, there seems to be a confusion between interface side inheritance and implementation side inheritance. In WebIDL, interfaces of HTML elements have inherited only from HTMLElement interface. This is fine just because it cares only about interface (API signature) but not about implementation. Even though there are some duplication on API surface of these elements, we can live with it as it is relatively stable and we have other reuse mechanisms like partial interface. For Custom Elements, the inheritance is not only about interface, but also about implementation. The implementation is more complex and flux in detail, thus worth being shared between different elements. Actually, the implementation of built-in HTML elements, which are usually done in C++, uses inheritance heavily, at least Blink and (I believe) WebKit. On Fri, Dec 6, 2013 at 2:53 PM, Ryosuke Niwa rn...@apple.com wrote: On Dec 5, 2013, at 9:30 PM, Dimitri Glazkov dglaz...@chromium.org wrote: On Thu, Dec 5, 2013 at 8:50 PM, Ryosuke Niwa rn...@apple.com wrote: On Dec 5, 2013, at 8:30 PM, Dimitri Glazkov dglaz...@chromium.org wrote: On Thu, Dec 5, 2013 at 7:55 PM, Ryosuke Niwa rn...@apple.com wrote: On Nov 11, 2013, at 4:12 PM, Dimitri Glazkov dglaz...@chromium.org wrote: 3) The approach pollutes global name space with constructors. This had been voiced many times as unacceptable by developers. 4) How does build a custom element that uses name-card as its base element? What about div or any other HTML element? The last one remains to be the hardest. The tortured inheritance support is what killed element in the first place. We can't ignore the inheritance, since it is clearly present, in both DOM and JS. If we attempt to punt on supporting it, our decisions cut off the opportunities to evolve this right in the future, and will likely leave us with boogers like multiple syntaxes for inheritance vs. non-inheritance use cases. What exactly are you referring to by inheritance support? Inheritance from all builtin elements (e.g. subclasses of HTMLElement)? Or inheritance from custom elements authors have defined? Sure, both are fine. Why should we treat them differently? For the following reasons to list a few: 1. We don't have any subclass of HTMLElement that can be instantiated and has subclasses. Not sure why this matters? It means that inheritance is NOT integral part of the platform; at least for builtin elements. 1. Methods and properties of builtin elements are not designed to be overridden by subclasses. Okay, that seems like an implementation detail of HTML. Again, doesn't preclude seeking consistency between inheritance from custom elements or HTML elements. That's not an implementation detail. The key observation is that HTML elements aren't designed to be subclassed. 1. Behaviors of builtin elements will be changed by UAs in the future without author-defined subclasses being upgraded accordingly, thereby violating Liskov substitution principle. Sure, it's probably a bad idea to inherit from any HTML element (other than HTMElement). Great, then let's not support that. The Custom Elements spec is deeply steeped in the idea that we bring new functionality by explaining how the platform works (see http://extensiblewebmanifesto.org/). If we just side-load some new platform magic to accommodate a few specific use cases, we're not doing the right thing. Without getting into a philosophical debate, supporting inheritance from subclasses of HTML elements doesn't explain how the Web platform works at all so let's not add that. If we removed this, we don't have to worry about attaching shadow DOM to builtin elements (other than HTMLElement itself) for custom elements. - R. Niwa -- morrita
Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
On Dec 5, 2013, at 10:09 PM, Hajime Morrita morr...@google.com wrote: On inheritance around HTMLElement family, there seems to be a confusion between interface side inheritance and implementation side inheritance. Right. Differentiating the two is very important. For Custom Elements, the inheritance is not only about interface, but also about implementation. The implementation is more complex and flux in detail, thus worth being shared between different elements. Actually, the implementation of built-in HTML elements, which are usually done in C++, uses inheritance heavily, at least Blink and (I believe) WebKit. The reason we can use inheritance heavily is because we have control over both parent and child classes, and there are careful distinctions between public, protected, and private member functions and member variables in those classes. Unfortunately, custom elements can't easily inherit from these builtin HTML elements because builtin elements do not provide protected functions, and they don't expose necessary hooks to override internal member functions to modify behaviors. Evidently, in the current Custom Elements specification, the interface is inherited but the implementation (DOM) is composed via shadow element. In fact, we've come to a conclusion that shadow element is an unnecessary complexity because composition is the preferred mechanism to build complex objects on the Web, and if someone is using inheritance, then the subclass should have access to the shadow DOM of the superclass directly instead of it being magically projected into the shadow element. In fact, this is how inheritance works in other GUI frameworks such as Cocoa, .net, etc… Additionally, we don't have something like shadow element inside Blink or WebKit for our builtin elements. If our goal is to explain and describe the existing features on the Web platform, then we sure shouldn't be introducing this magical mechanism. If we had a subclass that truly wanted to contain its superclass in some non-trivial fashion, then we should be using composition instead. If the container class needed to forward some method calls and property accesses to the contained element, then it should just do. And providing a convenient mechanism to forward method calls and property access in JavaScript is an orthogonal problem we should be solving anyway. - R. Niwa
Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
I agree that it isn't trivial to inherit from a built-in element as if it is an author-defined element. My point was that mentioning relationship between HTMLElement and built-in elements on WebIDL doesn't matter in this discussion and we should focus on other reasoning. On Fri, Dec 6, 2013 at 3:34 PM, Ryosuke Niwa rn...@apple.com wrote: On Dec 5, 2013, at 10:09 PM, Hajime Morrita morr...@google.com wrote: On inheritance around HTMLElement family, there seems to be a confusion between interface side inheritance and implementation side inheritance. Right. Differentiating the two is very important. For Custom Elements, the inheritance is not only about interface, but also about implementation. The implementation is more complex and flux in detail, thus worth being shared between different elements. Actually, the implementation of built-in HTML elements, which are usually done in C++, uses inheritance heavily, at least Blink and (I believe) WebKit. The reason we can use inheritance heavily is because we have control over both parent and child classes, and there are careful distinctions between public, protected, and private member functions and member variables in those classes. Unfortunately, custom elements can't easily inherit from these builtin HTML elements because builtin elements do not provide protected functions, and they don't expose necessary hooks to override internal member functions to modify behaviors. Evidently, in the current Custom Elements specification, the interface is inherited but the implementation (DOM) is composed via shadow element. In fact, we've come to a conclusion that shadow element is an unnecessary complexity because composition is the preferred mechanism to build complex objects on the Web, and if someone is using inheritance, then the subclass should have access to the shadow DOM of the superclass directly instead of it being magically projected into the shadow element. In fact, this is how inheritance works in other GUI frameworks such as Cocoa, .net, etc… Additionally, we don't have something like shadow element inside Blink or WebKit for our builtin elements. If our goal is to explain and describe the existing features on the Web platform, then we sure shouldn't be introducing this magical mechanism. If we had a subclass that truly wanted to contain its superclass in some non-trivial fashion, then we should be using composition instead. If the container class needed to forward some method calls and property accesses to the contained element, then it should just do. And providing a convenient mechanism to forward method calls and property access in JavaScript is an orthogonal problem we should be solving anyway. - R. Niwa -- morrita
