As pointed out in https://github.com/WordPress/gutenberg/pull/25622#issuecomment-699091615 by @shaunandrews, we should investigate whether it would make sense to render navigation-panel as the first element within the the interface-skeleton, and potentially moving navigation-toggle__button outside of skeleton__header too.
This might help with transition animations, tab ordering, and fixing alignment issues of other elements in the header.
Quoting @shaunandrews' comment for context:
Now that you mention it, I find it strange that the
navigation-panelis being rendered _inside_ theskeleton__body; Wouldn't it make more sense to render it above theskeleton__header, as the first element within the theinterface-skeleton? Taking this even further, perhaps thenavigation-toggle__buttondoesn't belong in theskeleton__headereither. I think moving these components outside the header and body could help with both the transition and an alignment issue that has popped up in https://github.com/WordPress/gutenberg/pull/25630.
I think moving these components outside the header and body could help with both the transition and an alignment issue that has popped up in #25630.
Note:
The alignment issues mentioned by Shaun have since been solved by leveraging flex-basis to center the document settings labels in #25630.
Moving the panel and toggle button, however, seems like it's still worth exploring to potentially solve two remaining issues:
1. Unintuitive keyboard navigation (@shaunandrews do we want Shift + Tab to focus the toggle button?)
Shift+Tab from the back button doesn't focus the "Toggle Navigation" button, but the last element of the header toolbar.
This is consistent with the Inserter's behaviour, and it makes sense technically (both navigation and inserter are "physically" rendered at the end of the header), but not so much if one wanted to easily close the sidebar after opening it.
2. Animation issues (@vindl could you confirm this? I'm not seeing syncing issues locally)
The animation of toggle and sidebar slide in are a bit out of sync. It's not that noticeable because of short duration. If we want to match them perfectly we could switch to linear animation, since I don't think we can perfectly match cubic bezier ones in general.
@jeyip
The animation issue was caused by the sidebar and toggle button requiring different animations.
The button had to animate the width from 60 to 300px; the sidebar the translateX from -300px to 0 (or something like that).
The idea was: let the button animation wait until the sidebar slides in to "join" the button, and then have them slide together. This was probably impossible with Guten's default cubic bezier animation.
The workaround was to have a linear animation instead, making the delay calculation easy, and removing the concern of adjusting the after-delay curve.
Maybe if button and sidebar were "together", there would be a way to use one single cubic bezier animation taking care of both.
Let me also add that imho this is not a big deal. The animation is 0.1s long, so it's not very noticeable anyway.
On the other hand, having the sidebar near the button would help us a lot with the keyboard navigation.
I'm not an a11y expert, but I'd argue that not having to manually adjust the keyboard nav would be a great improvement overall.
We might not even need to manually move the focus from Toggle to Back to Dashboard on sidebar toggle, but just let the user do it with a simple tab press.
What I'd love to see is this tab order (in both directions), which I think should happen "for free" if we manage to place the sidebar right in the middle of the Toggle and Inserter buttons 馃
@Copons Thanks for the context! Much appreciated 馃檪 The reasoning makes sense, and I'm currently working on implementing what you're describing in a draft PR.