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
