-
-
Notifications
You must be signed in to change notification settings - Fork 8.5k
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
refactor(v2): apply common behavior to dropdowns #3578
Conversation
Deploy preview for docusaurus-2 ready! Built with commit 03ebc7c |
Strange, locally I have no errors 🤷♂️ |
thanks, looks better :) |
Do you consider it a breaking change? |
Yess, because after that the dropdown button will always be non-clickable. I don't think this is a big deal, but it's a breaking change nonetheless. |
oh, didn't see that @lex111 why do you prefer to make it non-clickable? I also find the behavior of the doctrine website confusing. Why do we need this link to not be clickable? The Bootstrap dropdown does not feel confusing, because the dropdown only opens on click, not on hover, so the cursor makes sense here. |
The Doctrine site is just an example of how Boostrap Dropdown works. I have looked at other sites with dropdowns by hover, and there is almost always link (dropdown button) that is not clickable. Moreover, clickable link makes it difficult to control from the keyboard. In this case, we need to go through all the dropdown items, although we only want to switch to the next navbar item.
That is why I named this behavior as "common". If we have a dropdown that opens on hover, then we need to ensure that they are well accessible from the keyboard.
It's an indicator of the current version, eg.
This will be fixed in Infima. |
Can't we make it clickable, and yet allow to open the link on enter? Removing the cursor would make it consistent, but still find it confusing that it shows the link on the browser bottom bar and that we can open a new tab with right click. I found this. shortcut convenient, particularly for those that don't have other navbar items on purpose (ie, no docs/api in our case). If we remove it, I guess we'd as well link to # or not use a link at all? |
In other words, if we browsing from the keyboard, we ignore the clickable link by pressing Enter key (since it is used to open/close the dropdown), and ordinarily (navigate via mouse), the clickable link works as expected, right? |
Another example - https://v3.vuejs.org/ /https://get.foundation/sites/docs/accordion.html or Gatsby https://www.gatsbyjs.com/ (click/hover on dropdown switch it.) |
You are right that the dropdown button does not usually link to anywhere. However, if you look at Vue3 ou Gatsby, the dropdown button is a button, not a link (unlike Foundation). I find it confusing to have a link that shows a browser status bar URL and that we can't click (ie current and Foundation behavior). I find it better if it's just a button and does not feel like a link, like Vue/Gatsby So what about using a button instead? (bonus if clicking it actually does something, like giving focus ring, or toggle open/close state...) |
Also, something quite important: for archiving purpose, I'd like to be able to build the site with a single version (like the oldest one) so that it can be deployed as a standalone deployment (will be needed for RN website). In such case, the dropdown should become a regular, clickable link (because a dropdown with a single version does not make sense) I think this behavior is not broken (as there's no items array) but just wanted to let you know about the plan ;) |
This is quite tricky as we are using highlighting mechanism ( We can handle the click on the dropdown button via the |
Although I just thought that manually switching the dropdown visibility (using |
It's hard for me to visualize what would be the result of your suggestions without a preview. What I'd like in the end is:
|
When navigating using keyboard, the user still won't be able to click the link in the dropdown button (because pressing Enter key will control dropdown visibility). Is that okay for you? If so, then I will implement this option. |
That seems acceptable, as there's the link in the dropdown items on which you can enter anyway. |
Motivation
I suggest changing the behavior of navbar dropdowns to make it more predictable and standardized.
FYI, Bootstrap dropdowns works in a similar way, you can look at the Doctrine website (for example) - https://www.doctrine-project.org/
BTW, this PR fixes the annoying bug where we cannot navigate back to the previous navbar items using the keyboard.
Have you read the Contributing Guidelines on pull requests?
Yes
Test Plan
Current behavior (dropdown opens by pressing Tab, which is not very flexible and hardly we always need it):
New behavior (dropdown opens by pressing Enter):
Related PRs
(If this PR adds or changes functionality, please take some time to update the docs at https://github.com/facebook/docusaurus, and link to your PR here.)