We should probably not expose the native minlength property, as Safari 10.0 doesn’t natively produce validation errors for that. We should instead encourage users to use pattern instead.

This has been fixed already in Safari Technology Preview.

Related: maxlength works in Safari 10.0 also, it prevents the user from inputting more characters.

Also, it seems that minlength and maxlength are only evaluated for user input, and they don’t affect the validation unless the user has touched modified the input. The pattern property, on the other hand, is validated already when the element is loaded/rendered.

Currently, the invalid state isn't visible in any way in the non-styled examples.

• Have the form-layout position and resize the label of the text-field

<label>
  <vaadin-input></vaadin-input>
</label>

<label>
  <input>
</label>

Linux/Chrome

Probably related to #5

Add mixin from: vaadin/vaadin-themes#4

As an opt-in feature (or opt-out, can be discussed), provide a built-in suffix element which, when clicked/tapped, sets the value of the field to an empty string.

The element should be an “X” icon and be shown before any other suffix elements (closest to the value).

Question: When the field is marked as required, should the clear button always be hidden?

For reference: https://www.w3.org/TR/wai-aria-1.1/#textbox

Proposal: should support announcing label by the screenreader, also should announce states like disabled, readonly, invalid and required (and error message).

Also the value should be announced :doh:. And should announce that the user is in a textbox.

All the announcements should work out of the box without requiring the users to add any aria attributes themselves. aria-label can of course be used to override the default announcement.

Should be tested on VoiceOver (OSX + iOS), ChromeVox, JAWS and NVDA on Windows 10, Android TalkBack

If the initial value is not set, the value property is currently undefined.

Expected default value: empty string.

Script is working for 20 seconds and then "Unresponsive script" alert is shown in Firefox/Linux:

See the screenshot: https://github.com/vaadin/vaadin-input/blob/master/test/visual/screens/vaadin-input/theming-tests/screenshots/edge.png

Introduced in 2298486

• Include in the visual test "styling" suite
• Add to apidocs

When the error-message is hidden it still has margins.

• Add .gemini.yml
• Add Travis test step
• Add npm deps
• Add reference pics for different states (focused, hovered, invalid, etc.) to repository
• Add configuration files also to skeleton project

If you use tab to move focus from a <vaadin-text-field> to another, the first time it works as expected. Shift+tab back to the first field and hit tab again to focus the second field again and the focus gets lost.

Occurs on FF

It's unclear for users what's happening to text-field when it contains invalid value.

(This is the DX tests finding)

Some users prefer function-way instead of setting errorMessage property directly.

(This is the DX tests finding)

Specs by @jouni

It should be possible to provide an error message for the text-field, which gets announced by the screen reader, for example in the case of a validation error.

The error message should only be displayed when the text field is invalid.

API proposal:

<vaadin-text-field error-message="This field is required" label="Name" required></vaadin-text-field>

Implementation details

Expose the error message as a new themable part, e.g.

# shadow root
  ...
  <div class="error" part="error-message">[[errorMessage]]</div>
  ...

The error message should be displayed under the field by default. No extra styling is needed (colors or anything else).

On Edge, if you write something in the input and then click another vaadin-input, the focus gets transferred only on the second click.

• Label position should be definable by CSS
  • separate positions can be defined for states: input empty/non-empty, focused
• Default position for the label is on top of the field (like always-float-label on <paper-input>
• Consider support for form-layout

Attributes such as focused, focus-ring, disabled, invalid are available on the host element for styling, but not listed in the API docs as of now.

API documentation should list all of the attributes available for styling.

(This is the DX tests finding)

Plan, conduct and report

• Start with LightHouse
• Use either --perf flag our custom config file to run only the performance tests
• Run a control test first to figure out the performance of the environment
• Use a hard-coded threshold score value for now
• Only local Chrome in Travis

See Manolos prototype for inspiration: https://github.com/vaadin/vaadin-context-menu/compare/proto/perf-tests

As the native <input> element has the type attribute, which can make the element behave completely differently from a text input (such as "checkbox" and "range"), and since we have TextField and TextArea components in the Vaadin Framework currently, I think it would be better if we changed the name of this element. Then, it is more natural to create a <vaadin-text-area> element for multi-line text.

This would also make comparisons to paper-input less obvious.

Currently, after opening the page, the autofocus example makes it scroll away from the top. This obscures first few examples on the page.

(This is the DX tests finding)

• Drop the label-and-input-container so that the content-wrapper ends up with only prefix, input and suffix.
• Replace label-placeholder with the actual label
• Consider dropping the outer container wrapper

It's hard for users because there's nothing what indicates about invalid field by default.

(This is the DX tests finding)

The demo pages are not rendered.

Console has an error:

Unable to get property 'cssText' of undefined or null reference: webcomponents-lite.js (5,42707)

This is not obvious and should be explicitly stated in the docs.

(This is the DX tests finding)

Use cases:

• applies only to sync validation
• opt-in feature to prevent user from typing values that would be invalid
• should of course work with custom validators also
• iron-input has a corresponding property called prevent-invalid-input

Place 2 <vaadin-text-field>s next to each other. Use (shift+)tab to move focus between them. After the first round, it will require 2 tabs to move the focus to the second field. This happens only on Shady DOM.

Related to #6

All tests should pass in IE11

• Main purpose is to document using the all "parts" for theming.
• List all the parts in the API docs (vs. the old CSS mixins)
• Let's use Bootstrap as inspiration for visual end result
• Add also visual regression testing to make sure each "part" works

Related to #6

There are examples on the demos page, but nothing useful on the docs page.

(This is the DX tests finding)

In material design demo, the floating label jumps immediately. Happens in desktop Safari 10.0.

Fix suggestion: use -webkit-transition in theme CSS.

Adding/removing icons to prefix/suffix slots makes the element layout change.

That is an issue when adding mobile friendly clear/toggle buttons in other elements like vaadin-combo-box. Otherwise setting a height in other elements needs to define a theme block and repeat all theme-default properties.

Here a screenshot with the problem and possible solution

http://g.recordit.co/nDrZJnpxqv.gif

Use Cases to cover:

• allow adding icons/buttons inside the focusable area (think of combo-box)
• consider disabling "floating label" when prefix is defined

Definition of Done: add examples how to extend the VaadinTextFieldElement to provide:

• synchronous custom validation
• asynchronous custom validation

After #45 is completed, remove mixins and fix Material design demo using the new style module injection.

• Move the material design theming demo to vaadin-themes, just add a page with a material design themed vaadin-text-field
• Add visual regression tests
• Make sure nightly builds are run to prevent visual regressions

Currently, when prevent-invalid-input in enabled and user tries, for example, to type letters in a numbers-only field, nothing happens.

UX is poor, we should somehow indicate that input was prevented. Without the indication, the user thinks that his keyboard is broken or there's some virus in his lovely Android phone.

Indication by default could be red border (shadow-box) blink for a short moment right after typing.

(This is the DX tests finding)

(This is the DX tests finding)

Definition of Done:

• Add the possibility to theme the input (MVP should support material design look without the floating label thing)
• Design a "default" look for input, styles included inside the element
• By default it should look like a native input