Skip to content
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

EuiColorPicker uses standard portal DOM positioning, intentional popover entrance #2038

Merged
merged 9 commits into from
Jun 14, 2019

Conversation

thompsongl
Copy link
Contributor

@thompsongl thompsongl commented Jun 12, 2019

Summary

Uses the idea behind #1988 to address positioning inconsistency when EuiColorPicker is placed in a popover. Often, the problem can be "fixed" with position: fixed, but we can should do better.

The immediate change here is that the nested EuiPortal is no longer injected within the color picker component tree. Instead, it uses its shallow, late placement in the DOM to always ensure positioning (like other EuiPopover things).

The second change would resolve #1988, if accepted. It takes the concept from #1914 (comment), which asserts that popover-aided form elements should generally behave like native select elements:

Tabbing

Tab to focus on input only
Space/Enter to open popover and focus within
Space/Enter to select and close popover (back to focus just on input)

Mouse

Click on input
Focuses input and opens popover

The fundamental changes:

  • No auto-opening & auto-focusing popover without user intention, which makes tabbing through a form without selection is possible.
  • Cyclical tabbing no longer focuses the input after leaving the last swatch, which is more inline with other EUI pseudo-form elements (EuiComboBox, et al.).
  • An extra button (dropdown arrow; certainly open to design ideas) that (IMO) aids VO and keyboard usability.
  • More manual key press handling, but better z-index and positioning management math by fully embracing the EUI Platform™.

Checklist

- [ ] This was checked in mobile

  • This was checked in IE11
  • This was checked in dark mode

- [ ] Any props added have proper autodocs

  • Documentation examples were added
  • A changelog entry exists and is marked appropriately
  • This was checked for breaking changes and labeled appropriately
  • Jest tests were updated or added to match the most common scenarios
  • This was checked against keyboard-only and screenreader scenarios

- [ ] This required updates to Framer X components

top: 0,
});
const [lastColor, setlastColor] = useState<HSV | {}>({});
export const EuiSaturation: FunctionComponent<EuiSaturationProps> = forwardRef(
Copy link
Contributor Author

@thompsongl thompsongl Jun 12, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This diff is unfortunate. The gist is that I added forwardRef and a single ref, which changes a bunch of indentation. Nothing important to review in the file.

Copy link
Contributor

@chandlerprall chandlerprall left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code changes LGTM; Tested mouse & keyboard interaction locally, including with the added container example.

The popover is not closable by keyboard when focus is still on the color picker, tabbing off of the color picker's elements allows Escape to close the popover. I'm not sure if this should be a blocker or not.

@thompsongl
Copy link
Contributor Author

The popover is not closable by keyboard when focus is still on the color picker

ENTER and ESC should close the popover pretty much wherever focus is. Where're you seeing this happen?

@cchaos
Copy link
Contributor

cchaos commented Jun 13, 2019

I honestly don't think this component needs the dropdown arrow. It just adds noise and extra tab to get out of the input. I do think it needs better VO instruction when you tab into it since all you get is:

Screen Shot 2019-06-13 at 15 08 58 PM

For me, when the picker is in a popover, and I escape to close the picker, it doesn't focus back on the input like the normal one does.

But I think that's the only flaw I saw.

@chandlerprall
Copy link
Contributor

ENTER and ESC should close the popover pretty much wherever focus is. Where're you seeing this happen?

The color picker's popover closes, but a parent popover won't close if the input box has focus

input box focused

In the above state pressing Escape has no effect.

@thompsongl
Copy link
Contributor Author

better VO instruction

Yep. On it.

For me, when the picker is in a popover, and I escape to close the picker, it doesn't focus back on the input like the normal one does.

The popover thing was a mistake a made in the docs. Fixed now. I did notice that the modal steals focus no matter what, though (you can see it happen with the select in the first example here: https://elastic.github.io/eui/#/layout/modal). I'm going to open an issue for it.

I honestly don't think this component needs the dropdown arrow. It just adds noise and extra tab to get out of the input

I could see this (as @snide mentioned at one point) being more like EuiSelect, where the arrow is just a visual indication and does not have button qualities. Would that be better?

@chandlerprall
Copy link
Contributor

I honestly don't think this component needs the dropdown arrow. It just adds noise and extra tab to get out of the input.

I'll dissent, but not strongly. I navigate form fields primarily with the keyboard, and I don't think I would discover that the color picker opens without some visual indication. Maybe I would try the up & down arrows to see if it some how modifies the field value, and find instead that Down opens an interactive widget.

My 2¢, take it or leave it :)

@cchaos
Copy link
Contributor

cchaos commented Jun 13, 2019

Yeah I'm also thinking forward with the editor style controls. Having the arrow there really takes up valuable space. So I guess there is an option to show it for normal controls and hide it for compressed?

@snide
Copy link
Contributor

snide commented Jun 13, 2019

where the arrow is just a visual indication and does not have button qualities

Also think the arrow, even if it's just an indication and not a button (which I still think is fine to make just visual), is helpful to be there. Even in @cchaos' mock above... yes, it does add visual noise, but even with that gradient there it lets me know the gradient itself is clickable and will probably do something (even if I don't know what that something is). I think it's useful the same way the carets are useful on old fashioned primary, filled buttons. It just telegraphs what happens next.

@thompsongl
Copy link
Contributor Author

thompsongl commented Jun 13, 2019

The color picker's popover closes, but a parent popover won't close if the input box has focus

Yay @chandlerprall found a popover bug. If you have an EuiPopover in an EuiPopover, the child one stops propagation of the ESC event, even if the child EuiPopover is not open: https://codesandbox.io/embed/working-eui-xvll4

I'll open a bug for this


Bug: #2042

@thompsongl
Copy link
Contributor Author

Latest commit makes the arrow a visual indicator only. See how that feels.

Copy link
Contributor

@cchaos cchaos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like I'm outnumbered 😜 I'm happy that it's not a button at least and maybe we can revisit just the "compressed" version when those get implemented.

@thompsongl thompsongl merged commit 878c963 into elastic:master Jun 14, 2019
@thompsongl thompsongl deleted the colorpicker-portaling branch June 14, 2019 15:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

EuiColorPicker focus & popover behavior
4 participants