We had 7 classes in _grids.scss named `.column-...` which were being
used to give a certain column width. These worked by using `@include
grid column()`, which is now deprecated.
`.column-whole` and `.column-three-quarters` can be removed and replaced
with `govuk-grid-column-full` and `govuk-grid-column-three-quarters`
respectively. The other column classes don't have a direct replacment in
GOV.UK Frontend. To get round this, we overwrite the `$govuk-grid-width`
SASS map in `extensions.scss` to add in extra widths, then use this with
the `govuk-grid-column` mixin to create new classes in for our custom
widths in `_grids.scss`
Converts links in the following:
- the page-footer component
- the table component
- the browse-list component
- the notification status, when reporting failures
- validation messaging in the whitelist page
Includes:
- turning off :visited styles to match existing
design
- swapping heading classes used to make links bold
for the GOVUK Frontend bold override class
- adding visually hidden text to some links to
make them work when isolated from their context
We may need to revisit whether some links, such as
those for documentation and features, may benefit
from having some indication that their target has
been visited.
Converts links in the following:
- the page-footer component
- the table component
- the browse-list component
- the notification status, when reporting failures
- validation messaging in the whitelist page
Includes:
- turning off :visited styles to match existing
design
- swapping heading classes used to make links bold
for the GOVUK Frontend bold override class
- adding visually hidden text to some links to
make them work when isolated from their context
We may need to revisit whether some links, such as
those for documentation and features, may benefit
from having some indication that their target has
been visited.
This replaces the buttons that aren't part of a macro and that we don't
need to write additional styles for with their govuk-frontend equivalent.
There were some links that were styled to look like buttons, so these
have also been replaced with the new govuk-frontend macro.
There was one button on the `choose-account.html` template that was in a
section of code that was never reached - this has been deleted.
The GOV.UK Frontend details component macro
wraps its `<summary>` text in a `<span>`.
We put a `<h3>` in the `<summary>` (actually valid
use, based on the spec) so this breaks when the
`<span>` wraps it.
This converts the existing `<details>` tag to use
all the class names the macro creates, but with
all the `<summary>` contents in the `<h3>`.
Also adds font-smoothing to the messages on the
API page. This was previously set globally for
all fonts in the GOV.UK Template CSS but is now
just set for the New Transport 'nta' font.
Included because the messages use the monospace
font so don't have it by default.
The GOV.UK Frontend details component macro
wraps its `<summary>` text in a `<span>`.
We put a `<h3>` in the `<summary>` (actually valid
use, based on the spec) so this breaks when the
`<span>` wraps it.
This converts the existing `<details>` tag to use
all the class names the macro creates, but with
all the `<summary>` contents in the `<h3>`.
Also adds font-smoothing to the messages on the
API page. This was previously set globally for
all fonts in the GOV.UK Template CSS but is now
just set for the New Transport 'nta' font.
Included because the messages use the monospace
font so don't have it by default.
Since we added template folders the templates page has had a ‘medium’
sized heading, where other pages have stuck with a ‘large’ size.
This commit rationalises the decision around which pages have which
heading size:
- ‘navigation’ pages (eg templates, team members, email reply to
addresses) have medium sized headings
- transactional pages (ie ones which have a green button) keep the
larger heading size
The Design System has standardised on back links being at the top of the
page, decorated with a small text-coloured arrow.
I think this makes more sense than having them at the bottom, because it
suggests, in some way, being able to go back before commiting to any of
the forms on the page. Whereas the things at the bottom of the page
should be performing actions on what’s in the page.
The reason for making this change now is that it de-clutters the area
around the green buttons. This was presenting a design challenge where
multiple levels of interaction were happening in the same form. Moving
these back links to the top of the page should mean that, in these
complicated forms, there’s one fewer thing to compete for the user’s
attention.
I’ve componentised this into a `page_header` macro so that the change is
easier to roll out and maintain.
Counting pages for API notifications takes a long time for services
with a lot of sent messages (since it issues a `count(*)` query for
the given filter). Since API message log doesn't have a "Next page"
link we can skip the count by setting a flag on the API request.
There was an awkward line break in this text, and the line length was
too long because there was no grid on the page.
Splitting it into two paragraphs makes it:
- read nicer
- avoids any awkward line breaks
Once all our users have upgraded to the latest clients they won’t need
this. The latest clients only use the combined key and service ID.
Discuss: when can we safely remove it?
This will stop us repeatedly forgetting to add `novalidate` and
`autocomplete='off'` to our forms (which is how most of them are set
up).
It uses sensible defaults, based on how we most-commonly configure
forms:
- most of our forms are `post`ed (but this can be overridden)
- `autocomplete` should only be enabled where it makes sense, otherwise
it’s more annoying than useful (but this can be overriden)
- we should never be using HTML5 form validation because our own error
styles and messages are better
It’s useful to be able to see what the email or text message looks like,
especially if you’ve sent it with a test API key (so it isn’t in your
inbox or on your phone). We already have the page for this, so we just
need to link to it.
The contact link on the settings page should be truncated instead of the
text being wrapped and overflowing on to multiple lines. This adds in an
option to the text_field macro to truncate long text fields. This
setting has been used to truncate the API callback URLs too on the
services/<service_id>/api/callbacks page.
Precompiled letters can now have two additional states:
* pending-virus-check
* virus-scan-failed
Both new states should show in the notifications dashboard, and
virus-scan-failed should appear as an error state, with a descriptive
message. You should not be able to preview a letter in one of the two
new states, so the preview link has been removed for precompiled letters
in these states.
Both `<button type='submit'>Submit<button>` and
`<input type='submit' value='Submit'>` can be used to submit a form.
We have historically[1] used `<input>` because it’s better-supported by
IE6 in that:
- the `submit` attribute is mandatory on `<button>`, not on `<input>`
- the `innerHTML` of a button will be submitted to the server, not the
value (as in other browsers)
Reasons to now use `<button>` instead:
- IE6/7 support is no longer a concern (especially with deprecation of
TLS 1.0 on the way)
- Because an `<input>` element can’t have children, the pseudo-element
hack[2] used to ensure the top edge of the button is clickable doesn’t
work. We’re seeing this bug[3] affect real users in research.
1. We inhereted our buttons from Digital Marketplace, here is me making
that change in their code: 8df7e2e79e (diff-b1420f7b7a25657d849edf90a70ef541)
2. 24e1906c0d (diff-ef0e4eb6f1e90b44b0c3fe39dce274a4R79)
3. https://github.com/alphagov/govuk_elements/issues/545
Delivery comes before inbound. The order of the URLs was jumbled in two
places:
- in the view function
- in the Jinja template
So as the user saw it the URLs were in the right order, because the
double jumbling cancelled itself out. But it made the code _really_
confusing to read.
This commit:
- uses WTForms email fields wherever we collect email addresses
- makes sure we don’t let the default HTML5 form validation get trigged
(using `novalidate`[1])
We don’t want to use the default validation because:
- it looks out of place
- it’s not well supported by assistive technology
1. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/form#attr-novalidate
A page should have only one `<h1>` element. So if there’s an error
message, which contains a `<h1>`, it should replace the page’s normal
`<h1>` element, rather than sit above it.
Currently revoking an API key takes you to a separate page. It should
work the same way as other destructive actions, ie staying on the same
page but with a banner asking you to confirm the action.
Making the navigation narrower means that we have more space on every
page. So on pages where we had to use 16px type just to fit stuff on the
page we can now bump the type size up to something less miserly. This is
mainly the team and settings pages.
We still need to use 16px on pages which list notifications or previews
of spreadsheets, because we’re still trying to fit a lot of information
onto these pages, so every little space-saving helps.
In pages specific to a service (e.g. dashboard and sub pages) the title
needs to distinguish which service it applies to. This is mainly to give
context to screen reader users who could be managing multiple services.
Implementing this uses template inheritance:
`page_title` includes `per_page_title` includes `service_page_title`
‘GOV.UK Notify’ is inserted into every page title.
Pages that set `service_page_title` get the service name inserted too.
> If both sections of the page have errors and the page is submitted,
> focus moves to the mobile numbers section so screen reader users may
> not be aware of preceding errors - focus should move to a dedicated
> error summary at the top of the page.
This commit adds the dedicate error summary at the top of the page,
following the GOV.UK Elements style from:
http://govuk-elements.herokuapp.com/errors/
