Removes the following cookies:
- seen_cookie_message (flags if banner was already
shown)
- _gid (Google Analytics cookie)
- _ga (Google Analytics cookie)
These were set by default before so potentially
still around for some users.
The code for this now exists as a static method on
the cookieMessage module and is called when the JS
loads for the first time.
It's not obvious how the code that includes JS
Modules in the frontend build works.
This adds lots of comments to explain the various
bits and flattens `modules/all.mjs` to just be a
single function that starts off the window.GOVUK
namespace.
Also removes `module/all.js` from the repo'. It's
an artefact used by the frontend build so
shouldn't be included as source code.
The cookie_message block was part of GOV.UK
template but is not included in the GOV.UK
Frontend template.
This adds it back in along with JS to set the
cookies from GOV.UK template and styles, taken
from the Design System's website (which I assume
has the right colour contrast).
This includes the JS for all GOV.UK Frontend code.
If our frontend build includes a module bundler in
future, we should only include the JS for the
components we use, as with our Sass.
It's not obvious how the code that includes JS
Modules in the frontend build works.
This adds lots of comments to explain the various
bits and flattens `modules/all.mjs` to just be a
single function that starts off the window.GOVUK
namespace.
Also removes `module/all.js` from the repo'. It's
an artefact used by the frontend build so
shouldn't be included as source code.
The cookie_message block was part of GOV.UK
template but is not included in the GOV.UK
Frontend template.
This adds it back in along with JS to set the
cookies from GOV.UK template and styles, taken
from the Design System's website (which I assume
has the right colour contrast).
This includes the JS for all GOV.UK Frontend code.
If our frontend build includes a module bundler in
future, we should only include the JS for the
components we use, as with our Sass.
It's not obvious how the code that includes JS
Modules in the frontend build works.
This adds lots of comments to explain the various
bits and flattens `modules/all.mjs` to just be a
single function that starts off the window.GOVUK
namespace.
Also removes `module/all.js` from the repo'. It's
an artefact used by the frontend build so
shouldn't be included as source code.
The cookie_message block was part of GOV.UK
template but is not included in the GOV.UK
Frontend template.
This adds it back in along with JS to set the
cookies from GOV.UK template and styles, taken
from the Design System's website (which I assume
has the right colour contrast).
This includes the JS for all GOV.UK Frontend code.
If our frontend build includes a module bundler in
future, we should only include the JS for the
components we use, as with our Sass.
Detach all methods from sticky reference so they
can be attached to different objects.
Split sticky into stickAtTop and stickAtBottom and
make new versions of all methods and properties
specific to stickAtBottom.
Add CSS for stickAtBottom and call on load
Service contact details are needed if the upload document permission is
enabled - this used to be a link but services can now choose to use a
link, email address or phone number. The form to add or change service
contact details now gives these options and validates the data according
to the type of contact details provided.
When validating phone numbers we can't use the existing validation
because we want to allow landlines too, so there is a basic check that
the phone number is the right length and doesn't include certain
characters.
You might need to scroll this page quite a lot to see where a
placeholder appears in your template – especially if you have a long
email or letter.
One of the things I’m trying to stop happening so much is a lot of
scrolling back and forth. This would happen if you were scrolling down
to see the placeholder, then back up to fill in its value.
So this commit makes the textbox ‘sticky’, ie it always stays at the top
of the viewport, even when you scroll down. This lets you see the
placeholder and the textbox side by side, no matter how long the
template is.
The code to do this mostly comes from the GOV.UK Frontend Toolkit
(documented here: d9489a9870/docs/javascript.md (stick-at-top-when-scrolling)).
I had to add some extra CSS to make it look good when it overlaps the
content of the page, which the GOV.UK Frontend Toolkit implementation
doesn’t really anticipate.
The visual appearance of radio and checkbox form inputs changed in
GOV.UK Elements here:
https://github.com/alphagov/govuk_elements/pull/296
This was subsequently reimplemented with different markup and no
Javascript here:
https://github.com/alphagov/govuk_elements/pull/406
This has meant making the following changes to our app:
- changing the markup in our radio/checkbox macros to match the example
markup given by GOV.UK Elements
- removing the previous Javascript file because it’s no longer needed to
make the radios appear visual selected
- making the buttons on the scheduled job picker look like links,
because the grey button style looked weird with the new radio buttons
> 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.
Right now we use Javascript to focus the first error on a page (if any
errors are found). This commit adds more JS to then focus the error
summary, if there is one on the page. So this is where the focus will
rest.
It also makes some modifications to the ‘dangerous’ banner to make it
focusable, and to visually indicate that it is focused.
It’s weird to be on a page that says ‘2 seconds ago’ and stays stuck
there.
We don’t want to AJAX the whole page because it would get in the way of
interacting with the list of notifications.
This commit adds the venerable jQuery Timeago[1] plugin to keep the
relative times accurate and fresh.
1. http://timeago.yarp.com/
Because we’re not showing a summary of error messages screen reader users might
take a while to discover that there’s an error on the page. Since the only
real action on a page with errors is to correct them this commit adds some
Javascript to send focus straight to the first error message on a page.
A previous commit removed these to differentiate between this page and the
manage templates page. It turns out that we do want previews on this page
because:
- the users for the two pages might be different—they might only be allowed to
do one or the other depending what permissions they have
- it’s useful to see what the placeholders in the message are before uploading
a CSV, to make sure the CSV has the correct column headings
This commit re-adds the message preview with a simpler UI. Discussed with
@antimega and we both agreed that the speech bubble tails on the messages should
go.
ES6 has some nice new features. Specifically relevant to this piece of
work are:
Arrow functions[1], whose `this` context is bound the value of `this` in the
current scope and can’t be overidden. The code is cleaner as a result, and
doesn’t need the addition of a bind polyfill for older browsers.
Template strings[2], which are similar to triple-quoted multi line strings in
Python. This means less fiddly and error-prone string concatenation.
This commit adds Babel[3] to the Gulp pipeline. This transpiles Javascript
written to the ES6 specification into code which is compatible with older
browsers that don’t understand ES6 syntax.
It also rewrites the gulpfile itself using some ES6 syntax, for the same reasons.
1. https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Functions/Arrow_functions
2. https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/template_strings
3. https://babeljs.io
Users can add placeholders to their messages, eg
> …your vehicle ((registration number))
when the message is sent, this gets replaced with the data the user uploads, eg
> …your vehicle LC12 BFL
We reckon that it will be useful to see that the placeholder has been
recognised, ie that its syntax is correct, before uploading any data.
We reckon that the best way to do this is by styling it differently to the rest
of the text that the user types.
This is not a trivial problem. There are two possible ways to do it:
1 Write a Google Docs-style text rendering engine, which completely replaces
the native HTML `<textarea>` with a custom control, and programme what should
happen when the user types something that looks like a placeholder, or
presses an arrow key, or makes a selection, or…
2 Leave the `<textarea>` in place, unmodified, and duplicate layers in front
of/behind it to visually replace a placeholder with the blue lozenge
Unsurprisingly, this commit implements 2.
There are four layers. Each layer contains live-updated copy of the text in the
textbox, and each is styled differently:
- one layer behind the textbox to make the blue background
- the textbox itself
- a layer with the white text, which overlays the black text of the textbox
- a layer with an inner shadow to knock back the brackets
This is because of some interesting limitations:
- The text in the foreground and background must occupy the same physical space,
so no deleting characters from the duplicated layers
- Words can’t be split up into multiple elements,
eg `<span>((</span>regist…`:—this results in slightly different kerning to
`((regis…`, which messes up the alignment of the layers
- The textbox can’t be completely overlapped with a block of colour, because
the cursor disappears behind it. Trying to edit text when you can’t see the
cursor is hard.
Implementation
Technically this makes use of Paul Hayes work on Javascript modules in the
GOV.UK frontend toolkit[1].
It also makes use of the `oninput` event to detect changes to the textbox’s
contents. This is much more performant than `onkeydown`, `onpaste`, etc. Without
it the delay between user input and the layers all updating is too slow and you
see misalignment of the layers.
1. https://github.com/alphagov/govuk_frontend_toolkit/pull/227
…or how to move a bunch of things from a bunch of different places into
`app/static`.
There are three main reasons not to use Flask Assets:
- It had some strange behaviour like only
- It was based on Ruby SASS, which is slower to get new features than libsass,
and meant depending on Ruby, and having the SASS Gem globally installed—so
you’re already out of being a ‘pure’ Python app
- Martyn and I have experience of doing it this way on Marketplace, and we’ve
ironed out the initial rough patches
The specific technologies this introduces, all of which are Node-based:
- Gulp – like a Makefile written in Javascript
- NPM – package management, used for managing Gulp and its related dependencies
- Bower – also package management, and the only way I can think to have
GOV.UK template as a proper dependency
…speaking of which, GOV.UK template is now a dependency. This means it can’t be
modified at all (eg to add a global `#content` wrapper), so every page now
inherits from a template that has this wrapper. But it also means that we have a
clean upgrade path when the template is modified.
Everything else (toolkit, elements) I’ve kept as submodules but moved them to a
more logical place (`app/assets` not `app/assets/stylesheets`, because they
contain more than just SASS/CSS).
