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

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

From: Dominic Cooney <dominicc@google.com>
Date: Sun, 15 Dec 2013 23:25:23 +0900
Message-ID: <CAHnmYQ8W6LEyb8LzMkw_FhxC7+xV7Frg46uG4ShUiOsxn3borQ@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.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 Fri, Dec 13, 2013 at 5:59 PM, Maciej Stachowiak <mjs@apple.com> wrote:

> 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 think subtypes of HTMLInputElement with Shadow DOM can participate in
form submission by stuffing the value to submit into the "base" input
element by setting value.

> 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.

You are correct; a Custom Element could not implement HTMLInputElement
without heavily relying on the built-in HTMLInputElement. Participating in
a limited way by setting HTMLInputElement.value will work, but providing
hooks into the form submission process would enable more use cases.

> 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 HTMLInputElement is poorly designed; it effectively changes its
type in response to changes in the type attribute. So marrying anything
"classy" onto that will get messy.

If there was a protocol for participating in form submission, new form
input types could have different tags, just as SELECT is distinct from

> 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.

I agree.
Received on Sunday, 15 December 2013 14:25:50 UTC

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