-
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
Try alternate style to indicate selected blocks #3068
Conversation
outline: 1px solid $light-gray-500; | ||
transition: 0.2s outline; | ||
// simpler style for a block that has cursor focus (but hasn't been selected) | ||
&.is-selected .editor-block-mover:before, |
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.
We may want to unify the className used for the hover
and selected
, maybe something like is-ui-visible
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.
My experience with this:
- It feels and looks nice,
- I don't feel the heavy blocks anymore.
- It looks like it's one and unique content editable (even if it's not)
- Sometimes it hard to know what are the limits where the inspector/block settings will apply. I don't feel it's blocking but maybe just something we'll get used to over time.
To my knowledge, system colors are deprecated in CSS3 and there's no guarantee they will work in the future. https://www.w3.org/TR/css3-color/#css-system
|
@@ -284,6 +297,29 @@ | |||
} | |||
} | |||
|
|||
// show a separate cursor/caret highlight style for when an item was selected by the mouse or keyboard (but isn't multi selected) |
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.
How would this scale? Is this something a block author should be able to opt into? What are the reasons for a block to be part of this group?
Let's try this. I think we can get it for 1.5 and get some feedback. I'd like to test it before getting the docked toolbar PR merged. |
Sorry I can't understand why you want to merge an officially deprecated CSS feature. |
Thanks for the reviews.
Answering these together, because they are related. The answer is it doesn't scale well, and I'm still thinking about the best way to do this. The idea is that when you have the cursor in text, the cursor itself is an indication of what is your focus. We need something like that, for when your "focus selection" is on something non text, like a separator — just to help you keep your place as to what's selected. There's also the thing that when we get across block keyboard selection with shift, the boundaries between paragraph blocks become less important. Whether the block itself is important to show the boundaries of, remains to be seen, which is why I asked for your thoughts. I think if we can do some improvements around multi selection (see the recent keyboard selection discussion), perhaps clicking the ellipsis or mover also selects the block (as in multi select indication), which will show the boundaries clearly. |
I added a fallback color. If for whatever reason the Alternatively we can change the color of the selection using |
5da160b
to
c3b07eb
Compare
I rebased this, because it happened to be branched when |
That's better 🙂 However, in my mind "deprecated" means "no use", especially in a new software. Note the Sitepoint post you linked to is from August 11, 2009. |
I understand the concern with using deprecated properties, but in this case we have fallback plans and alternatives, should they stop working. And while they are working, it seems like a nice usability win to use system colors. |
With the recent changes above, I believe this PR is ready for final review. As it won't go in 1.5, and folks are all busy getting that ship shape, I won't ping anyone, but anyone receiving these notifications, feel free to review when you're ready! |
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 looks good, after a rebase :)
c312dd1
to
c48d4cb
Compare
Thanks Ella for the review and thumbs up. The rebase was a bit tricky — my own fault for making so many commits — but could I ask for your eyes on this another time just to verify it's okay? |
It's important for some blocks, if we are to look at removing this entirely, let's do that as a separate PR. This does tweak the width to 1px though.
c48d4cb
to
00366f7
Compare
Rebased to pull #2988. |
Codecov Report
@@ Coverage Diff @@
## master #3068 +/- ##
==========================================
- Coverage 31.66% 30.81% -0.85%
==========================================
Files 217 217
Lines 6263 6529 +266
Branches 1112 1199 +87
==========================================
+ Hits 1983 2012 +29
- Misses 3600 3756 +156
- Partials 680 761 +81
Continue to review full report at Codecov.
|
editor/modes/visual-editor/block.js
Outdated
@@ -283,6 +283,7 @@ class VisualEditorBlock extends Component { | |||
], this.props.order + 1 ); | |||
} | |||
this.removeOrDeselect( event ); | |||
this.maybeStartTyping( event ); |
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.
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.
Pushed 118f489 to consolidate keydown handling, targeting arrow keys explicitly for triggering typing mode.
This reverts some previous refactoring that had split out removeOrDeselect
to a separate function, but I think the switch is a bit easier to reason about consistently. Otherwise maybe some mapping of keys and conditions (isTarget
) via something like cond
but seems overkill and prone to a performance impact on this performance-critical code.
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.
Looks good to me.
Let's 🚢 this. |
That is pretty funky indeed. Is that the stable channel? What's the normal selection color? |
I'll revisit. Thanks for the update. |
Description
This PR takes a first stab at some of the changes discussed/mocked up in #2983.
Basically it removes both the hover and selected styles for blocks, in favor of little floating mover/settings blobs on the side, and some subtler selection styles for a few blocks (separator, more, button).
Additionally, it changes the visual style of multi-selected blocks. Given incoming keyboard-multi-select features, this changes it so a multi selected block has the same color as highlighted text does. This uses a kind of magical CSS value,
Highlight
, which is documented in https://www.sitepoint.com/css-system-styles/. Video:This property is quite magical, and actually changes along with whatever choice you make at the operating system level:
It's a CSS 2.1 property and I've tested this color and found it working all the way back to IE9 (didn't test further).
I'm marking this as "In Progress", as I'd like both some code reviews, as well as some experience reviews. How does this feel? What feels good? What feels not so good? What else needs to be done in this branch? Any experience regressions?
Keep in mind that this is only one aspect of the visual refresh, you can see a list of other complimentary tasks here: #2983 (comment)
How Has This Been Tested?
Tested the color effect in Safari, Firefox, Chrome both on Mac and Windows, as well as Edge and IE9-11 on Windows. Not that we need 9 support, I was just impressed that the CSS property worked all the way back for that one.
Checklist: