-
-
Notifications
You must be signed in to change notification settings - Fork 32.4k
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
[TreeView] Add disabled prop #20133
[TreeView] Add disabled prop #20133
Conversation
@material-ui/lab: parsed: +0.35% , gzip: +0.33% |
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.
Thanks for working on this problem. I believe we can extend the reflection of #19967 to this case.
@oliviertassinari Sure, you want to set this as the default behavior or create a new prop as it was done in #19967? I believe that in this second case, it should be done in a separated PR |
You have not applied the aria-disabled attribute.
For example, irrelevant options in a radio group may be disabled. Disabled elements might not receive focus from the tab order. For some disabled elements, applications might choose not to support navigation to descendants. In addition to setting the aria-disabled attribute, authors SHOULD change the appearance (grayed out, etc.) to indicate that the item has been disabled. The state of being disabled applies to the current element and all focusable descendant elements of the element on which the aria-disabled attribute is applied. You can still select with the keyboard. Perhaps use context to pass disabled through for when disabling a parent node ? |
That's an important point that is currently not tested in this PR. @netochaves Would be nice if you could test behavior of child treeitems of a disabled treeitems.
This seems rather restrictive. Is this quoted from somewhere? We currently disable navigation in all our components. I think we can rethink this later similar to https://github.com/mui-org/material-ui/pull/19967/files |
I was referring to https://github.com/mui-org/material-ui/blob/f1a2ec4ebab84d1ffe7b71e9e31904a44efc26c1/packages/material-ui-lab/src/TreeItem/TreeItem.js#L403
This is the only place where behaviour changes due to the disabled prop being true ( all other changes are styling). This prevents focus by click, toggling expansion and selection. Yet, with the keyboard, you can focus, toggle expansion and select. |
Should we disable the expansion of a parent treeItem when it is disabled? |
I think so. disabled usually disables interaction. Since expansion is triggered by interaction it should not be possible. |
a39f870
to
a648641
Compare
Hey guys, there's still work to be done here? please let me know. |
a648641
to
7ea7461
Compare
@netochaves Thanks for the head start. I've updated the PR with some more use cases and added some tests. Still need to add a demo with some wording and make sure the styling is working. |
@@ -459,14 +479,12 @@ const TreeView = React.forwardRef(function TreeView(props, ref) { | |||
|
|||
const selectRange = (event, nodes, stacked = false) => { | |||
const { start = lastSelectedNode.current, end, current } = nodes; | |||
if (start != null && end != null) { |
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.
Was preventing arrow down + shift from working without an already selected node.
Keeping disabled nodes focusable was easier (and more correct in my opinion) |
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 think that we should demonstrate this in the documentation. I'm not sure about using the first basic demo as it's not a frequent use case. Maybe we could have a new demo, just before the last a11y section?
@oliviertassinari I agree. I don’t think the first demo should be re-used either. |
It's definitely an option but we never did this before. Just like selection follows focus we should make this configurable since you don't know if it makes more sense to keep a disabled item in tab order. The authoring practices encourage a consistent set of rules and this would go against it.
-- https://www.w3.org/TR/wai-aria-practices-1.1/#kbd_focus_activedescendant We can definitely rethink our current set of rules but breaking them because it's easier for us is not really a helpful rationale. If it's hard to get right in a first PR we should definitely add a warning for now. But if we don't have a viable plan to make it work later we should rethink this feature. It seems to me that the path of least resistance is chosen and justified after the fact. |
7c92e97
to
4749555
Compare
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.
- editorial suggestions
- did you take a look at [TreeView] Add disabled prop #20133 (comment)?
- Reverted the changes that introduced
createStyles
where it is not necessary
Great catches! Co-authored-by: Sebastian Silbermann <[email protected]>
Thanks for the head start @netochaves |
Closes #19975
This PR adds a new disabled prop to TreeItem