Create inputter component

[jholt1]

Outcome

To create a wrapper component to display the following form control types:

Scope

Elements and types

• text
• email
• tel
• search
• password
• date
• number
• textarea
• checkbox
• radio
• select

Properties

• Type
• Value
• Validation
• Helper
• LabelID *
• Mask
• Separator
• IgnoreSeparator
• DisableNativeValidation *
• DisableEventBubbling *
• ShowError *
• OpenHelper
• Heading

Slot

• Input / Label
• Tip Details

Tokens

• Type
• Has-Mask*
• Has-Helper *
• Has-Separator *

Note*: Above tokens enable/disable mask, separator & helper functionality (if the design system decides to use them or not).

• Inputter - Add token support to enable/disable mask, separator and helper features #191

States (active/focus/disabled/hover) #185

• Color
• Background
• Outline
• Border

Events

• Change (value)
• Blur
• Helper-Toggle

Addon Features

• Input Validation
• Input Trimmer
• Input Separator
• Input-Single
• Input-Multiple

Mixin

• Form Element Mixin #65
• Validation Mixin #68

Child Components

• Helper (Detail Create details component #24 )
• Validation-Message

Parent Class

• Form-Element (Type, Value)
• Validation

[RobTobias123]

Discovery work... initial text input states created in Sketch. Rationale and a query on the disabled state's label appearance below...

Typography


Labels and input share the same font size and weight for simplicity and without implying importance so that it contrasts with buttons.





Input field




Simple rectangle with 2 px #333333 inner border. Square corners help distinguish it from the secondary buttons that could appear in close proximity.









Active state






By default will appear without data. 
Data is shown here just to demonstrate size and location.













Focus state








On click, there should be a blinking cursor
 to indicate that text can be input. The border changes to #000000 and thickens from 2px to 3px and is outlined with Muon purple 3px.

















Disabled state question:










The disabled input field and text should appear ‘greyed-out' in a similar way to disabled buttons, (so exempt from contrast ratio requirements).











But should its label also appear
 disabled (ie. grey in this case) when the input 
field is disabled?

As it is part of the component and the component is disabled maybe it should be?

But, I think it could be better if the Label was still of good visual contrast for a11y? People still need to understand what is disabled, don't they? The label itself still has a purpose and is not in itself redundant? (It also appears to be the more commonly used pattern.)















[RobTobias123]

I noticed 'Hover' mentioned in the states, but input fields do not usually have a hover state?

[andij]

The hover state will be relevant for the checkbox and radio and other input types.

It may be a good idea to list all the different input types we are planning on making available.

Here's the MDN page on <input>: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input

[RobTobias123]

Placeholder text can be displayed in an empty text field until input is entered. Cursor has been moved to left slightly to the 16px from edge so as not to interfere visually. Placehodler text is #666666 - lighter than standard (#333333 or #000000 on focus) - to give visual difference whilst still high enough to meet a11y.

[RobTobias123]

Helper text is 14px so visually smaller than the Label and Input (16px) and so able to contain more words in the same space - typically a description is longer than the label.

[RobTobias123]

Validation



An error message is preceded by a warning icon (font awesome) to make the error state more distinct to colourblind users. The message also appears in Muon Purple for visual awareness which meets a11y contrast requirements.
It keeps Muon to a stripped-down colour pallette (greyscale shades and 1 colour) where the Muon Purple colour implies no specific meaning other than to highlight and distinguish from grey elements.

[RobTobias123]

Checkboxes

Here's the first iteration for a simple checkbox.

Colours

In general, checkboxes tend to use blue as the colour when selected. These designs use Muon purple instead. The hover state follows button style and uses black. The unchecked box uses #333333 1px border (due to size). This also means that the Focus state colour had to change to a 2px wide outline #CCCCCC grey (instead of Muon purple like the button) in order to contrast well especially at the smaller size, 1px border. This is not likely to cause any misunderstanding but happy to look further into options if it is a technical problem (ie. requiring just one focus state style globally).

Size

Size is currently 12px sq with rounded corners which is generally the native shape and size (although some systems use square corners). The optimal target area for touch screens should remain 42px sq regardless to keep it usable. (See CTA research/documentation for why).

Indeterminate state

I have included an indeterminate attribute state for where the value is neither true nor false but is there a requirement for this at all? MSDN say there are no browsers that currently support it?

Ref: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/checkbox

Labels

Examples with appended labels coming next.

[RobTobias123]

Checkboxes

Example of labels with check boxes (10px to right of checkbox), nesting and indeterminate example, and a focus on one of them to view in context. Labels are using 16px (1rem) Open Sans font.

[RobTobias123]

Radio buttons follow the same principles as the checkbox regarding colours and focus... The outer ring is 1px (#333333 by default) the space between the inside of that ring and the 'selected' circle is 1.5px (for clarity) making the circle 7px diameter. Selected state is Muon purple, hover is black (#000000) and Focus is a 2px outline #cccccc.

[RobTobias123]

If as I suspect, focus colour needs to be the same throughout for consistency there's a few options I've nw explored. The last being my preferred route but requires our team's input to decide...

[RobTobias123]

Updated versions of the checkboxes and and radio buttons to version 6 @ actual size - Style TBC...

[RobTobias123]

Following discovery work and iterations for states (see #2 (comment)) this is the latest proposed design for the text input field (single).

[RobTobias123]

and also the same applied to checkboxes and radio buttons...

[RobTobias123]

Input with icon + date scenario (calendar icon could be switched for search icon etc). default, focus, and active states. The text highlight is also shown over the dd. Based on behaviour as described on MDN:

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input

[RobTobias123]

Select variant of inputter. Uses a similar looking Input box and icon. Width determined by longest data.

Question: On click the drop down list could be the browser default? - This is how it is on Nuclues and the simplistic Government design systems that (correctly) obscure the initial view. Or did we need a custom version of this so that it can be customised by different brands?

[RobTobias123]

Textarea takes on similar behaviours to a single line text input but with expandable parameters.

[RobTobias123]

Select right to left variant (considering internationalisation).

[RobTobias123]

Example of alternative left-hand side position for input with an icon.

[RobTobias123]

Input field with helper text and tip showing focus on the interactive helper text. (Left to right reading direction).

[RobTobias123]

Right to left reading direction variant for helper text and tip layout... These examples may look better when written in a script that actually reads from right to left instead of in English. I'll look into it.

[andij]

This is looking good!

For reference, here's a great article on Right-to-left styling: https://rtlstyling.com/posts/rtl-styling

In some cases things are not switched over, depending on the context and content type.
For example, the date field you've provided a RTL version of, the calendar icon should not be switched to the left. But the chevron for the Select is correct and should move position.

[andij]

With reference to the Helper and Tooltip, I like to suggest that the triangle/chevron should be placed at the start of the Helper rather than at the end.

I mention this as the position of the triangle/chevron for a raw HTML details and summary element is to the start.

I'm aware that the variant tested better with the triangle/chevron at the end. We can of course respect this decision when it's used.

My rational for this is to keep it as close to HTML's default and most likely the majority expectations.

[RobTobias123]

Thanks for the insights Drew - I'll look into it and update accordingly. BTW - here's an example I put together just before reading your posts, showing the Helper text in a RTL language (Yiddish) for a more authentic visual...

[RobTobias123]

Monospace text example using 16px Courier font (available as system on most operating systems) with 6 Character spacing....

[RobTobias123]

Masked variant is Opens Sans (same as default text) for simplicity. Obviously showing ••• instead of letters, not using *** asterisks as they can imply meaning (like a connection to a caveat or a multiplication etc)

[RobTobias123]

Here's the separator idea - based on variant. We have monospaced separator dashes when 'naked' which stay in the same place as data is entered so user in this case would only need to enter '123456'. All other focus and hover states inherit the same styles as the normal text inputter...

[RobTobias123]

Updated date variant of the inutter to use 'solid' font awesome (same as everywhere else - don't use regular) and note that we shouldn't have a date variant with icon at start.

[RobTobias123]

I've researched the show/hide toggle variant a little further. Typically something like a password component will have a way to reveal the content as a toggle, but displayed as •••• by default. Looking at Google Material DS they utilise the eye/eye-slash icon at the end of the input field.

Interestingly they refer to it as the 'visibility' icon so the reverse meaning to how we use it as Show/Hide. This I think is down to interactive icons describing 'intent' rather than current status. Is it a question of direction that may need to be answered before it gets to the brand side of things?

However, whilst we already have an input field that can accommodate an icon (like Date above) the more raw HTML variant tends to be to use an associated checkbox below the field. (As this example seen on W3 schools...)

From experience though this could be problematic if used with validation messaging. This same issue was addressed in password where we moved the show/hide toggle to the top-right above the input field, but that's surely a brand level decision?

What are others thoughts on the subject?

(also @andij the fontawesome eye-slash required a bounding box that was a couple of pixels larger to fit the icon at the same font size - so another alignment to consider (others sat within the 24px sq but all aligned central).

[andij]

Hi Rob, it looks like there's confusion between the Mask and Show/Hide. (Above post corrected to 'Show/hide' - Rob)

The Mask acts in a similar way to a placeholder. It is used to help indicate the format of the expected value to be entered within a field. Unlike a placeholder, the characters within the Mask are always present unless they have been populated with a value.

For example here is a field with the attribute: mask="DD-MM-YYYY"

It works in conjunction with the separator, in the above example the attribute separator="-" is present. The user experience is one, where typing 10101980 results in 10-10-1980.

[RobTobias123]

Ok - I see. I still think the show/hide toggle question is a valid one. But, due to getting muddled over the naming -  I think it's safe to say this is out of scope for the inputter and should be transferred to a password component when and if created.

Thanks for clarifying.

[RobTobias123]

I've added the masked inputter to the sketch file using the monospace and visually describing the states from 'naked' placeholder and as someone would enter the data. Hope that helps.

*"The mask is similar to a placeholder, this can be used to show what can be entered. However it stays when values are entered."

[RobTobias123]

The input field could only be as long as it needs to be as defined by the placeholder/mono/mask or data input. Labels on above are just to demonstrate the example and do not dictate the usage which is neutral at this stage).

[MekalaNagarajan-Centrica]

Mask & Separator - #123

[andij]

Reopening this as it was automatically closed when PR #136 was merged.

[andij]

Notable browser variations to some input types

Here I have captured screenshots of a few types of inputs which display additional icons and behaviour.

Password

Edge - password hide

Edge - password show

Safari - password

Date

Firefox - date

Chrome - date

Edge - date

Safari - date

Number

Firefox - number

Chrome - date

Edge - date

Safari - date

Search

Firefox - search

Chrome - search

Edge - search

Safari - search

[andij]

Here I've added screenshots of the latest development to the Search, Date and Select input types on Firefox, Edge, Chrome and Safari on Mac.

There are quite a number of browser specific overrides to pseudo elements to achieve this. These changes are noted in comments within the global stylesheet for inputter type="date" and the component stylesheet for inputter select

I'd like to test these in Windows High Contrast, but my Windows machine is out of action at the moment.

Search

Firefox - search

Edge - search

Chrome - search

Safari - search

Date

Firefox - date

Edge - date

Chrome - date

Safari - date

Select

Firefox - select

Edge - select

Chrome - select

Safari - select

[MekalaNagarajan-Centrica]

• More tests for different input types and state / style changes (Add tests for styles validation #185 )

[andij]

Here are a few notes following the alpha release that I'd like to capture. These are either points for discussion or to raise as tickets.

• Introduce design tokens for size #190
• Discover the use of calc() in tokens Calculate values for tokens #201
• change token name choice to multiple #196
• Align token naming and styling of inputter-details and details #210
• Position of icon when text wraps over multiple lines Icon shrinks with long content #194 (comment)
• Icon shrinks with long content #194
• When should we style :host, or use parent element? #209
• fix: radio and checkbox vertical alignment #197

[andij]

Closing this as all outstanding items have their respective tickets created.