-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PostPublishPanel: return focus to element that opened the panel #11543
Conversation
This approach gotchas:
|
ce47e64
to
5067de3
Compare
0c91e4b
to
4075b57
Compare
5067de3
to
0f99f9d
Compare
0f99f9d
to
4f9a323
Compare
So, against my original concerns, this PR has ended up being a fine approach. It is ready for review. The only thing I wonder is whether we should deprecate the toggle component. Normally, I'd do it, but given the point we're at in the release cycle I'd want to hear more opinions. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm unclear on whether #11584 needs to be merged before this will work as intended—is that the case?
Right now after closing the panel focus seems lost and is not returned to the element that opened it (the "Publish" button).
For what it's worth: if we aren't using the But then we're past API freeze and should respect that, maybe we deprecate it as normal and remove it in a few versions, recognising that that'll be after WordPress 5.0. |
- Do not unmount Header settings components. - Hide the "Save draft" button because it's not hidden by the PostPublishPanel slide-in sidebar.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll try this again a bit later today after I'm back from squash, but for now I have a few change requests regarding the deprecations.
Any chance you could record a screencast of this working on your machine? It would help to see what you're seeing 😄
packages/edit-post/src/components/header/post-publish-button-or-toggle.js
Show resolved
Hide resolved
<PublishButtonLabel forceIsSaving={ forceIsSaving } /> | ||
{ componentChildren } | ||
<DotTip tipId="core/editor.publish"> | ||
{ __( 'Finished writing? That’s great, let’s get this published right now. Just click “Publish” and you’re good to go.' ) } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find "Just" to be a weasel word and would like to remove it, but I know that's a bit out-of-scope for the PR. Just saying' 😆
packages/editor/src/components/post-publish-panel/test/toggle.js
Outdated
Show resolved
Hide resolved
@tofumatt Added a GHIF in the description. This is what I've done (the image is not great):
At this point, the Publish button has the focus although it's disabled. Then, I've done a few Tabs and Shift+Tab to move focus among the Header settings components forward and backward to demonstrate it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tested this locally and now it's working perfectly. Thanks so much!
I left a few suggestions but once they're addressed 🚢
Thanks so much for this! Once it's merged, all the Gutenberg merge accessibility issues are covered! 🎉
docs/reference/deprecated.md
Outdated
@@ -1,5 +1,9 @@ | |||
Gutenberg's deprecation policy is intended to support backwards-compatibility for releases, when possible. The current deprecations are listed below and are grouped by _the version at which they will be removed completely_. If your plugin depends on these behaviors, you must update to the recommended alternative before the noted version. | |||
|
|||
## 4.6 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Best to keep this consistent with the rest of the file:
## 4.6 | |
## 4.6.0 |
<div className="edit-post-header__settings"> | ||
<div className="edit-post-header__settings"> | ||
{ ! isPublishSidebarOpened && ( | ||
// This button isn't completely hidden by the publish sidebar. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
This is an awesome, super-helpful comment. Ace!
const toggleProps = { | ||
'aria-disabled': isToggleDisabled, | ||
'aria-expanded': isOpen, | ||
className: 'editor-post-publish-panel__toggle', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
editor-post-publish-panel__toggle
seems like the right name.
EDIT: oops, I meant editor-post-publish-button__toggle
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Damn, looks like we shouldn't be deprecating stuff here:
Might be best to remove that for now. Really sorry, I thought deprecations would continue as normal, but seems like the mechanism will be different going forward, so for now maybe we shouldn't.
The changes of #11679 are not really relevant to speaking to whether or not a thing can be deprecated still. The changes there are merely a reflection of the fact that the dependency becomes unused once the current deprecations are removed. |
Right, but I thought @youknowriad was saying deprecations after 4.3 we don't know how we'll handle them. Maybe I'm confused and these deprecations are fine? I'm confused 😅 |
Since we said we're in API Freeze, yes I did say that and I think we should be more strict now to keep our engagements. We shouldn't deprecate anything impactful. I think |
Fair enough then; changed back to approved 😄 |
We're actually going to merge this into 4.3; I'll take it over from here and tweak the deprecations. Thanks again for working on this 👍 |
isPrimary | ||
isLarge | ||
onClick={ onClick } | ||
disabled={ isButtonDisabled } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For what reason did we need to stop passing the disabled
prop? While this and many other buttons in the header appear as disabled, they don't act as disabled. You can immediately press "Publish" on a new post and the publish panel is (wrongly?) shown.
As it relates to focus return, it's not clear to me how it's relevant, since the panel would have presumably never been opened if it were disabled.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch. #13194 should fix it.
The disabled
property didn't play well with the withFocusReturn
HOC, IIRC. I can dig up the exact details if necessary.
Addresses the last bit of #4187 (comment)
Depends on #11584Closes #4187
Description
This PR manages where focus goes after the PostPublishPanel is closed. At the moment, it's lost and just goes to the body element.
Changes this PR introduces:
withReturnFocus
HOC to return focus to the element that had it before opening the publish sidebar.PostPublishButton
how to behave like a button (publish directly) or a toggle (opens the publish sidebar instead).Questions
PostPublishToggle
in favor of thePostPublishButton
component in this PR We'll go with deprecating it and removing it in 5.1.