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 G2 #19344

Merged
merged 63 commits into from
Feb 25, 2020
Merged

Try G2 #19344

merged 63 commits into from
Feb 25, 2020

Conversation

youknowriad
Copy link
Contributor

@youknowriad youknowriad commented Dec 27, 2019

closes #18195
closes #18069
closes #18223
closes #16617
closes #19624
closes #7646
closes #19018
closes #12260
closes #15489
closes #20086
closes #4287
closes #9522

This branch should be used to serve as a base branch for all updates related to this issue #18667 that can't land individually.

For now, it contains:

  • Movers moved to the toolbar Move the block movers to the block toolbar #18685
  • Change the block toolbar borders to black.
  • Simplify hover/focus and radius styles for Buttons.
  • Remove is-selected styles and replace with focus styles.
  • white placeholders with dotted background.
  • Block Switcher with an arrow on the corder of block toggle.
  • New Dropdown Menu styles.
  • No arrow indicator for dropdowns.
  • Update the icons used.

@karmatosed
Copy link
Member

I am just exploring this a little and I feel the dots on the placeholders are a bit much with text. I personally find it hard to read. I wonder if a balance could be done to make them less strong @jasmussen?

g2visualissues

For me, there is an almost wave visual created that doesn't help text read clearly.

@karmatosed
Copy link
Member

Another issue is with screens where multiple white backgrounds show and a theme isn't white, this feels a lot and like the focus hierarchy is a little misaligned:

toomanybackgrounds

@karmatosed karmatosed added the Needs Design Feedback Needs general design feedback. label Jan 6, 2020
@jasmussen
Copy link
Contributor

I would tend to agree specifically with the dots as they are. They are meant to indicate the presence of a grid which blocks align themselves to. This is probably an aspect of the design that is worth postponing implementing until we can actually support a grid for the blocks.

I'm catching up on a few things today, but will give this PR a spin as soon as I can, perhaps help push some polish as well!

@jasmussen
Copy link
Contributor

jasmussen commented Jan 7, 2020

Thanks so much for taking a stab at this, Riad! I'm very excited to see the new UI explored, and I've been wondering how to best do it. I'm increasingly leaning towards a big switch, like this, rather than implementing things piecemeal.

I took this for a quick spin today, and it's exciting to explore as a prototype currently and as something that can grow into the real thing. There are a lot of little things I can help fix in code — the right black, the right border radius, the right spacing for icons, the right menu treatment, the right placeholder treatment, right toolbar positioning — mostly a massaging of pixels. But it's also likely going to be a great deal of CSS and code refactoring (touching a lot of files), so I'm currently pondering how to best help, rather than just jumping in and pushing code.

To be sure, this is the right branch to work in, correct? Or should I work in your "g3" branch instead?

One thing that does seem worth exploring separately, is any conversations around icons and fonts, which are tentatively explored also in the #18667 ticket.

@youknowriad
Copy link
Contributor Author

The reason for g2 and g3 branches is that I think we can probably land half of the changes (all the changes within the canvas) before the other half (the panels, the bordered dropdowns).

So if it's something in the canvas itself, push to this PR (and potentially rebase g3 on top of it) and if it's outside the canvas, it's the other one.

That said, if you don't think that split make sense, we can work on a single branch for everything. I personally do like 2 branches because the whole thing can become huge and instead of one giant PR, if we can do two bigs PRs that's a win.

@jasmussen
Copy link
Contributor

Cool, I'll think for a bit.

I'm also thinking in terms of introducing some grid/dimension variables and the new black color in a way that is leveraged by both.

@jasmussen
Copy link
Contributor

jasmussen commented Jan 8, 2020

I'll be pushing some work today. Right at this moment I'm going to try the following approach:

  • try/g2, I'll focus on in-canvas work, but I will probably also be including popovers, as they appear prominently inside the canvas
  • try/g3, when I get to it, is outside, including modals

Icons and font discussions we postpone, I would suggest.

@jasmussen
Copy link
Contributor

jasmussen commented Jan 8, 2020

Alright, I pushed a bunch of polish.

The placeholder grid is gone for now, and it has a 2px border radius to match the mockups:

Screenshot 2020-01-08 at 13 11 22

It has a focus style that is the beginning of a unitified theme-color 2px focus style we can use everywhere:

Screenshot 2020-01-08 at 13 11 42

I added new grid system variables, and cleaned up the code that paints borders around buttons, so they're all square:

Screenshot 2020-01-08 at 13 11 34

Note how the formatting buttons are also optically spaced:

Screenshot 2020-01-08 at 13 10 13

That is — when multiple buttons are shown next to each other, the middle ones are 36px, and the ones on the edges are 36px + 6px padding. This is based on the overlap the 48px buttons would have, in order to be optically balanced:

Screenshot 2020-01-08 at 12 56 22

There are a number of issues remaining, which I will help take a stab at. However before jumping into that, @youknowriad (get well soon!) I hope you can help me with a good rebase on this one. I know that @ellatrix has refactored the canvas a fair bit, removing dom nodes left and right, so before I go styling elements that no longer exist, it would be good to rebase. If you feel like squashing a couple of your smaller commits too, that would be fine ;)

Some of the remaining issues I hope to look at include:

Problem with focus on floats and other non-text blocks

Screenshot 2020-01-08 at 13 11 38

Problem with the toolbar needing to be detached so it can align left and right

Screenshot 2020-01-08 at 13 19 12

I don't know if that should be this branch, but the whole G2 concept of a detached toolbar kind of hinges upon it. Especially since we're still figuring out the exact behavior if the mover control; it's actually the block switcher that's supposed to align with the left margin on the block.

There's an extra border on the first block when you're multi selecting

Screenshot 2020-01-08 at 13 11 55

Also:

  • buttons inside toolbar needs consistent focus and and toggled styles
  • movers need polish
  • navigation mode needs redoing just like the rest
  • we need to refactor away the block-edit::before border
  • test plugin toolbar groups and plugins that add to the inline slot

Again, fonts and icons, and actually colors also, we'll look at separately.

@@ -4,10 +4,16 @@
width: 100%;
overflow: auto; // Allow horizontal scrolling on mobile.
position: relative;
border-left: $border-width solid $border-color;
height: $block-toolbar-height;
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Does this work in all breakpoints and top toolbar, I think this generic component is meant to be shown with different heights, so maybe it should be unopionated?

Copy link
Contributor

Choose a reason for hiding this comment

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

Done!

$block-controls-height: 36px;
$icon-button-size: 36px;
$block-controls-height: 36px; // @todo: This should be deprecated in favor of 48px block control heights.
$icon-button-size: 36px; // @todo: This should be deprecated in favor of 48px block control heights.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This I think is useful for the default button size (and all what should have its size)

Copy link
Contributor

Choose a reason for hiding this comment

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

Can you elaborate on what you mean here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I mean I don't really understand why this is deprecated. The button size is still 36px across the UI (aside toolbars)

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh, good point. I suppose I'll remove those Todos for now. I think there is some variable cleanup todo here so that there isn't any confusion — "icon button" could refer to formatting buttons which should be 48x48, also on mobile, and perhaps even in the toolbar, wheras yes, the traditional blue primary and secondary buttons are 36 in height.

I'm speaking specifically about the clickable hit area also.

// They are 36px, except for the first and the last, which have
// an additional 6px padding left or right.
.components-toolbar > div {
width: 48px - 6px - 6px;
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I wonder if it's possible for third-party plugins to add formatting buttons that are not icons but text (so not square).
Can we achieve the same behavior without forcing a width?

Copy link
Contributor

Choose a reason for hiding this comment

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

Addressed this in 0417c92, but it's a little messy and specific. Advice is welcome, but I'm also hoping to revisit this.

@jasmussen
Copy link
Contributor

Great thoughts Riad, I will try to address those tomorrow as I continue with this.

When you're well again, I would appreciate your help with a rebase!

@youknowriad
Copy link
Contributor Author

The rebase was a little bit painful :) I hope I didn't break anything.

@jasmussen
Copy link
Contributor

Polished the mover icons:

Screenshot 2020-01-09 at 12 03 52

Screenshot 2020-01-09 at 12 06 31

The hit area remains 48x24 pixels, despite the alignment of the icons inside, so the hit area remains a fair bit larger than what is currently shipping (28x24px).

@jasmussen
Copy link
Contributor

Screenshot 2020-01-09 at 12 15 42

This white square at the end of the toolbar appeared in the rebase. This is from the redone and way faster sibling inserter, it exists there for tabbing but is invisible until focused. I will see what I can do to fix it so it doesn't take up space like it does now.

@jasmussen
Copy link
Contributor

Fixed the blank square:

Screenshot 2020-01-09 at 12 33 17

&.is-visible {
width: auto;
opacity: 1;
pointer-events: all;
}
}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@ellatrix I feel the inserter shouldn't be part of the BlockToolbar DOM node at all, it makes styling more difficult. Could we return maybe a fragment and move it out?

Copy link
Member

Choose a reason for hiding this comment

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

Sure. I moved it here temporarily. We can move it somewhere else and reposition.

@jasmussen
Copy link
Contributor

Alright, did some cleanup and made progress. Improved the focus styles:

placeholder

Unified them with block selection styles:

multi select

Improved positioning of resize handles in a more generic way:

Screenshot 2020-01-10 at 13 05 41

Optical balancing of icon hit areas in toolbar, rewritten to work with any component groups:

Screenshot 2020-01-10 at 13 07 36

Still on the ToDo:

  • button focus styles refactor and consistency + toggle states
  • reusable blocks
  • theme colors, where and when to use (for example it has been a problem to use red/danger-color buttons in midnight themes)
  • color variable cleanup to colors.scss
  • navigation mode styles
  • new dropdown icon for inline styles
  • fix switcher for icons with no switching, like nav items
  • remove todos
  • problem with the toolbar needing to be detached so it can align left and right
  • we need to refactor away the block-edit::before border
  • test plugin toolbar groups and plugins that add to the inline slot

So there's still a ways to go for this branch to be ready to merge.

@youknowriad
Copy link
Contributor Author

@jasmussen in the format toolbar, when you click the buttons, you'll notice that the focus style is not centered properly and that there's jumpiness when you "toggle" formats.

@jasmussen
Copy link
Contributor

Yep, that's one of the things I mean to look at now.

@jasmussen
Copy link
Contributor

Refactored focus, hover and toggled states for the block toolbar today:

focus

Screenshot 2020-01-13 at 12 46 54

For this particular effort, I'm trying to unify on a single visual style (2px rounded) that is the same for:

  • block focused
  • block selected
  • button focused

Aside from being a single identifiable focus style, it works well with things that are bordered, such as the placeholder and text input fields, in that the 1px to 2px border becomes a shape change so that it does not need to also have contrast change.

However this is a change from the 1px style, and while I vastly prefer this personally, I could use a sanity check.

Similarly — we need a visual treatment for a button that is toggled and focused. Here's what I have so far:

Screenshot 2020-01-13 at 12 47 19

That is, a white inner halo. However in being inset, that makes the icon square. Can we do better? CC: @mtias @pablohoneyhoney

@youknowriad
Copy link
Contributor Author

I like the code refactoring, I personally prefer a 1px focus style design-wise though.

@github-actions
Copy link

Size Change: -811 B (0%)

Total Size: 865 kB

Filename Size Change
build/a11y/index.js 1 kB -1 B
build/block-editor/index.js 104 kB -194 B (0%)
build/block-editor/style-rtl.css 10.3 kB +544 B (5%) 🔍
build/block-editor/style.css 10.3 kB +547 B (5%) 🔍
build/block-library/editor-rtl.css 7.67 kB -4 B (0%)
build/block-library/index.js 116 kB -20 B (0%)
build/block-serialization-default-parser/index.js 1.65 kB +1 B
build/components/index.js 190 kB +16 B (0%)
build/components/style-rtl.css 15.5 kB -529 B (3%)
build/components/style.css 15.5 kB -535 B (3%)
build/compose/index.js 5.76 kB -2 B (0%)
build/core-data/index.js 10.5 kB -1 B
build/data-controls/index.js 1.03 kB -1 B
build/data/index.js 8.22 kB +1 B
build/date/index.js 5.37 kB +4 B (0%)
build/deprecated/index.js 772 B +1 B
build/dom-ready/index.js 568 B -1 B
build/dom/index.js 3.06 kB -1 B
build/edit-post/index.js 90.9 kB +147 B (0%)
build/edit-post/style-rtl.css 8.68 kB -23 B (0%)
build/edit-post/style.css 8.67 kB -18 B (0%)
build/edit-site/index.js 4.59 kB -1 B
build/edit-widgets/index.js 4.36 kB -1 B
build/edit-widgets/style-rtl.css 2.8 kB -1 B
build/editor/editor-styles-rtl.css 325 B -2 B (0%)
build/editor/editor-styles.css 327 B -1 B
build/editor/index.js 44.6 kB -517 B (1%)
build/editor/style-rtl.css 4.01 kB -115 B (2%)
build/editor/style.css 4 kB -111 B (2%)
build/element/index.js 4.45 kB -2 B (0%)
build/format-library/index.js 7.6 kB +3 B (0%)
build/format-library/style-rtl.css 502 B +2 B (0%)
build/format-library/style.css 502 B +1 B
build/html-entities/index.js 622 B +1 B
build/i18n/index.js 3.45 kB -1 B
build/is-shallow-equal/index.js 710 B -1 B
build/keyboard-shortcuts/index.js 2.3 kB +4 B (0%)
build/nux/index.js 3.02 kB +1 B
build/plugins/index.js 2.54 kB +1 B
build/priority-queue/index.js 879 B +1 B
build/redux-routine/index.js 2.84 kB +2 B (0%)
build/rich-text/index.js 14.3 kB -1 B
build/server-side-render/index.js 2.54 kB -2 B (0%)
build/token-list/index.js 1.27 kB -1 B
build/url/index.js 4 kB -1 B
ℹ️ View Unchanged
Filename Size Change
build/annotations/index.js 3.43 kB 0 B
build/api-fetch/index.js 3.39 kB 0 B
build/autop/index.js 2.58 kB 0 B
build/blob/index.js 620 B 0 B
build/block-directory/index.js 6.02 kB 0 B
build/block-directory/style-rtl.css 760 B 0 B
build/block-directory/style.css 760 B 0 B
build/block-library/editor.css 7.67 kB 0 B
build/block-library/style-rtl.css 7.49 kB 0 B
build/block-library/style.css 7.49 kB 0 B
build/block-library/theme-rtl.css 669 B 0 B
build/block-library/theme.css 671 B 0 B
build/block-serialization-spec-parser/index.js 3.1 kB 0 B
build/blocks/index.js 57.6 kB 0 B
build/edit-site/style-rtl.css 2.77 kB 0 B
build/edit-site/style.css 2.76 kB 0 B
build/edit-widgets/style.css 2.79 kB 0 B
build/escape-html/index.js 733 B 0 B
build/hooks/index.js 1.92 kB 0 B
build/keycodes/index.js 1.68 kB 0 B
build/list-reusable-blocks/index.js 2.99 kB 0 B
build/list-reusable-blocks/style-rtl.css 215 B 0 B
build/list-reusable-blocks/style.css 216 B 0 B
build/media-utils/index.js 4.85 kB 0 B
build/notices/index.js 1.57 kB 0 B
build/nux/style-rtl.css 616 B 0 B
build/nux/style.css 613 B 0 B
build/primitives/index.js 1.49 kB 0 B
build/shortcode/index.js 1.7 kB 0 B
build/viewport/index.js 1.61 kB 0 B
build/warning/index.js 1.14 kB 0 B
build/wordcount/index.js 1.18 kB 0 B

compressed-size-action

@youknowriad youknowriad merged commit ef73ed0 into master Feb 25, 2020
@youknowriad youknowriad deleted the try/g2 branch February 25, 2020 08:07
@youknowriad
Copy link
Contributor Author

Don't tell anyone ;)

@github-actions github-actions bot added this to the Gutenberg 7.7 milestone Feb 25, 2020
@jasmussen
Copy link
Contributor

ᕕ( ᐛ )ᕗ

@irishetcher
Copy link

Big improved look for the block editor. The inserters are far more visible and make for better usability. The tool bar, when attached to blocks, now becomes fixed as you scroll blocks up. Useful when working larger layout blocks.

@irishetcher
Copy link

The Desktop/Tablet/Mobile preview modes are welcome but the viewports don't represent or render what you see on the frontend. Toolset now has these in Views but their viewports are different widths than those in the block editor and likewise are not as faithful to what is seen on the front end. It seems to be me that blocks are not as sharp in this respect as what you get with page builders such as Divi.

@ZebulanStanphill
Copy link
Member

ZebulanStanphill commented Mar 11, 2020

@irishetcher Yeah, the preview modes are still limited by the differences between the editor and front-end styling. A lot of work has been done lately to reduce the differences between the two, e.g. #19701, but there's still a lot of work to be done. The move towards block-based templates in themes, full site editing, and the global styles system will all be involved in making this a reality.

Relevant links:

@ellatrix ellatrix mentioned this pull request Jun 16, 2020
12 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs Accessibility Feedback Need input from accessibility Needs Design Feedback Needs general design feedback.
Projects
None yet