Add class .govuk-frontend-supported for ES modules support

[colinrotherham]

This PR updates the .js-enabled inline <script> to also append .govuk-frontend-supported

Only browsers with <script nomodule> support now run our JavaScript, which closes:

• Implement new class for early styling #3507

By additionally detecting 'noModule' in HTMLScriptElement.prototype (Safari 11+) we can "cut the mustard" and prevent early ES2015 class implementations from loading our components

[colinrotherham]

Do we need to follow our own advice and use the govuk-js-* prefix?

• Renames js- css prefix to govuk-js- #1444

Noticed whilst updating test setup to include the new class:

document.body.classList.add('govuk-frontend-supported')
$textarea.classList.add('govuk-js-character-count')

Side-by-side it looks like a typo

[romaricpascal]

Looking neat! 🙌🏻 Just added a little comment to clarify comments in the Character count test (but pre-approving). I think this closes #3509 as well, as any further discussion on what the component does when it can't initialise can be handled as part of our work on the component's public API #3479.

[romaricpascal]

Suggested change

	// Component checks that required elements are present
	document.body.classList.add('govuk-frontend-supported')
	// Component checks that GOV.UK Frontend is supported
	document.body.classList.add('govuk-frontend-supported')
	// Component checks that required elements are present

[colinrotherham]

Fine by me. Were you happy that we don't comply with our .govuk-js-* prefix in #3801 (comment)?

[romaricpascal]

Yup, I think that's fine as the purpose of each class is different:

• govuk-js-* for JS to grab specific HTML elements (and shouldn't be used for styling)
• govuk-frontend-supported set by JS to hook styles, so shouldn't have the -js- bit (we happen to re-use it for checking if we're supported; we could have set a window.GOVUKFrontendSupported = true but that makes the snippet longer)

[colinrotherham]

Brill, that's what I figured

Other services can freely use .govuk-js-* as advised by us

But we may see other "support classes" such as:

.govuk-frontend-supported
.govuk-prototype-kit-supported
.govuk-design-system-supported
.govuk-supported

[romaricpascal]

Yeah, I think that'll be perfectly fine if these classes pop up as well, allowing services to have their own cut on top of ours (hopefully coordinating with ours, though 😆 ). ⛵

[colinrotherham]

Thanks @romaricpascal

Let's merge this for now but aware we may still tighten the checks after:

• Finalise browser support table and get feedback #3511

For example we talked about raising the ES2015 bar to perhaps ES2018?

Reducing polyfills

For example this rough ES2018 feature detect for Promise.prototype.finally would avoid the need to ship polyfills to support browsers with potentially quite low visitor numbers:

'Promise' in window && 'finally' in window.Promise.prototype

Would give us loose assurance of the following:

1. Array.prototype.includes() (ES2016)
2. Object.values(), Object.entries() (ES2017)
3. Promise async/await support (ES2017)
4. Promise.prototype.finally support (ES2018)
5. Spread operator and rest ... parameters (ES2018)

ES2015 to ES2018 support gap

Querying against promise-finally can give us some good figures: