Contain [aria-busy] toggling within Frames
#442
Conversation
Setting `[aria-busy="true"]` on the `<html>` element during a
`<turbo-frame>` navigation might be too aggressive given the frame's
value proposition of a compartmentalized request-response cycle. If
applications style the page based on `html[aria-busy="true"]`, having
that toggled during (eager or lazy) Frame loading could lead to a
disorienting experience.
If that isn't the case for applications, they can synchronize the
attribute themselves with a `MutationObserver`:
```js
const observer = new MutationObserver(([ { target } ]) => {
document.documentElement.setAttribute("aria-busy", target.busy)
}, { subtree: true, attributeFilter: ["busy"] })
observer.observe(document.body)
```
|
I think if we can't use aria-busy in a uniform way, we should use data-turbo-busy, and then leave it as an exercise for the app to choose when aria-busy might make sense for their flow. |
|
I think Turbo's usage of The issue this change is addressing would be the same with Imagine an application that renders a page-wide spinner instead of a progress bar. If a This change aims to contain |
Document the changes introduced in [hotwired/turbo#199][] and [hotwired/turbo#442][]. [hotwired/turbo#199]: hotwired/turbo#199 [hotwired/turbo#442]: hotwired/turbo#442
|
Ahhh, I misunderstood the original issue. Yes, that this is about turbo-frame being self-contained. Not whether aria-busy or not makes sense. I thought you meant it wouldn't work for the turbo-frame. Yup, all good with this then. |
|
Switching to const observer = new MutationObserver((mutations) => {
for (const { target } of mutations) {
if (target.localName == "html") {
// somehow determine if the change was initiated by a `<turbo-frame>` element or a page visit
} else if (target.localName == "form" || target.localName == "turbo-frame") {
target.setAttribute("aria-busy", target.hasAttribute("data-turbo-busy"))
}
}
}, { subtree: true, attributeFilter: ["data-turbo-busy"] })
observer.observe(document.body)That's possible, but the issue feels the same for |
|
You could actually make a fair case that aria-busy should not be set on html, but that data-turbo-busy should. Since you might have a global style spinner. But... I think it's fine to see how this is going to be used first. |
Setting
[aria-busy="true"]on the<html>element during a<turbo-frame>navigation might be too aggressive given the frame'svalue proposition of a compartmentalized request-response cycle. If
applications style the page based on
html[aria-busy="true"], havingthat toggled during (eager or lazy) Frame loading could lead to a
disorienting experience.
If that isn't the case for applications, they can synchronize the
attribute themselves with a
MutationObserver: