Add <vaadin-text-field-container>

[platosha]

Create <vaadin-text-field-container> element, which is a themable container for an <input> element provided by users in the light DOM.

Resolves vaadin/vaadin-text-field#38 and vaadin/vaadin-text-field#48.

Motivation

Exposing <input> for direct access gives accessibility benefits. <label> element bindings and attributes without any hacks/manual support from the <vaadin-text-field>.

Currently with <vaadin-text-field>, using <label> is problematic: it does not announce <label> as an accessible name when native Shadow DOM is used, because <label> is in the parent tree, while the focused <input> is in the shadow tree of <vaadin-text-field>:

<label>
  Foo
  <vaadin-text-field>
    ::shadow-root
    <input>
  </vaadin-text-field>
</label>

With <vaadin-text-field-container>, users can assign accessible labels with <label> element (#useThePlatform 👍):

<!-- <label> is in the same tree with <input>, works fine -->
<label>
  Foo
  <vaadin-text-field-container>
    <input>
  </vaadin-text-field-container>
</label>

<!-- using <label for="">, also works fine -->
<label for="myInput">Foo</label>
<vaadin-text-field-container>
  <input id="myInput">
</vaadin-text-field-container>

<!-- works for <vaadin-form-item> as well out-of-the-box -->
<vaadin-form-item>
  <label slot="label" for="fooInput">Foo</label>
  <vaadin-text-field-container>
    <input id="fooInput">
  </vaadin-text-field-container>
</vaadin-form-item>

Users can assign aria-label and other ARIA attributes on the input directly:

<!-- using aria-label on the input, works fine as well -->
<vaadin-text-field-container>
  <input aria-label="Foo">
</vaadin-text-field-container>

Users can use a custom input type and other native <input> attributes:

<vaadin-text-field-container><input type="password"></vaadin-text-field-container>

[jouni]

Style leaks are unavoidable with this approach, of course, so it’s no silver bullet it that sense. It is fine when you can wrap it inside another shadow tree (like we encapsulate paper input in vaadin-combo-box/date-picker), but using it inside the light dom of vaadin-form-layout seems more prone to unwanted style leaks.

[platosha]

@jouni style leaks are workaroundable. Naturally, themes need to define all appearance properties for <input>, as they need to override UA default styles anyway. If these theme styles are specific enough, they can override global styles as well.

For example, if a theme will use !important for slotted input styles, then non-important global styles won’t override it. Another option for users is to wrap the entire form contents (with vaadin-form-layout) in a shadow tree.

We can’t protect against !important in non-scoped global styles, but either shadow trees don’t protect with ShadyDOM polyfill.

Here are some quick JSbin demos.

• WIth shady DOM, local #input-slot-container ::slotted(input) is translated to #input-slot-container.my-input-container > input, which is very specific already, could be enough to override global styles even without !important: http://jsbin.com/buyirinogu/edit?html,css,output

• With shadow DOM, !important helps, and also global style overrides are possible: http://jsbin.com/yabejukuki/edit?html,css,output

[paales]

Reasons for the container:

• You can't use a native <form>, working with iron-form is a b*tch (pardon my language)
• Password managers break (lastpass, etc.)
• Autocomplete doesn't work: Address / credit card fields

[web-padawan]

@paales please keep in mind that password managers and autocomplete are expected to break anyways, when using any Web Component with shadow root for the whole app / single view inside of it.

What problems do you have regarding iron-form support for vaadin-text-field?

[jouni]

Slightly related (a more generic field wrapper element): vaadin/vaadin-core#150

[paales]

please keep in mind that password managers and autocomplete are expected to break

Not when you have the form in the same scope as the input field. It is not the issue that the autocomplete can't penetrate the shadow dom boundary, just that the values are set from the 'level' of the form and thus cant find the inputs. Autocomplete matters.

[web-padawan]

Closing in favor of #2185 where this will be partially handled. See also #84 for an epic with all related tickets.