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

Try alternate style to indicate selected blocks #3068

Merged
merged 12 commits into from
Oct 27, 2017
Merged

Conversation

jasmussen
Copy link
Contributor

@jasmussen jasmussen commented Oct 19, 2017

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:

behavior

This property is quite magical, and actually changes along with whatever choice you make at the operating system level:

itshappening

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:

  • My code is tested.
  • My code follows the WordPress code style.
  • My code follows has proper inline documentation.

@jasmussen jasmussen added the [Status] In Progress Tracking issues with work in progress label Oct 19, 2017
@jasmussen jasmussen self-assigned this Oct 19, 2017
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,
Copy link
Contributor

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

Copy link
Contributor

@youknowriad youknowriad left a 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.

@afercia
Copy link
Contributor

afercia commented Oct 19, 2017

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

CSS2 system colors
Deprecated.

Note. The CSS2 System Color values have been deprecated in favor of the CSS3 UI ‘appearance’ property. If you want to emulate the look of a user interface related element or control, please use the ‘appearance’ property instead of attempting to mimic a user interface element through a combination of system colors.

@@ -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)
Copy link
Member

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?

@mtias
Copy link
Member

mtias commented Oct 19, 2017

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.

@afercia
Copy link
Contributor

afercia commented Oct 19, 2017

Let's try this.

Sorry I can't understand why you want to merge an officially deprecated CSS feature.

@jasmussen
Copy link
Contributor Author

Thanks for the reviews.

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.

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?

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.

@jasmussen
Copy link
Contributor Author

To my knowledge, system colors are deprecated in CSS3 and there's no guarantee they will work in the future.

I added a fallback color. If for whatever reason the Highlight color won't work, the background will be used instead.

Alternatively we can change the color of the selection using ::selection? But this seems like a better approach.

@pento pento force-pushed the try/alternate-block-style branch from 5da160b to c3b07eb Compare October 19, 2017 16:15
@pento
Copy link
Member

pento commented Oct 19, 2017

I rebased this, because it happened to be branched when master was going through an awkward buggy phase.

@afercia
Copy link
Contributor

afercia commented Oct 19, 2017

I added a fallback color. If for whatever reason the Highlight color won't work, the background will be used instead.

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.

@jasmussen jasmussen removed the [Status] In Progress Tracking issues with work in progress label Oct 20, 2017
@jasmussen
Copy link
Contributor Author

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.

@jasmussen
Copy link
Contributor Author

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!

Copy link
Member

@ellatrix ellatrix left a 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 :)

@jasmussen jasmussen force-pushed the try/alternate-block-style branch from c312dd1 to c48d4cb Compare October 24, 2017 13:46
@jasmussen
Copy link
Contributor Author

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?

Joen Asmussen added 5 commits October 25, 2017 15:15
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.
@mtias mtias force-pushed the try/alternate-block-style branch from c48d4cb to 00366f7 Compare October 25, 2017 13:15
@mtias
Copy link
Member

mtias commented Oct 25, 2017

Rebased to pull #2988.

@codecov
Copy link

codecov bot commented Oct 25, 2017

Codecov Report

Merging #3068 into master will decrease coverage by 0.84%.
The diff coverage is 0%.

Impacted file tree graph

@@            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
Impacted Files Coverage Δ
editor/modes/visual-editor/block.js 0% <0%> (ø) ⬆️
blocks/library/code/index.js 50% <0%> (-7.15%) ⬇️
blocks/editable/format-toolbar/index.js 5.19% <0%> (-1.19%) ⬇️
editor/block-toolbar/index.js 0% <0%> (ø) ⬆️
blocks/library/shortcode/index.js 50% <0%> (ø) ⬆️
editor/writing-flow/index.js 0% <0%> (ø) ⬆️
blocks/library/image/block.js 0% <0%> (ø) ⬆️
blocks/editable/index.js 11.96% <0%> (+1.53%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6e984b0...118f489. Read the comment docs.

@@ -283,6 +283,7 @@ class VisualEditorBlock extends Component {
], this.props.order + 1 );
}
this.removeOrDeselect( event );
this.maybeStartTyping( event );
Copy link
Member

Choose a reason for hiding this comment

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

This is just to see how it feels—I like that arrow keys trigger "typing" mode now. But we'd want to exclude modifier keys, etc. cc @iseulde @mcsf

Copy link
Member

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.

Copy link
Member

Choose a reason for hiding this comment

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

Looks good to me.

@mtias
Copy link
Member

mtias commented Oct 27, 2017

Let's 🚢 this.

@mtias mtias added [Feature] Blocks Overall functionality of blocks General Interface Parts of the UI which don't fall neatly under other labels. Design labels Oct 27, 2017
@mtias mtias merged commit efa08a0 into master Oct 27, 2017
@mtias mtias deleted the try/alternate-block-style branch October 27, 2017 14:04
@aduth
Copy link
Member

aduth commented Nov 9, 2017

Noted today that the multi-select system highlight color is pretty extreme in Firefox (56.0.2, macOS 10.12.6)

Firefox Multi-Select

@jasmussen
Copy link
Contributor Author

That is pretty funky indeed. Is that the stable channel? What's the normal selection color?

@afercia
Copy link
Contributor

afercia commented Nov 9, 2017

Firefox on Windows (IE 11 and Edge use the same color, Chrome a lighter one):

screenshot 118

@aduth
Copy link
Member

aduth commented Nov 9, 2017

The normal selection color in Firefox is more reasonable, only the darker blue when multi-select takes effect.

image

@jasmussen
Copy link
Contributor Author

I'll revisit. Thanks for the update.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Blocks Overall functionality of blocks General Interface Parts of the UI which don't fall neatly under other labels.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants