Add input prefix and suffix

[simonwhatley]

What

Adds prefix and suffix elements to the input component.

Why

A number of local and departmental design systems (GOV.UK Publishing Components, HMRC, MOJ and ONS) are using prefixes and suffixes to indicate currencies and measurements.

Examples

Prefix

HTML

<div class="govuk-form-group">
  <label class="govuk-label" for="input-with-prefix-attribute">
    Amount
  </label>
  <div class="govuk-input__wrapper">
    <span class="govuk-input__prefix" aria-hidden="true">£</span>
    <input class="govuk-input" id="input-with-prefix-attribute" name="amount" type="number">
  </div>
</div>

Macro

{% from "input/macro.njk" import govukInput %}

{{ govukInput({
  "label": {
    "text": "Amount"
  },
  "id": "input-with-prefix-attribute",
  "name": "amount",
  "type": "number",
  "prefix": {
    "text": "£"
  }
}) }}

Suffix

HTML

<div class="govuk-form-group">
  <label class="govuk-label" for="input-with-suffix-attribute">
    Weight
  </label>
  <div class="govuk-input__wrapper">
    <input class="govuk-input" id="input-with-suffix-attribute" name="weight" type="number">
    <span class="govuk-input__suffix" aria-hidden="true">kg</span>
  </div>
</div>

Macro

{% from "input/macro.njk" import govukInput %}

{{ govukInput({
  "label": {
    "text": "Weight"
  },
  "id": "input-with-suffix-attribute",
  "name": "weight",
  "type": "number",
  "suffix": {
    "text": "kg"
  }
}) }}

Fixes #1915

[hannalaakso]

This work was reviewed by the Working Group in June, see alphagov/govuk-design-system#1269 (comment) for their comments.

[hannalaakso]

I've implemented the design for very narrow viewports. It only kicks in under 320px so I think that it's most likely to be seen by users who zoom in on a mobile device. I've tested this using the 'Aa' zoom button on iOS Safari:

I've also tried to increase text scaling on Android Chrome but it mainly seems to work for text like paragraphs and headings, it doesn't do anything for form elements for instance. I'll raise a separate issue to investigate that.

Tested on
✅ IE8 (See commit for details)
❓ IE9 (Doesn't support flex so there's a small gap between elements and some borders are incorrectly removed. However the number of IE9 users is abysmally small so I'm not worried about it)
✅ IE10
✅ IE11
✅ Windows 10 Edge 84
✅ Android 10 - Samsung galaxy S20: FF, Chrome, Samsung Internet
✅ Android 6 - Galaxy S7: FF, Chrome
✅ iOS 13 - iPhone XS: Safari
✅ iOS 11 - iPhone 6S: Safari and FF
✅ iOS 9 - iPhone 6S: Safari and FF
❓ iOS 8 - iPhone 6S: Safari and FF (Things aren't quite correctly aligned, probably a flex issue)
❌ iOS 7 - iPhone 5: Safari (Things aren't quite correctly aligned and the suffix drops onto next line - but this is way outside our support matrix and the component is still usable)
✅ MacOS Safari 13.1
✅ MacOS Firefox 80.0 with inverted colours
✅ MacOS Chrome 84
✅ Windows 10 Firefox 80.0
✅ Windows 10 Edge 84

[hannalaakso]

I wish we had another way of fixing this but I can't find anything else to stop the suffix overlapping the input focus border.

[36degrees]

We want to hold off merging this until we're ready to start on 4.0.

[36degrees]

Minor, but can we have at least one example that does not use an input width modifier? This will allow us to verify that the input is unconstrained and 'full-width' by default.

Possibly most of the examples should omit the width modifier? In the same way the National Insurance Number examples are 'full-width' even though in real world usage you'd expect them to be constrained… most of the examples should probably combine the minimum number of 'features' possible? Although we would then want some examples that show that they do combine properly…

[hannalaakso]

@36degrees I don't know if you saw the feedback from @christopherthomasdesign which the change with the width modifiers was in response to?

But maybe we mainly shouldn't use the width modifiers in the review app as the examples are out of context anyway..? Let me know if you have any thought on that. Definitely happy to include some examples without width modifiers in either case.

[36degrees]

@36degrees I don't know if you saw the feedback from @christopherthomasdesign which the change with the width modifiers was in response to?

Yep, I did – and completely agree for the examples in the Design System.

But maybe we mainly shouldn't use the width modifiers in the review app as the examples are out of context anyway..? Let me know if you have any thought on that. Definitely happy to include some examples without width modifiers in either case.

I think generally we use examples that are focused on only the specific feature, and don't 'enable' anything else – for example, the National Insurance Number examples don't include the spellcheck attribute, the example that enables isPageHeading doesn't also add a class to style it (though I think we might be missing some examples for each label size!)

[hannalaakso]

That all makes sense, I think I'm just having a slow day!

I've removed the width modifiers from the examples and added a new example that does use one.

The inputs with prefix/suffix actually look pretty strange at full width but I guess that's okay, especially since there isn't an elegant way of setting any kind of max width on them.

[edwardhorsford]

Do these end up showing in a 2/3 column grid?

[hannalaakso]

Do these end up showing in a 2/3 column grid?

They get constrained by the grid which is also a good point so I think we're okay to leave it as is 👍

[hannalaakso]

Massive thanks for all the amazing work by @simonwhatley and his team on this component 🎉🙏