Make the editor canvas friendly towards colored backgrounds #6406

jasmussen · 2018-04-25T10:47:20Z

One long term vision for the editor, is to allow you to load the theme stylesheet into the editor canvas itself, so you have an almost if not completely WYSIWYG experience where the theme background and fonts apply to the editor.

In the interim, we should make it easier to load editor styles into the canvas. This already works today, but the block UI is not really ready for it — white backgrounds are used here and there, and borders are colored light grays which quickly disappear on some colors.

This PR takes an initial stab at alleviating that, by moving to using various levels of opacities of the darkest gray we have, to emulate the range of opaque grays we have. As such, this PR includes a range of those opacities. For example, shown on a white background, $dark-opacity-500 should look the same as $dark-gray-500, but the latter should look good on colored backgrounds as well.

This is going to be a fair bit of work, and this is only the beginnings of it. It styles the borders, the outermost toolbar borders, the naked mover/settings/more icons, and the title field, as well as the appender. In doing this, it now means you can at least change the background color and still sort of use the editor.

Asking for thoughts now, before I do more work — what do you think of this approach?

If there's positive agreement on this direction, I will fix the drag and drop shadows/colors. Note that this PR makes the UI work on light backgrounds. If you cross a certain threshold of luminosity into the dark background territory, we need to invert the colors. This PR already contains the opacities for that, but we'll need to detect the background color and apply a body class, something like body.has-dark-background, so that I can invert the UI for that. Would appreciate thoughts on this too.

Video: https://cloudup.com/cDX4dvMYFvs

paulwilde · 2018-04-25T11:35:55Z

Looks good from what I saw in the video.

I also had the same considerations with different opacities based on if the BG is light/dark. To be honest, I cannot think of a different approach than this to add background support... so I think this is the best approach on that basis.

Something I've picked up upon from adding this on a prior site built in Gutenberg and watching the video you've attached is that the hover states of the buttons need a white background as otherwise the border looks kinda ugly.

jasmussen · 2018-04-25T11:41:30Z

Cool, thanks for the initial sanity check, Paul. I'll let this branch sit for a bit further, but then take a stab at making further improvements.

Something I've picked up upon from adding this on a prior site built in Gutenberg and watching the video you've attached is that the hover states of the buttons need a white background as otherwise the border looks kinda ugly.

Yep — that's a solid point, and something I'll add. 🤘

afercia · 2018-04-25T12:53:39Z

Hmm... giving themes the power to modify the UI could potentially break any colors contrast ratio for accessibility. I'd tend to think Gutenberg should preserve the accessibility of its own interface, maybe reserving some light background around its controls.

Also, using opacity will make a bit difficult calculating the contrast ratio... as we won't be able to pick up the actual color from the CSS (or browser inspector), inteaad we'll have to use tools that pick up the colors rendered on screen 🙂

karmatosed · 2018-04-25T14:58:53Z

In theory this seems like a good idea on unification. I absolutely agree with breaking it down. Before I review though, how does (if at all) fit in with: #5360?

I also wonder a little from an accessibility view but right now we have that with editor styles. Maybe we can consider what boundaries we do/don't let people style?

jasmussen · 2018-04-25T17:42:53Z

Before I review though, how does (if at all) fit in with: #5360?

Ah yes, excellent memory, thanks for bringing that back on my mind, I'd forgotten it totally.

Re-reading that post, it seems like this PR could still be complementary. I.e. we want to allow themes to load an editor style into the editor, and style every block. If a theme then opts-out of "opinionated styles" as Matías calls it, those styles would simply not load in the editor, and the theme would not have to deal with them, either in the editor or on the frontend. In that vein it would be similar to a theme that has not opted into wide images — they can still style the editor with an editor style.

jasmussen · 2018-04-25T17:47:20Z

Responding separately due to the feedback from two angles:

I'd tend to think Gutenberg should preserve the accessibility of its own interface, maybe reserving some light background around its controls.

and

I also wonder a little from an accessibility view but right now we have that with editor styles. Maybe we can consider what boundaries we do/don't let people style?

Both good observations and thoughts. Given the overall positive reception this PR has engendered, I think this is what I'll tackle next. I feel like we have many options on the table, such as just always showing the filled-out buttons behind the side UI, or looking at things like inversion filters or mix-blend-mode, to guarantee sufficient contrast in the case of selection styles or placeholder colorings. Those are vague concepts I haven't yet dived into, but they are tools in our toolbelt that we can explore, and I think they can help us get to a point where the UI will always have contrast (for example a total inversion, when necessary, should always have sufficient contrast by definition).

That said, a badly designed theme will always be able to work around these for non-UI aspects, such as providing light gray text on a white background. Enforcing that seems like a task for the theme-review team, if at all.

weavertheme · 2018-04-27T14:58:35Z

I created a more or less duplicate issue #6451 (sorry to dup - I find it very hard to search existing issues)

I thnk some of the default colors on these edit controls certainly can use improvement, but I also now think this could be a theme requirement. It is possible to get very nice looking controls using just code listed in #6451. Letting the theme handle control styling alleviates trying to get a one-size-suites all solution.

@maddisondesigns

This updates the extensibility document, and adds a section around loading editor styles. It gives examples for how to change the colors of the editor (which will look good once #6406 gets merged), as well as how to change the width of the editor. The last part fixes #1483. CC: @maddisondesigns

One long term vision for the editor, is to allow you to load the theme stylesheet into the editor canvas itself, so you have an almost if not completely WYSIWYG experience where the theme background and fonts apply to the editor. In the interim, we should make it easier to load _editor styles_ into the canvas. This already works today, but the block UI is not really ready for it — white backgrounds are used here and there, and borders are colored light grays which quickly disappear on some colors. This PR takes an initial stab at alleviating that, by moving to using various levels of opacities of the darkest gray we have, to emulate the range of opaque grays we have. As such, this PR includes a range of those opacities. For example, shown on a white background, $dark-opacity-500 should look the same as $dark-gray-500, but the latter should look good on colored backgrounds as well. This is going to be a fair bit of work, and this is only the beginnings of it. It styles the borders, the outermost toolbar borders, the naked mover/settings/more icons, and the title field, as well as the appender. In doing this, it now means you can at least change the background color and still sort of use the editor. Asking for thoughts now, before I do more work — what do you think of this approach? If there's positive agreement on this direction, I will fix the drag and drop shadows/colors. Note that this PR makes the UI work on _light_ backgrounds. If you cross a certain threshold of luminosity into the dark background territory, we need to invert the colors. This PR already contains the opacities for that, but we'll need to detect the background color and apply a body class, something like `body.has-dark-background`, so that I can invert the UI for that. Would appreciate thoughts on this too.

jasmussen · 2018-05-02T08:40:20Z

Okay, pushed some polish, and I think this is ready for final review.

This PR now:

Adjusts all the UI on the canvas to be friendly to theme styles. Previously white backgrounds are now transparent, and previously gray buttons are now semi transparent.
Multi selections now use mix-blend-mode to ensure that the selection is always visible.

Please review any contrast issues that might have come up as part of this — I've tried my best to match the new opacity based grays to the existing grays, but if there are any regressions, they are easy to adjust.

Default — this should ideally look the same as before:

Light theme:

I also included colors that work based on dark themes. But this is not yet activated anywhere. Essentially we need to apply an is-dark-theme class to the body element, to invert the UI colors to use shades of white instead of shades of dark gray for the side UI and borders. This PR is ready for that class to exist, but how that class is best added should probably be explored separately. What do you think? Here's how the dark theme looks:

Let me know your feedback.

@maddisondesigns

) * Update theme extensibility documentation to include editor widths This updates the extensibility document, and adds a section around loading editor styles. It gives examples for how to change the colors of the editor (which will look good once #6406 gets merged), as well as how to change the width of the editor. The last part fixes #1483. CC: @maddisondesigns * Simplify syntax a bit. * Trim whitespace

paulwilde · 2018-05-02T09:14:24Z

editor/components/post-title/style.scss

+		border: 1px solid $dark-opacity-light-500;
+
+		.is-dark-theme & {
+			border: 1px solid $light-opacity-light-500;


border-color: $light-opacity-light-500;

paulwilde · 2018-05-02T09:15:00Z

editor/components/block-toolbar/style.scss

-}
+
+	.edit-post-header-toolbar__block-toolbar & {
+		border-left: 1px solid $light-gray-500;


border-left-color: $light-gray-500;

paulwilde · 2018-05-02T09:15:22Z

editor/components/block-list/style.scss

+	border: 1px solid $dark-opacity-light-500; 
+
+	.is-dark-theme & {
+		border: 1px solid $light-opacity-light-500; 


border-color: $light-opacity-light-500;

paulwilde · 2018-05-02T09:15:49Z

editor/components/block-list/style.scss

+		outline: 1px dashed $dark-opacity-light-500;
+
+		.is-dark-theme & {
+			outline: 1px dashed $light-opacity-light-500;


outline-color: $light-opacity-light-500;

paulwilde · 2018-05-02T09:16:22Z

editor/components/block-list/style.scss

+		border-right: 1px solid $dark-opacity-light-500;
+
+		.is-dark-theme & {
+			border-right: 1px solid $light-opacity-light-500;


border-right-color: $light-opacity-light-500;

paulwilde · 2018-05-02T09:16:41Z

editor/components/block-list/style.scss

+		border-left: 1px solid $dark-opacity-light-500; 
+
+		.is-dark-theme & {
+			border-left: 1px solid $light-opacity-light-500;


border-left-color: $light-opacity-light-500;

paulwilde · 2018-05-02T09:16:55Z

editor/components/block-list/style.scss

+		outline: 1px solid $dark-opacity-light-500;
+
+		.is-dark-theme & {
+			outline: 1px solid $light-opacity-light-500;


outline-color: $light-opacity-light-500;

paulwilde · 2018-05-02T09:18:54Z

Just left a few comments where it's probably best to set only the colour when is-dark-theme is applied. Otherwise you would need to update the border/outline widths/styles twice in future.

Just a small nitpick really, heh.

noisysocks

Code LGTM! 🌈✨ I tested this locally and the only bug I noticed was that, when using a dark background, the controls in a column block don't have visible icons:

noisysocks · 2018-05-16T00:23:20Z

edit-post/components/visual-editor/style.scss

@@ -67,7 +67,7 @@

 // This is a focus style shown for blocks that need an indicator even when in an isEditing state
 // like for example an image block that receives arrowkey focus.
-.edit-post-visual-editor .editor-block-list__block:not( .is-selected )   {
+.edit-post-visual-editor .editor-block-list__block:not( .is-selected ):not( [data-type="core/paragraph"] )   {


Why not paragraphs?

Good question. This branch has been around long enough that I don't recall adding this — could it have come in as part of a rebase and later been removed?

In any case I removed it again becaues I couldn't see any regressions as a result.

noisysocks · 2018-05-16T00:23:43Z

editor/components/block-list/style.scss

@@ -1,6 +1,6 @@
 .components-draggable__clone {
 	& > .editor-block-list__block > .editor-block-list__block-draggable {
-		background: $white;
+		background: $white; // @todo: ensure this works with themes that invert the color


Has this been done?

No, and I'm not sure that this can be done. At least I'm open to ideas here.

The thing is, the draggable clone has to have a background, or you can see the text below through it. It would be nice if we could eyedrop the color of the body, but even then a user could've applied a background image or pattern.

noisysocks · 2018-05-16T00:28:41Z

editor/components/block-toolbar/style.scss

+	.edit-post-header-toolbar__block-toolbar & {
+		border-left-color: 1px solid $light-gray-500;
+	}
+}


Missing a new line at the end of the file here.

jasmussen · 2018-05-16T08:21:25Z

Thanks for the review, @noisysocks! I pushed some changes to address your comments. Except for this one #6406 (comment) because I'm not sure how to best address that.

However, given that is-dark-theme is currently sort of a "hidden feature", I feel like the white background is a decent enough compromise for light themes, and then we can hopefully revisit this aspect if/when we enable dark theme support.

jasmussen · 2018-05-17T07:12:53Z

CC: @jorgefilipecosta — can you rebase your nested blocks for cover image branch and see if this improves things?

mcsf · 2018-05-19T11:38:48Z

I believe this introduced regression #6836, fixed in #6844.

youknowriad · 2018-05-19T11:45:20Z

edit-post/assets/stylesheets/_z-index.scss

@@ -3,8 +3,8 @@
 // value is designed to work with).

 $z-layers: (
+	'.editor-block-list__block-edit:before': 0,


Not certain why this change was required but it broke the PlainText inside blocks (code block for instance). It should be fixed by this though #6844

jasmussen · 2018-05-22T07:17:46Z

My apologies for the regression, and thank you for fixing it!

jasmussen added the [Status] In Progress Tracking issues with work in progress label Apr 25, 2018

jasmussen self-assigned this Apr 25, 2018

jasmussen requested a review from a team April 25, 2018 10:47

jasmussen mentioned this pull request Apr 25, 2018

Implement nesting in cover image block #5452

Closed

jasmussen force-pushed the try/bg-color-friendly branch from 407bfcf to e54bfdb Compare April 26, 2018 14:22

chrisvanpatten mentioned this pull request Apr 27, 2018

Editor pop-up editing symbols need to be theme BG color neutral #6451

Closed

2 tasks

jasmussen force-pushed the try/bg-color-friendly branch from e54bfdb to 1f0dcee Compare May 1, 2018 08:35

jasmussen mentioned this pull request May 1, 2018

Block width (content width) needs to be resizeable #1483

Closed

jasmussen force-pushed the try/bg-color-friendly branch 3 times, most recently from d46948f to 087c016 Compare May 1, 2018 11:17

jasmussen mentioned this pull request May 2, 2018

Update theme extensibility documentation to include editor widths #6531

Merged

jasmussen force-pushed the try/bg-color-friendly branch from 087c016 to 05386b8 Compare May 2, 2018 07:44

Add dark mode tweaks

5f5868e

jasmussen force-pushed the try/bg-color-friendly branch from 7bde1c8 to 5f5868e Compare May 2, 2018 08:35

jasmussen added Needs Design Feedback Needs general design feedback. and removed [Status] In Progress Tracking issues with work in progress labels May 2, 2018

paulwilde reviewed May 2, 2018

View reviewed changes

Address feedback

3272f0d

karmatosed approved these changes May 2, 2018

View reviewed changes

noisysocks removed the Needs Design Feedback Needs general design feedback. label May 16, 2018

noisysocks requested changes May 16, 2018

View reviewed changes

Address feedback.

64c91c5

jasmussen added this to the 2.9 milestone May 16, 2018

noisysocks approved these changes May 17, 2018

View reviewed changes

Darken the side UI slightly, it was too light

4c1e095

jasmussen merged commit af65418 into master May 17, 2018

jasmussen deleted the try/bg-color-friendly branch May 17, 2018 07:12

youknowriad reviewed May 19, 2018

View reviewed changes

chrisvanpatten mentioned this pull request Jun 8, 2018

[Try] Alternate design for block side controls #7211

Closed

4 tasks

afercia mentioned this pull request Aug 31, 2018

Input placeholder text must have a sufficient color contrast ratio #9502

Closed

afercia mentioned this pull request Jul 6, 2023

Fix Site editor page when JS support is disabled #52376

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Make the editor canvas friendly towards colored backgrounds #6406

Make the editor canvas friendly towards colored backgrounds #6406

jasmussen commented Apr 25, 2018

paulwilde commented Apr 25, 2018 •

edited

Loading

jasmussen commented Apr 25, 2018

afercia commented Apr 25, 2018

karmatosed commented Apr 25, 2018 •

edited

Loading

jasmussen commented Apr 25, 2018

jasmussen commented Apr 25, 2018

weavertheme commented Apr 27, 2018

jasmussen commented May 2, 2018

paulwilde May 2, 2018 •

edited

Loading

paulwilde May 2, 2018 •

edited

Loading

paulwilde May 2, 2018 •

edited

Loading

paulwilde May 2, 2018 •

edited

Loading

paulwilde May 2, 2018 •

edited

Loading

paulwilde May 2, 2018

paulwilde May 2, 2018

paulwilde commented May 2, 2018 •

edited

Loading

noisysocks left a comment

noisysocks May 16, 2018

jasmussen May 16, 2018

noisysocks May 16, 2018

jasmussen May 16, 2018

noisysocks May 16, 2018

jasmussen commented May 16, 2018

jasmussen commented May 17, 2018

mcsf commented May 19, 2018

youknowriad May 19, 2018

jasmussen commented May 22, 2018

Make the editor canvas friendly towards colored backgrounds #6406

Make the editor canvas friendly towards colored backgrounds #6406

Conversation

jasmussen commented Apr 25, 2018

paulwilde commented Apr 25, 2018 • edited Loading

jasmussen commented Apr 25, 2018

afercia commented Apr 25, 2018

karmatosed commented Apr 25, 2018 • edited Loading

jasmussen commented Apr 25, 2018

jasmussen commented Apr 25, 2018

weavertheme commented Apr 27, 2018

jasmussen commented May 2, 2018

paulwilde May 2, 2018 • edited Loading

Choose a reason for hiding this comment

paulwilde May 2, 2018 • edited Loading

Choose a reason for hiding this comment

paulwilde May 2, 2018 • edited Loading

Choose a reason for hiding this comment

paulwilde May 2, 2018 • edited Loading

Choose a reason for hiding this comment

paulwilde May 2, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

paulwilde commented May 2, 2018 • edited Loading

noisysocks left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jasmussen commented May 16, 2018

jasmussen commented May 17, 2018

mcsf commented May 19, 2018

Choose a reason for hiding this comment

jasmussen commented May 22, 2018

paulwilde commented Apr 25, 2018 •

edited

Loading

karmatosed commented Apr 25, 2018 •

edited

Loading

paulwilde May 2, 2018 •

edited

Loading

paulwilde May 2, 2018 •

edited

Loading

paulwilde May 2, 2018 •

edited

Loading

paulwilde May 2, 2018 •

edited

Loading

paulwilde May 2, 2018 •

edited

Loading

paulwilde commented May 2, 2018 •

edited

Loading