hidden="until-found" usage broken in browsers lacking support

[lb-]

Issue Summary

• The new expanding panels do not appear to be collapsing at all in some browsers.

Steps to Reproduce

1. Load up Wagtail main branch
2. Sign in to the home page
3. Attempt to collapse any of the panels on the dashboard page (or any page in the admin)
4. Expected - should collapse
5. Actual - the chevron changes, the aria-hidden attribute changes, but the panel's content still is visible

Any other relevant information.

• Appears to be a compatibility issue with the usage of hidden until found https://caniuse.com/mdn-html_global_attributes_hidden_until-found_value
• Maybe it is also due to the CSS styling around this attribute usage
• It might be good to not try to use this until-found feature until we know a bit more about it (depending on time available for 4.0 RC)

wagtail/client/scss/generic/_normalize.scss

Lines 59 to 63 in 3576e27

	// See https://github.com/necolas/normalize.css/pull/879.
	[hidden='until-found'] {
	/* stylelint-disable-next-line declaration-no-important */
	display: revert !important;
	}

wagtail/client/src/includes/panels.ts

Lines 15 to 20 in 3576e27

	} else {
	// Use experimental `until-found` value, so users can search inside the panels.
	// Browsers without support for `until-found` will ignore the value and just `display: none` the panel.
	content.setAttribute('hidden', 'until-found');
	}

Technical details

• Wagtail version: main branch (4.0 WIP)
• Browser version:
• Works - Chrome Version 106.0.5216.6 (Official Build) dev (x86_64)
• Fail - Safari Version 15.4 (17613.1.17.1.6)
• Fail - 103.0 (64-bit)

Screenshots

Safari

Firefox

[lb-]

Broke when adopting the new panels code via #8921
FYI @thibaudcolas

[PaarthAgarwal]

I'm able to replicate this issue on firefox and edge in Linux 20.03.

[lb-]

PR up for a browser feature detection fix for this (JS side)
#8962

Solution from https://developer.chrome.com/articles/hidden-until-found/#caveats

This article also explains the hidden until found feature really well
https://github.com/WICG/display-locking/blob/main/explainers/hidden-content-explainer.md

If we do ever adopt the details semantic element for expanding panels, it appears that there is a similar and somewhat simpler behaviour that allows text search to trigger visibility.

https://html.spec.whatwg.org/#interaction-with-details-and-hidden=until-found

Looks like Safari iOS is still the laggard for support of details elements with headers https://a11ysupport.io/tech/html/summary_element

[thibaudcolas]

I have merged #8962 as-is (thank you for putting this together @lb-!). Will re-open this so we look for another fix, as the solution is specific to panels while the until-found issue is with the CSS reset applying to the whole of the admin here:

https://github.com/wagtail/wagtail/blob/main/client/scss/generic/_normalize.scss#L54-L63

Right now it’s only the panels that use this but I think it’s important we make this usable for other parts of the admin and custom code too.

---

The issue seems to be with the revert keyword, which I wasn’t expecting to completely remove even browser / user-agent styles:

If used by a site's own styles (the author origin), revert rolls back the property's cascaded value to the user's custom style, if one exists; otherwise, it rolls the style back to the user agent's default style.

I’m not sure where what we’re observing comes from. Maybe a special case of the style being from an attribute rather than an element. The least-work would probably be to change our reset to:

[hidden]:not([hidden="until-found"]) {
  /* stylelint-disable-next-line declaration-no-important */
  display: none !important;
}

I was hoping there would be a way to do this without increasing the specificity of that selector, but since we use !important anyway this isn’t really a concern. Other creative solutions welcome!

Edit: on <details> – I don’t think we can use it for this. Its <summary> is a <button>, and the DOM structure it requires is very different from how our forms are structured, so it’d require very creative HTML/CSS to make this work, and likely custom JS on top anyway.

[thibaudcolas]

For anyone following this – I don’t think I’ll be able to look into this further until the very end of the month. I’ll keep this assigned for myself to look at then, but if you think this is more urgent please go for it.

[gasman]

So, while this is a wider issue than #8962 addresses, it sounds like it isn't actually manifesting as a bug anywhere else - this is more about addressing technical debt. As such, I think we can reasonably bump this to 4.1.