Style details in older browsers

[domoscargin]

Part of #3464

What

We're removing the JavaScript polyfill for the <details> element.

We need to ensure that the component is not styled to suggest it can be expanded in browsers that do not natively support the <details> element.

Browser support for the <details> component: https://caniuse.com/?search=details

Wrap "link-like" styles in a CSS Feature Query

We can wrap most of the Details styles in a feature query which excludes EdgeHTML:

/* 
 * -ms-ime-align is only supported on Edge 12 - 18.
 * Additionally, most older browsers that don't support the <details> component don't support feature queries
 * and will ignore everything inside the feature query block
 */
@supports not (-ms-ime-align: auto)

This covers the vast majority of browsers (about 97%), which behave as expected.

Hack for Internet Explorer

IE doesn't support the <details> element, so we can style it to look like inset text.

Internet Explorer 11

Default to browser-native styles

For browsers which support <details>, but not CSS feature queries, we simply default to their styles for the <details> element, plus some added font and spacing.

Chrome 27

Android 4.1 (emulated)

Gaps

Browsers which support feature queries, but not <details> or es6 module will still have "linkified" styling, but not be interactable. This largely applies to Opera Mini and early Firefox.
https://browsersl.ist/#q=supports+css-featurequeries+and+not+supports+details+and+not+supports+es6-module&region=GB

This represents around 0.18% of browsers in the UK, and is even more minimal on the latest stats I have for GOV.UK (where the affected Firefox versions account for about 0.001% of traffic).

Firefox 48

[querkmachine]

This looks good to me, code wise!

I do find it a bit weird visually, however, as on non-<details> browsers the summary now looks like regular prose but reads like it's meant to be akin to a section heading.

I know it isn't a section heading (or, at least, we don't want it to be one semantically), but the lack of any visual difference is a bit jarring. Should we get a designer to give this a look over?

[querkmachine]

This margin is being ignored in EdgeHTML Edge. It seems like you need to maintain the display: inline-block for this to be applied correctly.

[domoscargin]

Hmm, I can't reproduce this via Browserstack in Edge 15 - 18. What are you getting?

[querkmachine]

The style appears in the inspector's style and computed tabs, but if you hover over the element so that the box model is highlighted on the page you can see that the margin-bottom value hasn't actually been used, even though it's not crossed out.

The difference can also be seen if you do a side-by-side comparison with the existing review app—the border of the <details> contents has moved up by 5 pixels.

I'm not sure why EdgeHTML devtools says the style is being used when it actually isn't, but I'm gonna chalk that up to EdgeHTML devtools maybe not being amazing. 😝

[domoscargin]

Aah, nice spot! My basic trust in devtools is forever tainted.

[domoscargin]

It seems like you need to maintain the display: inline-block for this to be applied correctly.

Done. Looking good so far.

[domoscargin]

I do find it a bit weird visually, however, as on non-<details> browsers the summary now looks like regular prose but reads like it's meant to be akin to a section heading.

I know it isn't a section heading (or, at least, we don't want it to be one semantically), but the lack of any visual difference is a bit jarring. Should we get a designer to give this a look over?

Hard agree! I was trying not to introduce any new styles, but it does feel a bit awkward.

[domoscargin]

A few styling alternatives:

Bold text

Use govuk-heading-s styles

Use govuk-heading-m styles

Hide summary text, keep border

Hide summary text, no border

Hide... everything?

[christopherthomasdesign]

Hi thanks for sharing this! I'm wondering if it might look a bit more together if the summary text was made visually part of the same block:

That makes it appear basically like an inset text with a heading (I used govuk-heading-s here which I think looks right). I personally don't have an issue with that – without the show/hide-ness that a details gives, it's probably about the right amount of visual prominence.

It does look slightly different to an inset text, because we use different border widths. But maybe that's a problem for another day!

What do you think?

[domoscargin]

I can style it pretty much like an inset text in older browsers (now just have to figure out how to not make it look insane on modern browsers!).

One thing that immediately brings up on the review app at least, is that details html with headings can look a bit weird.

[domoscargin]

Moving back to draft while I work on these notes.

[domoscargin]

I've had a go at styling everything to look like inset text on older browsers.

This means I've styled the component to look like inset text by default, then overridden these styles within the feature query. I've highlighted specific overrides with comments.

Obviously having the overrides peppered in is not as neat as just adding "linkifying" styles within the feature query, so very open to suggestions.

Edit: I still have to test these changes cross-browser, but I don't think they'll cause any issues.

[domoscargin]

I've had a look at our supported browsers and Opera Mini, and the components behaves as it should.

In older browsers, the "inset-text" fallback looks good and matches the inset text component.

Beyond Opera Mini, the gaps only come in when we start looking at 0.01% coverage and below, with Firefox 44, 43 and 36 displaying the "linkified" details summary, but not supporting details. I looked into using the new supported class via :not(.govuk-frontend-supported), but these older browsers don't support not. I'm fairly content that this gap is small enough.

[domoscargin]

Another set of browsers I hadn't considered before simply because they're all from 2014 and earlier and I hadn't tested that far back.

Browsers that support the <details> element, but don't support type=module or CSS feature queries will currently display an amalgam of the inset text-like styles and default <details> styles.

https://browsersl.ist/#q=%3E0.00001%25+and+supports+details+and+not+supports+es6-module+and+not+supports+css-featurequeries&region=GB

Currently not exactly sure how to target these using only CSS, or whether it's worth the effort (given that these browsers represent less than 0.1% of GOV.UK visits).

[domoscargin]

I've pushed a change to default to browser native styles. This is to cover browsers which support <details> but not feature queries.

IE 8 - 11 get styled like inset text via a hacky selector.

Here's a table summarising what happens:

Supports <details>	supports es6-module	Supports CSS feature queries	Notes.	Coverage
Yes	Yes	Yes	Captured in feature query	95.7%	✅
Yes	No	Yes	Captured in feature query	0.76%	✅
No	Yes	Yes	Edge 16 - 18, captured in feature query	0.02%	✅
No	No	No	Captured in IE 8 - 11 hack	0.09%	✅
No	Yes	No		0%	✅
Yes	Yes	No		0%	✅
Yes	No	No	Fall back to native details, with some extra font and padding styles	0.69%	🟠
No	No	Yes	Essentially just Opera Mini. These will have the interactable styles, but not be interactable.	0.18%	🔴

Note: "Coverage" refers to browserslist data for the UK.

[36degrees]

😍

[stevenjmesser]

Adding to this PR a conversation we had elsewhere: we're comfortable with this impacting 0.18% of browsers as the interaction will break in a way that won't prevent users completing their task. The link won't work on clicking it, but text is still visible. @domoscargin also mentioned that 0.18% is estimated use across the UK, which translates to 0.004% on GOV.‌UK.

[domoscargin]

Adding another conversation from elsewhere: We've kept the IE hack in because of the inertia of support for IE11, but we don't believe it'd be breaking to remove those styles to trim down our CSS in the future when IE11 support is even lower - it'd look a bit worse, but still be fully functional.