Preview v5: Update to use <script type="module">

[colinrotherham]

No description provided.

[netlify]

✅ You can preview this change here:

Name	Link
🔨 Latest commit	ceef53a
🔍 Latest deploy log	https://app.netlify.com/sites/govuk-design-system-preview/deploys/64c298890820dd000889725e
😎 Deploy Preview	https://deploy-preview-2958--govuk-design-system-preview.netlify.app/
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[colinrotherham]

Example <iframe> pages now use application-example.mjs

We adjust initAll() from GOV.UK Frontend to turn off auto focus

[colinrotherham]

For application.mjs we can use the default initAll() from GOV.UK Frontend

[36degrees]

I've not had a chance to do a full review but two things that stand out to me I wanted to note down before I forget:

1. Unless we split our analytics and cookie banner JavaScript out, browsers that don't support type="module" will disappear from our analytics. That may well be OK, but we need to make sure that it's a conscious choice and that anyone looking at our analytics data is aware of that.
2. We may want to move towards putting any scripts with type="module" in the head, given they are deferred.

[colinrotherham]

• Unless we split our analytics and cookie banner JavaScript out, browsers that don't support type="module" will disappear from our analytics. That may well be OK, but we need to make sure that it's a conscious choice and that anyone looking at our analytics data is aware of that.

Yeah, tricky isn't it

Typically I'd suggest a server-side rendered version with <form> that works without JavaScript, using a Netlify function to manage cookies. Enhance with new CookieBanner() for instant show/hide on button presses, no POST delays

It's where the GOV.UK Publishing ES6 to ES5 idea came from, so we could alternatively use Babel just on the Cookie banner component? Lots of risk

Otherwise I'd assumed we were happy to lose the cookie banner by design 😬

I'd love to solve this though

• We may want to move towards putting any scripts with type="module" in the head, given they are deferred.

I'm happy with this for the Design System website. We do add minor risk to First Contentful Paint (FCP) since the render-blocking CSS download may be delayed by a concurrent script download (albeit much lower priority)

[36degrees]

As discussed on Slack, we're happy that we don't need to split out the JavaScript for our analytics or cookie banner.

This means that users visiting the Design System using a browser that does not support type="module" will no longer appear in our analytics once this change goes out. We're OK with this given that between April 2023 and June 2023, out of 11,751 users:

• only 17 (0.14%) were using a browser that does not support type="module" and so would not have appeared in our analytics data
• 67 (0.57%) were using a browser that may not support type="module" and may not have appeared in our analytics data (we can't tell because the data available to us is inconclusive)

---

Raw data

Browser	Version	Users	Sessions	Supports type="module
Safari (in-app)	(not set)	63	66	?
Safari	10	5	5	N
Internet Explorer	11	3	3	N
Chrome	42.0.2311.111	2	2	N
Chrome	47.0.2526.106	1	1	N
Chrome	56.0.2924.87	1	1	N
Chrome	59.0.3071.92	1	1	N
Firefox	31	1	1	N
Firefox	33	1	4	N
Mozilla Compatible Agent	5	1	1	?
Safari	9	1	1	N
Samsung Internet	7.2	1	1	N
UC Browser	11.3.5.1203	1	1	?
UC Browser	13.4.2.1307	1	1	?
YaBrowser	16	1	1	?

[36degrees]

• We may want to move towards putting any scripts with type="module" in the head, given they are deferred.

I'm happy with this for the Design System website. We do add minor risk to First Contentful Paint (FCP) since the render-blocking CSS download may be delayed by a concurrent script download (albeit much lower priority)

Let's leave this for now – maybe worth exploring in the future, if so we can look at running webpagetest and compare the two approaches?

[36degrees]

I think the code changes generally look fine, but the experience for users on older browsers is suboptimal because we need to also update the Design System to use the new govuk-frontend-supported class rather than js-enabled, which requires a preview branch or pre-release.

Happy to approve this without those changes, but to makes sure we don't forget can you please create an issue for the govuk-frontend-supported changes and assign it to the v5 milestone?

[colinrotherham]

Thanks @36degrees, yeah it's awful isn't it

I've followed the steps we took to upgrade GOV.UK Frontend in alphagov/govuk-frontend@7e1d0f4

Tests will be broken (no .govuk-frontend-supported in the template) but this PR comes next:

• Preview v5: Skip initialisation when GOV.UK Frontend is not supported #2976

Happy to approve this without those changes, but to makes sure we don't forget can you please create an issue for the govuk-frontend-supported changes and assign it to the v5 milestone?

Do you want an issue making for the other PRs?

[colinrotherham]

Rebased with the preview release in:

• Updates for GOV.UK Frontend v5.0.0 #2977