Polish the new multi-select style #18867
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
We probably don't need the small icon of three blocks selected as it is not used systematically. Otherwise, great stuff! |
|
The PR needs to be rebased. Visually, I think this PR is a definite improvement over As for additional improvements, I think a blue block border around multi-selected blocks would be a good improvement over the current left border (which, as you mentioned, is not visible for full-width blocks). |
ellatrix
approved these changes
Dec 4, 2019
jasmussen
force-pushed
the
polish/multi-select
branch
from
6690870 to
717c56e
Compare
|
Thank you! Rebased and will merge when the checks pass. |
|
Thoughts:
|
|
Both stellar ideas, Ella. When we get to those, feel free to ping me if I can help. |
jasmussen
force-pushed
the
polish/multi-select
branch
from
717c56e to
b6ff923
Compare
ZebulanStanphill
added a commit
that referenced
this pull request
Dec 4, 2019
6 tasks
ZebulanStanphill
added a commit
that referenced
this pull request
Dec 4, 2019
|
Thank you for the fix, Zeb! |
jasmussen
added a commit
that referenced
this pull request
Dec 12, 2019
The new native selection style is much faster and an important step on the path to various writing-flow improvements. However until we can get closer to those improvements, in the mean time selecting multiple blocks is currently slightly less clear than it was prior to the native selection change. In #18867 I tried to mitigate this, and it includes some mockups for how to improve the style longer term, with more thoughts being discussed in #18667. But until that gets hashed out more clearly, perhaps we should rewind the visual style slightly, to be closer to what was, while still keeping the technical benefits of the native selection PR. This PR keeps those changes, but tweaks the visual style. What it does is remove the left border style, and re-paints a cross-block background. But this time with a color that is closer to the default selection color on Windows and MacOS. Specifically, both those defaults are eye-dropped and averaged to create a new color that looks at home on both. It is possible users can customize this select color, meaning the color of the selection marker inside text will diverge from that of multi-block selections. But this is unfortunately not something we can address. But the averaged color feels like a pretty good interim step towards a selection model that is perhaps closer to that of Figma, painting borders around each block instead of re-coloring the background.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In #16835, a new native selection style was introduced when selecting across blocks. This solves an accessibility issue with coloring the selection style, and enables the "inactive browser selection color" to work.
It also surfaced some small issues, notably one around nested blocks reported in #16835 (comment), and one with the placeholder selection seeming off.
In this PR I tried to tackle both. Worth noting that with multi-selection, we offer two indicators of selection:
To improve the nesting situation, I limited that style to top level blocks:
To improve the placeholder issue, I made the selection style transparent there, as it is misleading, suggesting you copy the text from the placeholder description. Given the presence of the additional marker, the one referred to in 2 above, it shouldn't be necessary:
To me, the above feels like a good first step at polishing the multi-select experience. However it also highlights some issues that perhaps deserve more love, notably:
It seems like some of the efforts being explored in #18667 could inspire a better visual style for multi-selection. In that vein, I explored using the suggested visuals to imagine some new options.
Selecting Text:
It remains to be seen how feasible this is. We discussed it a bit in #16811 (comment), but if it is possible, then selecting between two text blocks should look as it does in every other text editor — like so:
As suggested, text blocks would make up the exception to the multi select rules, and as soon as you select beyond text and into another type of block, you'd get something more familiar. Perhaps something like this:
The above is inspired by Navigation/Selection mode, and works to establish a singular style for when a block is actually selected (i.e. where when you press Delete, the blocks are removed).
I don't believe the following is possible, because it might need an additional wrapper around selections, and being aware of wide/fullwide scenarios. But if it were possible (JS positioned border?), It seems like the following would be even better:
... that is, 1px borders around each individual blocks, and a 2px border that surrounds the whole selection. @ellatrix would appreciate your thoughts!