The environment variables for Tenon aren't available for forks:
https://travis-ci.org/alphagov/govuk-frontend/jobs/252049398#L457

The build fails and the tests don't run.
Ideally the tests should run, even if we can't run Tenon to check components from forks.

Needs further investigation.

The utility classes e.g. govuk-u-pt-1 that are output from _spacing.scss define hard units. These classes should contain a breakpoint that follows this mapping.

60px (Desktop) > 40px (Mobile)
50px (Desktop) > 30px (Mobile)
30px (Desktop) > 20px (Mobile)
20px (Desktop) > 15px (Mobile)
---- No change below 15px ---
15px (Desktop) - 15px (Mobile)
10px (Desktop) - 10px (Mobile)
5px (Desktop) - 5px (Mobile)

details.njk uses summary argument, I think it should use summaryText?

as it stands nothing appears next to the arrow

Can reproduce by rendering

  {{ govukRadios({
    "fieldset": {},
    "idPrefix": "radio-stacked",
    "name": "radio-stacked",
    "items": [
      {
        "value": "email",
        "text": "Email"
      },
      {
        "value": "phone",
        "text": "Phone"
      },
      {
        "value": "text",
        "text": "Text message"
      }
    ]
  }) }}

Some of our components allow nesting using https://mozilla.github.io/nunjucks/templating.html#call.

We currently can't show this in the guide or tests, so this functionality could break.

For example #509 we do not have coverage for 'caller'

We would need to

• Allow the review application to show 'caller' examples
• Allow the tests to test 'caller' examples

This issue is raised on behalf on @owenm6.

Suggested changes to the back link pattern

When not to use this component

On non-linear flows including a back link could confuse users or stop them completing a task

How to use this component

Adding a page title or ‘back to previous page’ makes it clearer to the user what to expect from the interaction. It also helps increase a users confidence that they will not lose their work.

Research

We have seen some users not understand the context of the current back link design. This has caused them anxiety.

Some users have been concerned that using the back link would lose their work.

Adjustments to design

• change triangle to arrow (chevron)
• use link colour for consistency

Code and examples

The Phase tag component has generic value beyond it's use in the Phase banner component.

For example, we could use it to style the task statuses in the task list pattern.

For this reason we should remove the reference to 'phase' from the name.

This is an example of a component that goes by a number of names - we should add 'pill' and 'chip' as aliases.

hey folks, I've been thinking about our grid usage, and it's something that tends to be used across component boundaries.

So I was wondering if they should actually be objects and not components?

E.g. govuk-o-grid instead of govuk-c-grid

As per https://github.com/alphagov/govuk-frontend/blob/master/docs/coding-standards/css.md#objects-o-

Following on from the conversation here alphagov/govuk_elements#545.

It seems that input style buttons are only useful in IE6/7, since we do not support these browsers should we remove this from our macro and reduce complexity in the component?

The Date component allows users to input some non-numeric characterse, ., + and -

We need a test to make sure we can't update READMEs without commiting them.

Steps to reproduce:

• Visit the demo page for radio buttons or checkboxes
• Click the control

On desktop, it will select, but if you click elsewhere, it will deselect
On mobile, it won't select

To make sure we have deterministic builds we should commit in the package-lock.json.

Macros abstract our class names, if we were to change our class names, macro usage would break for our users.

In our button examples, we pass the internal button modifier class to make a button into a start button.

We could consider passing a boolean instead so that if we choose to change how our classes work, macros still function.

For example instead of

- name: start
  data:
    text: Start now button
    classes: 'govuk-c-button--start'

We could do:

- name: start
  data:
    text: Start now button
    start: true

See also the GOV.UK Publishing component: http://govuk-static.herokuapp.com/component-guide/button/start_now_button

Link to code: https://github.com/alphagov/static/blob/a9a040a72d475ef7015c1c9e690a5d77687fcfd8/app/views/govuk_component/button.raw.html.erb#L1

We constructed the class based on booleans, then finally merge with classes and inject into the markup.

Edit:
I put together an example showing how you can restructure the macro to avoid the confusing forking logic.

This approach only forks on individual parts of the template, which is easier to reason about.

https://glitch.com/edit/#!/flag-based-macro-approach?path=views/index.html:15:26

We could recognise contributors with something similar to https://github.com/kentcdodds/all-contributors

Instead of fixing simple issues that are not high priority ourselves we could open them up the community, even for people who are new to Github etc.

https://github.com/hoodiehq/first-timers-bot

This will need to be done in the design system too.

#519 (comment)

There's occasionally the need to highlight text in user interfaces.

For example:

• matching text in search results
• placeholders in GOV.UK Notify templates
• showing changes to contracts in Digital Marketplace

The Home Office design system has a style for this.

At the moment it is possible to have a failing master branch.

1. Contributor 1 pushes PR 1
2. PR 1 passes CI
3. Contributor 2 pushes PR 2 with breaking changes that 1 relied on
4. PR 2 passes CI and is merged into master
5. PR 1 will not now be failing since Travis only runs on updates to an individual PR, not master changes.

Considered solution: Force branches to be up-to-date with master

We ruled this out since it would mean with so many PRs happening we'd have to rebase very often which would slow down the team.

Another option is to ensure that before releases our test suite is ran.

We need to update the build scripts or documentation to include this step.

To avoid duplicating code examples and documentation manually, as well as having full docs in the source directory for each component, we generate the README markdown file and a dev preview page from the same set of nunjucks templates.

This will allow us to test our assumptions with consumers.

It could be the case that we disable the generation task once we are confident in the docs content, but there is still the question creating and updating docs for component when a contribution happens.

Occasionally you need to style something that’s not a link as a link. For example, summary tags are styled as links on GOV.UK, and occasionally form controls need to be styled as links.

If autofill is turned on (default) Safari adds the "person" icon to the right hand side of the input.

Relating to constraining inputs to an appropriate size of their content, this example on the DVLA Driving Licence service shows the autofill icon completely obscuring the content of the input. The user needs to type blindly and will only see what they have typed by de-focussing. (side note, this example will also lead to a year typed many times which is also not apparent even after de-focussing)

Do we want to suggest that inputs should:
be "x" many characters bigger than expected content
or
override the autofill icon all together?

input::-webkit-contacts-auto-fill-button {
  visibility: hidden;
  display: none !important;
  pointer-events: none;
  position: absolute;
  right: 0;
}

If our form elements were the same height it would make it much easier to maintain a vertical rhythm and to create horizontal form layouts where necessary.

For example, we sometimes need to align buttons to the right of form fields (eg. search boxes). They'd look a lot nicer if they were the same height.

I'm thinking of the following elements in particular: radios, checkboxes, text fields, select boxes, type-aheads, buttons.

For example with the button examples, it lists many inputs as required but only a few are required.

This may be a wider problem, I imagine we'd want to automate this process as @36degrees has spoken about before.

Radio labels extend to the full width of the container. This means the clicks apparently in space on the righthand side activate radios.

This was not the case with Elements where labels only extended as far as the text.

What

We had a discussion on a design system slack channel about the documentation not to encourage the use of html parameter in macros. We concluded, we shouldn't take away that functionality, but make it clear it's unsafe to use, causing people to rethink the strategy or apply necessary fixes before hand.

Why

It's more efficient to copy and paste a block of text without realising what it's doing. It could easily bring some XSS vulnerability into the application by accident, which we'd all like to avoid.

Proposal

Changing the name of the html attribute is a good start. This will need to be followed by some documentation changes on the Design System.

Before

{% from "panel/macro.njk" import govukPanel %}

{{ govukPanel({
  "titleText": "Application complete",
  "html": "Your reference number<br><strong>HDJ2123F</strong>"
})
}}

After

{% from "panel/macro.njk" import govukPanel %}

{{ govukPanel({
  "titleText": "Application complete",
  "unsafeHTML": "Your reference number<br><strong>HDJ2123F</strong>"
})
}}

Connection

alphagov/govuk-design-system#175

See https://github.com/alphagov/govuk-frontend/blob/master/.travis.yml#L6

I don't believe this will ever run since we pin a LTS Node.js version.

eg date-input.njk has hyphens in the brackets, cookie-banner.njk does not
should probably be consistent?
note: these hyphens do not work with Nunjucks v2, which we are currently using on the kit, however we may well upgrade. We have avoided because of this issue:

mozilla/nunjucks#696

https://govuk-frontend-review.herokuapp.com/components/label

Our hint text in labels are directly embedded, if this were very long it could make these labels unwieldily.

Should we be using aria-describedby and move these hints outside the label?

https://developer.paciellogroup.com/blog/2014/12/using-aria-describedby-to-provide-helpful-form-hints/

<label class="govuk-c-label">
  National Insurance number
  <span class="govuk-c-label__hint">
    It’s on your National Insurance card, benefit letter, payslip or P60. For example, ‘QQ 12 34 56 C’.
  </span>
</label>

vs

<input id="input-example" aria-describedby="label-hint"/>
<div class="govuk-c-label">
  <label class="govuk-c-label__text" for="input-example">National Insurance number</label>
  <span class="govuk-c-label__hint" id="label-hint">
    It’s on your National Insurance card, benefit letter, payslip or P60. For example, ‘QQ 12 34 56 C’.
  </span>
</div>

It'd be good to know how big our builds are, how they impact users and get a baseline for GOV.UK Frontend.

Tools

• http://hughsk.io/disc/
• https://bundlephobia.com/

We want to create isolated components that include and call relevant dependencies without duplicating the imported code.

Possible approaches:

1. use a sass mixin to check: http://paul.wellnerbou.de/2015/05/18/avoid-multiple-imports-of-the-same-scss-file-with-sass/ or https://github.com/carbon-design-system/carbon-components/blob/master/src/globals/scss/_import-once.scss

2. Use an NPM module:
   https://www.npmjs.com/package/node-sass-import-once

Either way it might become redundant as of Sass 4.0: sass/sass#156

Copied over from GOV.UK Frontend toolkit

There are cases where it's useful to have a colour with a semantic meaning of 'positive'.

We already have error_colour which is a good red for 'negative' - but we don't have a counterpart.

We could use an existing colour, or make a new colour. Either way, a semantic SASS name would be good.

The closest colour would be button_colour. An alternate would be #008800 which is the green used by petitions. It's warmer, which feels more positive to me.

The classes govuk-c-border govuk-c-border--left-narrow have no associated styles.
The border comes from the text element nested beneath it.

The majority of the time, you want Day, Month, Year, so we could just have that as the default without the user having to specify items

As mentioned by @dashouse in #519:

Might be worth thinking about all border widths being less specific in general and not worrying about specifying names based on usage?

$govuk-border-width-10: 10px
$govuk-border-width-5: 5px
$govuk-border-width-4: 4px
$govuk-border-width-2: 2px
$govuk-border-width-1: 1px

aXe fails when testing tables that have

html<td scope="row></td>

Steps to take:

1. Figure out if this is a real issue or something that should be ignored.
2. Unskip the test https://github.com/alphagov/govuk-frontend/pull/522/files#diff-2cfe07504444a7f34f0f9b6c29ccca3cR10
3. Update the test with ignored rules or template to remove the attribute depending on 1.

There are some cases where it’s not appropriate to distinguish between visited and non-visited links.

An example is navigation links to pages with dynamic content, like dashboards in admin systems. The content on the page is changing all the time, so the fact that you’ve visited it before is not that important.

Looks like we're running a specific task here:

https://github.com/alphagov/govuk-frontend/blob/master/tasks/gulp/lint.js#L10

Which should be the same as what is run as part of npm test here: https://github.com/alphagov/govuk-frontend/blob/master/package.json#L23

We'd want to make sure to remove the dependencies that this uses too.

Frontend doesn't seem to have a way to highlight errors with the red line to the left, like Elements does:

https://govuk-elements.herokuapp.com/errors/#highlight-errors

By default our input and select fields switch to 100% width for small screen sizes. In some cases however we want them to remain at a fixed width. For example, very short fields designed to take a specific number of characters, like day, month, year and postcode.

Extension of this Pull Request #491 to investigate if we can get alignment pixel perfect across browser.

Looks to be how box-shadow is rendered on this device.

Raised here to unblock this PR.

Raised in #519 (review)

In radios and checkboxes components, it would be more semantic to wrap the component (eg. .govuk-c-radios) within a fieldset, instead of vice versa which is what is happening now.

Here is the code for a start button on the Prototype Kit:

<a class="govuk-c-button govuk-c-button--start govuk-!-mt-r2 govuk-!-mb-r8" href="/start" role="button">Start now</a>

This seems complicated for a standard component? Are we doing it right on the Prototype Kit, or can the Start Button component be tweaked somehow to make the code less complex?

Are we publishing the minimal amount of files, this will make npm installs quicker for consumers?

I'm wondering if we instead of using govuk-text-colour we could use govuk-text-color.

This mirrors the spelling seen elsewhere in CSS.

color: $govuk-text-color;

vs

color: $govuk-text-colour;

I'm not sure it's worth embracing the UK spelling here, we should be inclusive and take the hit ;)

Related: https://github.com/HashanP/postcss-spiffing

Potential problem:
When an input has an error it's border is increased from 2px to 4px. This means that input will become physically bigger than it's previous state.

When this input is in-line or part of a tight lockup with another element the component parts will become mis-aligned.

Should we adjust the padding of the input error state to compensate for the increased border?

For example

.govuk-c-input {
        padding: 5px 4px 4px;
}
.govuk-c-input--error {
        padding: 3px 2px 2px;
}

Before | After

Is there an alternative way of doing this with box-sizing?

Sometimes it is useful to be able to describe why an example exists, maybe an edge case or a simulation of state

Some user interfaces are designed for high information density and regular use. In these cases, smaller form controls may be required.

The Home Office design system already has small versions of radio buttons and checkboxes, we should probably add text fields, select boxes and buttons to that list.

Implementation considerations:

• is this a modifier class that you can apply to any form component?
• does the class apply to all form elements inside the component?
• for text input and select, does the font get smaller too?