Enhance the Accordion component with hidden='until-found'
#3053
Conversation
|
Ah this is great, ties in nicely with the
Where HTML validation for |
I think we have prior art for this in the header component, and could do something similar here too? govuk-frontend/src/govuk/components/header/_index.scss Lines 222 to 225 in 14d3c64 |
|
Unfortunately, seemingly not. Applying Trying something fancy with negation (like I think the solution here is to feature detect whether the browser supports |
|
Sounds sensible – from reading MDN it sounds like Something like [hidden] {
display :none;
@supports (content-visibility: hidden) {
content-visibility: hidden; /* may not even be needed, as all browsers that support content-visibility: hidden probably have default UA styles? */
display: inherit;
}
}We could also wait until 5.x when we no longer need to care about IE10! |
|
It even words in "tweener" browsers—i.e. versions of Chrome released between |
Previously, browsers that did not have a user agent style for the `hidden` attribute (such as IE 10 and below) would always show section content, regardless of whether the section was expanded or collapsed.
[hidden='until-found']hidden='until-found'
|
Really nice improvement – It'd be great to get this shipped 🙌🏻 Given this uses
So it might be worth comparing the behaviour with and without this change to check if anything's changed?
In my testing, the details element already takes care of this for us – if you search for terms hidden inside a details element, it'll expand automatically to reveal the content. Because our styling hooks on to the |
|
@36degrees My earlier poke at this seemed to show that the accessibility tree was rendering and being updated as expected, though admittedly that was only checked in latest Chrome. The issues described in those articles were (seemingly) fixed in Chrome 90. |
|
A general comment to say that I'll do one final pass against browsers to be belt and bracers once this is moved out of draft but based on the chat in the PR so far I'm feeling positive. |
|
Percy is being a bit odd. On edge it shows the accordions as default open. I'm unsure what could be causing this? Maybe some sort of version mish mash. I personally don't think this is a blocker for live but if we're able to figure out why this is happening that'd be neat. |
|
@owenatgov I think what I wrote in the initial content-y bit was my best guess as to why Percy is returning different:
Is Percy taking its screenshots before the bulk of Frontend's JS has kicked in? In the past, the accordion will already have been collapsed at this point (via CSS and JS inlined in the template), but now it won't until the accordion has been initialised. |
|
@querkmachine That'll be it. I don't think this is a showstopper but it probably is something for us to consider if we want to continue using percy and run into other cases where we move away from relying on |
There was a problem hiding this comment.
Code looking good.
Working across browsers.
Accessibility wise this seems to be operating as expected and from a bit of research, Chrome 90 is on the extreme low end of use.
Cracking work 💪🏻
Something worth recording is that in IE9 the accordion looks a little odd with a big border at the bottom. See screenshot below. This was already there however so it's not a regression and it's not stopping users from reaching the content. It may even be captured somewhere else.
@querkmachine It's been fab reading through this PR 🎉 Percy wise, we've just got the 100ms default Can try dropping in a .percy.js config into the project root, seeing if a longer timeout helps settle things down? Does this mean users will see the same flicker through as sections close after init? |
Yes, but I personally think this isn't a problem and is actually an improvement. Previously, if the stylesheet loaded but the network request for
Now, the accordion's content remains visible up until the component JS has successfully downloaded and initialised. |
|
Ah I see the benefit, I just know Google unfavourably ranks websites with high "cumulative layout shift" as users prefer a stable layout when JavaScript kicks in. Having unclickable section headings is still a valid point though |
When loading the Accordion component with JavaScript enabled, this change restores `display: none` on section content For context, we switched to `display: inherit` previously: #3053 But for slow-loading pages we saw a visual layout shift as each section flickered closed (from open) after initialisation We’d like to take another look at how components load in: #999
When loading the Accordion component with JavaScript enabled, this change restores `display: none` on section content For context, we switched to `display: inherit` previously: #3053 But for slow-loading pages we saw a visual layout shift as each section flickered closed (from open) after initialisation We’d like to take another look at how components load in: #999
When loading the Accordion component with JavaScript enabled, this change restores `display: none` on section content For context, we switched to `display: inherit` previously: #3053 But for slow-loading pages we saw a visual layout shift as each section flickered closed (from open) after initialisation We’d like to take another look at how components load in: #999
When loading the Accordion component with JavaScript enabled, this change restores `display: none` on section content For context, we switched to `display: inherit` previously: #3053 But for slow-loading pages we saw a visual layout shift as each section flickered closed (from open) after initialisation We’d like to take another look at how components load in: #999
until-foundis a new value for thehiddenattribute, that allows a user agent's find-in-page functionality to search the text inside of elements that are currently collapsed. It serves as a progressive enhancement to the existinghiddenboolean attribute, falling back to the default behaviour in browsers that don't support the new value.It was introduced at the same time as the
beforematchJavaScript event, allowing us to see which element on the page the "found" text is contained within.Currently the new attribute value and JavaScript event are only supported in Chromium-based browsers (including Google Chrome, Microsoft Edge, Opera, and Samsung Internet).
Linked to #2697. I previously did a small, hackier investigation into this at the start of August. See my previous comment for the outcome of that.
Changes in this spike
hidden="until-found"attribute using JavaScript.js-enabledclass. It now requires both the class and for the accordion's JavaScript to have been initialised before anything is hidden.hidden="until-found"on it is not removed from the box model (it usescontent-visibility: hidden, notdisplay: noneunlike booleanhidden) so the padding was always visible.beforematchevent handler and function to correctly change the state, styles and button labels in the event of a match by the user agent.hiddenattribute upon a match, but would not change any other parts of the accordion.Other thoughts
This would seem to be a non-breaking change in terms of service teams, unless a team has customised the styles of the section content box. As this element is no longer completely ignored when rendering the box model, any styles (such as borders, background colours, margins or padding) may become visible even when the section is collapsed.
This probably poses a larger issue for legacy Internet Explorer support. This is currently relying on user agent stylesheets to be clever and apply eitherResolved, see discussion below.content-visibility: hiddenordisplay: nonedepending on the value (or lack) of thehiddenattribute. IE 10 and below don't support thehiddenattribute at all, so adisplay: nonerule would need to be applied for those browsers without compromising those that supporthidden="until-found".This functionality would seemingly want to be mirrored to the Details component, however we are relying solely on the user agent's own functionality to provide the expand/collapse feature in modern browsers.