New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Select #60

Open
govuk-design-system opened this Issue Jan 12, 2018 · 5 comments

Comments

6 participants
@govuk-design-system
Copy link
Collaborator

govuk-design-system commented Jan 12, 2018

Use this issue to discuss this component in the GOV.UK Design System.

@govuk-design-system govuk-design-system created this issue from a note in GOV.UK Design System Community Backlog (In progress) Jan 12, 2018

@govuk-design-system govuk-design-system moved this from In progress to Published in GOV.UK Design System Community Backlog Jan 12, 2018

@timpaul timpaul added the component label May 21, 2018

@dashouse

This comment has been minimized.

Copy link

dashouse commented Oct 30, 2018

Collating a few thoughts / experiments on <select>'s

Styled selects

Although the current version of the <select> component in GOV.UK Frontend has some styles it's appearance is largely dictated by the browser default. Therefore a <select> in Chrome will look different to a <select> in Safari, IE, Edge, FF etc. This can cause alignment issues if a select is used as part of a group of components and generally doesn't feel like part of the visual style of GOV.UK.

screen shot 2018-10-30 at 10 42 52

I have an example of a styled select experiment on this codepen

iOS spinner control content cropping

Using the default <select> markup, the options that an iOS user will see will be cropped if they are around 30 characters (it may be fewer on a smaller device - test was done on an iPhone 7).

For this reason options should be front loaded to emphasise the differences.

Prefixing options like this:

  • Cool black t-shirt with GOV.UK Logo - Size M
  • Cool black t-shirt with GOV.UK Logo - Size L

has a greater chance of the important information being cropped off than if you front loaded the information that made the options different.

  • Medium - Black GOV.UK Logo T-shirt
  • Large - Black GOV.UK Logo T-shirt

The <optgroup> hack

You can force iOS to "shrink to fit" the full text of every option in a <select> by adding an empty <optgroup> to the the list of options. Of course if you are genuinely using <optgroup>'s in your <select>'s then this will also just work.

dnxqabmx0aaaznz

There is an example of this on this codepen

Please note the <optgroup> itself has a physical size so if you add an empty <optgroup> you will see an extra space at the bottom of the <select>. In this example I have used display: none; to remove this.

Legend > Radios / Checkboxes alternative to <select>

This idea is purely a conceptual untested experiment

As many of the usability issues of <select>'s are around the behaviour of the native HTML component, if you genuinely need to collapse a group of options creating a custom select component could be an option.

This is a quick example I put together which could progressively enhance a <legend>, <fieldset> using JavaScript to reveal a group or radios or checkboxes.

select-radios

@36degrees

This comment has been minimized.

Copy link

36degrees commented Oct 30, 2018

Although the current version of the <select> component in GOV.UK Frontend has some styles it's appearance is largely dictated by the browser default.

Note that there was a previous attempt to style the select element but it was never merged because we found there were issues making the (recreated) arrow indicator visible in browsers where the user had overridden colours.

@sanjaypoyzer

This comment has been minimized.

Copy link

sanjaypoyzer commented Dec 11, 2018

Can we add some examples of when it is okay to use a select component? Or if we don't have any, we should more explicitly say 'We have not seen any examples of a select component being necessary'.

At the moment the current guidance "select should only be used as a last resort" seems a little vague.

@joelanman

This comment has been minimized.

Copy link
Member

joelanman commented Dec 11, 2018

It's a good question. The idea of the current guidance is to try other things before using a select, as we know they have various problems.

I think there's a good example of usage on Find a job (via @dashouse)

image

I'm referring specifically to the 'sort by' select. Caveat - I haven't seen any research on this particular example.

In this case, there is not much space to use radios - they would push the main content down the page a lot.

The select has the 'right' number of items in it, few enough that you don't need to scroll within it, which is a problem for users. But more than two, which would probably be better as radios.

Finally, the 'sort by' control is where users might expect it, from using other sites - at the top right, so redesigning the control and placing it elsewhere might not be a good option.

@sanjaypoyzer

This comment has been minimized.

Copy link

sanjaypoyzer commented Dec 11, 2018

Subtly suggesting I should go get a job somewhere else with that link? 😉

I think there's a couple of options that are available to Find a Job here - One being to have radio buttons over on the left-hand side with the filters, the other being to have a horizontally aligned list, like a nav bar, in place of the select. In terms of accessibility, I would have thought the first would be better as then the filter/sort tools are grouped together which lets people refine what they are looking at it in the same place.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment