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

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


> 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.
<http://goto.google.com/dc-email-sla>