W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2013

Custom form elements (was Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax))

From: Maciej Stachowiak <mjs@apple.com>
Date: Fri, 13 Dec 2013 00:59:27 -0800
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>
Message-id: <6AA6CA2D-27B9-4A57-9344-37D9565A88A1@apple.com>
To: Dominic Cooney <dominicc@google.com>

On Dec 7, 2013, at 4:38 PM, Dominic Cooney <dominicc@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



Received on Friday, 13 December 2013 08:59:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:20 UTC