This replaces the slider with an integer input for each provider.
Unfortunately showing a variable number of inputs isn't easy to
achieve in WTForms [^1], but we think this is the least worst way
to do it vs e.g. not using WTForms at all.
[^1]: https://github.com/wtforms/wtforms/issues/736
Our CSS for links in the navigation, which makes
the underline appear on hover is overriding the
GOVUK focus styles, making it look like there are
2 underlines. This adds some extra CSS to reset
it.
The new CSS is further down the stylesheet to the
hover styles. This gives them a higher specificity
meaning they override them when these links are
hovered over while in focus.
Based on comments on the associated pull request,
(and my realisation that I was using flexbox
wrong):
https://github.com/alphagov/notifications-admin/pull/4171
Removal of flex-grow
I added `flex-grow: 1` to make the description and
status flex items grow to fill the container, at
least until they hit their `max-width`. They
already have `width: 100%` which achieves the same
thing so this removes it.
Using `width` doesn't work for flex-items with
flex-grow set above 0 because they will expand to
fill the space, whatever its value.
The intention for this line was always to
constrain how much these ones can grow to half the
space minus the gap between. `max-width`, which is
still honored by flex-items with `flex-grow` above
0, meaning they will expand up to that size.
Having a grid in the click target stops the hint
and status text being clickable. This removes it
in favour using flexbox to position the elements
in a similar way.
Includes fallback styles for browsers that don't
support flexbox that positions the child elements
inline, laid out justified, to mimic the flexbox
positioning of justify-content: space-between.
Note: display is overriden on child items under
flexbox so setting display: inline-block is
ignored.
In user research we quite often saw people accidentally scroll the
branding preview `<iframe>` when trying to scroll the page.
This is suboptimal because they:
- were confused why the page wasn’t scrolling
- lost visibility of the branding they were trying to preview because
it scrolled outside the bounds of the `<iframe>`
In previous iterations of the classPersister, we
found issues with the implementation meant classes
it should have added back to elements were also
added to other elements. This adds tests for this
scenario to ensure it doesn't happen again.
Also includes changes to fix a linting error with
the JS which complained about a function being
defined in a loop while referencing variables in
the outer scope.
The assumption that the classes you want to
persist will always have parity with the elements
that have those classes, at that point, won't
always be true.
Because of that, this changes the way elements
with those classes are stored, to be in a map
between classes and the elements with them (at
that point).
Also includes an extra test for a scenario where
more than one updating component is in the page
with classes that need to persist through updates.
File-list items contained by div.keyline-block's
are pushed down 3px more than elsewhere which
creates a gap between the top of the focus style
and the keyline above. This extends the part of
the focus style made up by a box-shadow by 3px so
it covers the gap.
If the :has pseudo-class becomes available in the
browsers we support in future, the code this
branch/pull request adds will be redundant as its
behaviour will be possible only using CSS.
This adds comments to note this to the parts of
the code you'd need to remove.
Includes the following:
Guard for adding duplicate classNames
Stops the code that allows classNames to persist
across updates to the component HTML from adding a
className multiple times to the list of those to
persist. From this comment on the associated pull
request:
https://github.com/alphagov/notifications-admin/pull/4155#discussion_r804639058
Add comment explaining guard for operations on
elements no longer in the DOM
The value of this guard can be unclear and why it
is needed so we add a comment to explain this.
From this comment on the associated pull request:
https://github.com/alphagov/notifications-admin/pull/4155#discussion_r804697189
We can't guarantee that elements we stored a
reference to with `classesToPersist.remove` will
still exist so we need to guard against this.
Note: it checks for whether the node is still
attached to the DOM rather than whether it exists
because the standard way to delete a node just
detaches it from the DOM and relies on garbage
collection to delete it from memory.
The current updateContent JS replaces the in-page
HTML with the HTML from the server the first time
an AJAX request is fired, even if the HTML from
the server has no changes. This is because the
code that compares the two operates on two
different things:
The HTML in the page is the component HTML, with
all the data attributes and the partial HTML
(marked with the 'ajax-block-container' class) as
its first child:
```
<div data-module="update-content" data-url="...">
<div class="ajax-block-container">
...
</div>
</div>
```
The HTML from the server only contains the
partial:
```
<div class="ajax-block-container">
...
</div>
```
The diffing code just sees them as different at
the top level so replaces the page HTML with the
partial from the server. This means all subsequent
diffs are between partial HTML and partial HTML so
only update on actual changes.
These replace the component with the partial, as
part of the component initialising. This means all
code that runs on an AJAX response will only
compare like-for-like so will result in actual
changes (or none at all), not just swapping one
element out for another.
Note: this commit also removes the
aria-live="polite" from the ajax_block component.
It has always been overwritten by the first
response so never announces anything to assistive
technologies. Removing it makes this more clear.
Includes:
- JS to add a class to the heading when the link
is focused
- CSS to apply the enlarged focus style via a
selector which uses that class
- changes to the partial to hook in the JS to
track focus on links and to tell the
updateContent JS to persist the classes added
between updates to the HTML
Wrap the code that updates the HTML with changes
from the server with code that stores and
re-applies specified classes.
This is to allow other JS to add classes which
change the visual state of the HTML without them
being considered by the code that diffs our
in-page HTML against that from the server.
They are called classesToPersist because this
should make the visual state they create persist
between updates.
Includes the addition of tests for updateContent
that cover the addition/deletion of elements so we
can write a test for classNames persisting through
updates. The existing tests only cover updates
that change the content of elements. Just adding
the test for these changes to those would simulate
a scenario that doesn't exist in the app. Writing
extra tests for the kind of updates these changes
act on keeps them in line with the app code.
For the "Something else" branding form we want the form label to be the
title. This brings in the textarea component from GOV.UK Frontend in
order to do this since that contains code to set a the textarea label as
the page heading in an accessible way.
The rest of the textarea fields have not been switched to use the new
component yet.
Most browsers apply the focus style when a link is
clicked but Safari just applies the active style.
This meant our large links, with expanded click
areas, didn't get the focus style themselves but
their psuedo-elements (which create the expanded
click area) did.
This adds the focus styles to the active state of
links with the expanded click area, to ensure all
of their click area gets the focus style.
At present the file-list pattern assumes each
item has hint text below the link and so increases
the hit area to overlap the hint. This adds a
variant for items without one and uses it on the
page for choosing an alert sub-area.
We added domdiff to replace the DiffDOM library
here:
87f54d1e88
DiffDOM had updated its code to be written to the
ECMAScript 6 (ES6) standard and so needed extra
work to work with the older browsers in our
support matrix. This was recorded as an issue
here:
https://www.pivotaltracker.com/n/projects/1443052/stories/165380360
Domdiff didn't work (see below for more details)
so this replaces it with the morphdom library.
Morphdom supports the same browsers as us and is
relied on by a range of large open source
projects:
https://github.com/patrick-steele-idem/morphdom#what-projects-are-using-morphdom
It was tricky to find alternatives to DiffDOM so
if we have to source alternatives in future, other
options could be:
- https://github.com/choojs/nanomorph
- https://diffhtml.org/index.html (using its
outerHTML method)
Why domdiff didn't work
Turns out that domdiff was replacing the page HTML
with the HTML from the AJAX response every time,
not just when they differed. This isn't a bug.
Domdiff is bare bones enough that it compares old
DOM nodes to new DOM nodes with ===. With our
code, this always results to false because our new
nodes are made from HTML strings from AJAX
response so are never the same node as the old
one.
This was a minor issue in a recent incident [1].
We don't want people emailing us directly:
- It's harder to collaborate on replies than in Zendesk, where I
can see who's editing.
- We can't take advantage of macros like we can in Zendesk.
- People emailing us directly creates an unnecessary distraction
and it's easy to lose track. We want to minimise distractions in
an incident situation.
- We use notify-support@ for monitoring, so we don't want noise.
[1]: https://docs.google.com/document/d/1eArpcYoCmhlgB45FZpGj1_HnkAgpgtgwr-KBiUq7h8c/edit#
Making the icon an inline SVG lets it inherit
colours from the page styles. This helps in forced
colour modes, like Windows high contrast mode,
where it will match the colour of the text next to
it, whatever it is set to.
Making it inline requires some changes to the CSS
to allow its position to match that of the current
background image.
This also sets `forced-color-adjust` to `auto` on
the `<svg>` element, which tells the browser it
can control its colours in forced colour modes.
This is required because the browsers that support
forced colour mode set it to `none` for the
`<svg>` element by default.
At the moment, the icons in the key of the map
showing what each type of area drawn on the map
means change colour in high contrast mode. This
causes a mismatch between the areas on the map and
the key.
These changes remake the images in SVG to prevent
the colours changing in high contrast modes. They
also add a white background to the icons, to make
sure they match the areas they refer to in the
map.
The enhancedTextbox component has an element that
sits in front of the textbox and draws the
highlights over the text. This element has a 2px
border so it's dimensions match those of the
textbox. This border has a colour of 'transparent'
by default, to hide it from view but this is
overridden in high contrast modes to match the
text colour.
This adds some CSS targeting high contrast modes
which sets it to match the colour of the
background, making it invisible again.
The link-buttons we use in our pill component
have a blue background which shows the area they
occupy by default. In high contrast mode,
backgrounds are hidden so the link-button text
looks like it is floating because you can't see
the edge of their area.
These changes use the trick of adding a
transparent border. This is hidden by default but
displays in high contrast mode to show the edges
of the link-button. I've reduced the padding to
accommodate the extra space it takes up.
The mock up component, shown in all
current/past/rejected alert pages, doesn't show
fully in high contrast modes because it uses its
background colour to show its shape and
backgrounds are hidden in high contrast modes.
This uses a technique from design system which
adds a transparent border to these elements to
show their shapes. This works because borders of
any colour (even transparent) are rendered as the
foreground colour.
Previously all our error messages had the class `error-message`.
Where we are using the components from GOV.UK Frontend they have the
class `govuk-error-message`.
This makes the code which jumps focus to the first error work in both
cases.
In 674c27a693 we updated the autofocus
Javascript to be compatible with GOV.UK Frontend textboxes, which have
the `data-module` attribute set on the `input` element, rather than on
a wrapper element.
However we still have some `<textarea>`s and `<input>`s which haven’t
moved to GOV.UK Frontend and therefore aren’t getting picked up by the
Javascript which is supposed to focus them.
This commit makes the Javascript work with both kinds of textbox, which
is needed until we move entirely to GOV.UK Frontend.
Previous the text input on the send one off SMS page was wrapped in
an element with a class of `form-group`. We overrode the spacing on this
element to make the links under the textbox move closer to the textbox,
so that visually they group together.
This was broken when we moved to GOV.UK frontend, which uses a class of
`govuk-form-group`. This commit changes the CSS to account for both
possibilities, because the send-a-one-off-letter page is still using a
textbox, not a text input, and textboxes haven’t moved to GOV.UK
Frontend yet.
The size and position of the 'X' has deviated a
bit from the design intentions of the original.
The original shared the x-height of the area text
and has positioned to be vertically and
horizontally centered.
These changes assume an x-height of 11px and use
flexbox to center the new 'X' horizontally and
vertically.
This also tweaks the visual state when focused and
then hovered so matches other buttons without
breaking the design.
The text never had underlines like our other
link-button components so always looked like
buttons. If they look like buttons, they should
act like them too and have those semantics.
This give them a role of button and uses the class
and data attribute for the button component from
GOVUK Frontend to make them work like one.
These changes include a fair amount of styles to
override those the govuk-button class brings in.
I've tried to mark those ones to at least make
that obvious.
The current link button for removing an area is
created using a psuedo element with an 'x' as
content.
The inline box for the 'x' overlapped its parent.
This is visible in high contrast mode, breaking the
parent's border. Despite existing in CSS, the 'x'
is also announced by screen readers, which is not
what we want.
This changes it to be an inline SVG with a role of
image. It doesn't require as large an inline box
so doesn't cause visual issues in high contrast
modes. It also means we can set it's label similar to
how you would an image's alt text, giving us
control over what is announced by screen readers.
This commit also includes some extra CSS,
targeting high contrast modes, giving the
link button the following when viewed in those
modes:
- a complete border so it is
distinguishable from the list item
- a focus style
This is currently spelt incorrectly though it
seemed to work nonetheless. Can only assume this
is a common error, for this attribute or all
attribute names, so browsers work it out.
This makes the spelling match the spec:
https://www.w3.org/TR/wai-aria/#aria-describedby
The browser uses the `width` and `height` attributes of the image tag to
allocate space on the page for the image.
If these aren’t provided then the browser will assume the image takes up
no space, until it’s downloaded it and had a look at what the file’s
dimensions are. This causes the layout of the page to jump once the
image downloads.
`149 × 150px` is the native size of the image. But we don’t want it to
display at that size, so this commit also adds some extra CSS which
keeps it looking the same, namely:
- the full width of the 1/4 page column on desktop
- the full width of the column minus a `40px` gutter either side on
mobile (by using `box-sizing: border-box` the `40px` of padding is
subtracted from the 100% width, rather than added to it)
When the component was renamed from ‘API key’ to ‘Copy to clipboard’ the class for the thing to be copied changed from `api-key__key` to `copy-to-clipboard__value`. While the CSS was updated to reflect the change from `api-key` to `copy-to-clipboard` the change from `__key` to `__value` was not made.
Before: 4921e6d46e/app/templates/components/api-key.html
After: 85f6881a56/app/templates/components/copy-to-clipboard.html
This commit changes updates the CSS to reflect the latter change, so that the styles get applied properly.
A while ago diffDOM moved its code to use ES6
modules and started using various language
features specific to ES6. These two things
happened independently btw.
The result of this is that the version of diffDOM
suitable for our build pipeline, structured as an
immediately invoked function evocation (IIFE),
now requires polyfills of some ES6 features to
work in the older browsers we support, like IE11.
It's also worth noting that in the move to ES6
the maintainers of diffDOM have adopted a process
whereby users who need to support older browsers
now have to add polyfill code for any ES6 features
they choose to use.
This commmit proposes a move to the domdiff
library instead because:
- it runs on all javascript runtimes with no
polyfills
- it is 2KB instead of diffDOM's 25KB
Domdiff takes a different approach to diffDOM, in
that it compares existing nodes and new nodes and
replaces the existing ones with the new ones if
there are differences. By contrast, diffDOM will
make in-place changes to nodes if there are enough
similarities. In other words, in most situations,
diffDOM won't change the node in $component
whereas domdiff will.
Because of this, I've had to change the
updateContent.js code to cache the data-key
attribute's value so we don't lose access to it by
overwrite the $component variable with a different
jQuery selection.
since we are hard-coding a generic error message on the front-end, we
have no need to do anything on the back end. This is also nice as it
standardises the two flows to behave more like each other (rather than
previously where one would `flash` an error message and the other would
return CBOR for the js to decode).
Note that the register flow returns 400 while the auth flow returns 403.
The js for both just checks `response.ok` so will handle both. The JS
completely discards any body returned if the status isn't 200 now.
