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

Unify how editor alignments are applied across blocks #21822

Merged
merged 9 commits into from
Apr 24, 2020

Conversation

youknowriad
Copy link
Contributor

While working on the lightBlockWrapper API, we experimented on the Image block about how we can keep the frontend similar to the backend for alignments. It worked for this particular block but it's not something we can generalize yet to all blocks (especially the ones relying on the align hook).

This PR partially reverts the image block alignments change and at the same time updates the "align" hook to support the new "lightBlockWrapper" behavior. This means lightBlockWrapper doesn't mean we're consistent with frontend for aligned blocks but it also means that all blocks in the editor behaves consistently when it comes to alignment (fixes #21685)

So this is an intermediate step before the bigger alignments rethinking that is happening separately.

@youknowriad youknowriad added [Feature] Blocks Overall functionality of blocks [Block] Image Affects the Image Block [Block] Buttons Affects the Buttons Block labels Apr 23, 2020
@youknowriad youknowriad self-assigned this Apr 23, 2020
children,
tagName = 'div',
__unstableIsHtml,
wrapperProps: parentWrapperProps,
Copy link
Contributor Author

@youknowriad youknowriad Apr 23, 2020

Choose a reason for hiding this comment

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

This is just needed for the image block now, but we can remove it if ever we refactor it to use the "align" hook instead of a custom implementation.

Copy link
Member

@ellatrix ellatrix Apr 23, 2020

Choose a reason for hiding this comment

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

Can we not use the block context for this?

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'm not sure how you'd do so, retrieve the context value, alter it and add a new provider? It would work but it's also not great code either, I'd rather remove this at some point (after the image refactor).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Actually, we can probably use getEditPropsWrapper

Copy link
Member

Choose a reason for hiding this comment

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

I meant adding it to useContext( BlockContext ) below

@youknowriad youknowriad force-pushed the add/unify-editor-alignments branch from 9f3700e to d945522 Compare April 23, 2020 11:36
@github-actions
Copy link

github-actions bot commented Apr 23, 2020

Size Change: -530 B (0%)

Total Size: 844 kB

Filename Size Change
build/block-editor/index.js 105 kB +32 B (0%)
build/block-editor/style-rtl.css 10 kB -144 B (1%)
build/block-editor/style.css 10 kB -139 B (1%)
build/block-library/editor-rtl.css 7.05 kB -81 B (1%)
build/block-library/editor.css 7.05 kB -78 B (1%)
build/block-library/index.js 112 kB -33 B (0%)
build/block-library/style-rtl.css 7.14 kB -46 B (0%)
build/block-library/style.css 7.14 kB -49 B (0%)
build/components/index.js 198 kB +3 B (0%)
build/data-controls/index.js 1.29 kB +40 B (3%)
build/edit-post/style-rtl.css 12.4 kB -13 B (0%)
build/edit-post/style.css 12.4 kB -13 B (0%)
build/edit-site/style-rtl.css 5.24 kB -8 B (0%)
build/edit-site/style.css 5.24 kB -8 B (0%)
build/editor/index.js 43.4 kB +7 B (0%)
ℹ️ View Unchanged
Filename Size Change
build/a11y/index.js 1.02 kB 0 B
build/annotations/index.js 3.62 kB 0 B
build/api-fetch/index.js 4.08 kB 0 B
build/autop/index.js 2.82 kB 0 B
build/blob/index.js 620 B 0 B
build/block-directory/index.js 6.24 kB 0 B
build/block-directory/style-rtl.css 760 B 0 B
build/block-directory/style.css 761 B 0 B
build/block-library/theme-rtl.css 683 B 0 B
build/block-library/theme.css 685 B 0 B
build/block-serialization-default-parser/index.js 1.88 kB 0 B
build/block-serialization-spec-parser/index.js 3.1 kB 0 B
build/blocks/index.js 57.7 kB 0 B
build/components/style-rtl.css 16.9 kB 0 B
build/components/style.css 16.9 kB 0 B
build/compose/index.js 6.66 kB 0 B
build/core-data/index.js 11.4 kB 0 B
build/data/index.js 8.43 kB 0 B
build/date/index.js 5.47 kB 0 B
build/deprecated/index.js 772 B 0 B
build/dom-ready/index.js 569 B 0 B
build/dom/index.js 3.1 kB 0 B
build/edit-navigation/index.js 3.54 kB 0 B
build/edit-navigation/style-rtl.css 485 B 0 B
build/edit-navigation/style.css 485 B 0 B
build/edit-post/index.js 28.2 kB 0 B
build/edit-site/index.js 10.8 kB 0 B
build/edit-widgets/index.js 8.33 kB 0 B
build/edit-widgets/style-rtl.css 5 kB 0 B
build/edit-widgets/style.css 5 kB 0 B
build/editor/editor-styles-rtl.css 428 B 0 B
build/editor/editor-styles.css 431 B 0 B
build/editor/style-rtl.css 3.27 kB 0 B
build/editor/style.css 3.27 kB 0 B
build/element/index.js 4.65 kB 0 B
build/escape-html/index.js 733 B 0 B
build/format-library/index.js 7.32 kB 0 B
build/format-library/style-rtl.css 502 B 0 B
build/format-library/style.css 502 B 0 B
build/hooks/index.js 2.13 kB 0 B
build/html-entities/index.js 622 B 0 B
build/i18n/index.js 3.56 kB 0 B
build/is-shallow-equal/index.js 711 B 0 B
build/keyboard-shortcuts/index.js 2.51 kB 0 B
build/keycodes/index.js 1.94 kB 0 B
build/list-reusable-blocks/index.js 3.12 kB 0 B
build/list-reusable-blocks/style-rtl.css 226 B 0 B
build/list-reusable-blocks/style.css 226 B 0 B
build/media-utils/index.js 5.29 kB 0 B
build/notices/index.js 1.79 kB 0 B
build/nux/index.js 3.4 kB 0 B
build/nux/style-rtl.css 616 B 0 B
build/nux/style.css 613 B 0 B
build/plugins/index.js 2.67 kB 0 B
build/primitives/index.js 1.49 kB 0 B
build/priority-queue/index.js 789 B 0 B
build/redux-routine/index.js 2.84 kB 0 B
build/rich-text/index.js 14.8 kB 0 B
build/server-side-render/index.js 2.67 kB 0 B
build/shortcode/index.js 1.7 kB 0 B
build/token-list/index.js 1.28 kB 0 B
build/url/index.js 4.02 kB 0 B
build/viewport/index.js 1.84 kB 0 B
build/warning/index.js 1.14 kB 0 B
build/wordcount/index.js 1.17 kB 0 B

compressed-size-action

@@ -352,6 +352,9 @@ export class ImageEdit extends Component {
sizeSlug,
} = attributes;

const wrapperProps = {
'data-align': align,
Copy link
Member

Choose a reason for hiding this comment

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

Can this not be built in?

[data-align="right"] > .wp-block-cover,
[data-align="left"] > .wp-block-cover-image,
[data-align="right"] > .wp-block-cover-image {
max-width: $content-width / 2;
Copy link
Member

@ellatrix ellatrix Apr 23, 2020

Choose a reason for hiding this comment

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

Why is width being defined here?

Copy link
Member

Choose a reason for hiding this comment

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

I'm just curious, it's not a comment to this PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Just guessing

I believe if we don't do it and align a block (left or right) we won't notice any change as otherwise it will stay with a 100% width

@youknowriad youknowriad marked this pull request as ready for review April 23, 2020 16:09
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.

I think this is a good step in the right direction. From here we can better look at having the same structure as the front-end.

@jasmussen
Copy link
Contributor

Sorry for being so late to this review.

This feels like an excellent first step onto bigger things, and the reduced and simplified markup is so lovely. Also bonus points for including the float margin. Great work all around.

There's one thing I noticed, technically it's not a regression from master — master is actually broken here 😱 — but worth noting so as to not grow worse. I notice because I recently merged #21608 and wanted to be sure things didn't regress.

It looks as though a centered image isn't centered in either master or this branch, in the editor only. But in master, at least the aligncenter class exists. Whereas in this branch, it appears is if nothing is output at all for a centered block.

Master:

Screenshot 2020-04-24 at 11 18 51

You can see there's a text-align: center there which doesn't work (that's the bug), but at least it's there.

This branch:

Screenshot 2020-04-24 at 11 19 23

It seems the quick fix would be to just remember to include some centering stuff? As mentioned, it works on the frontend, so what we could output in the editor could be something like:

.wp-block[data-align="center"] figure {
    margin-left: auto;
    margin-right: auto;
}

This appears to work for me in the editor, and should not be needed on the frontend, but I can't think of how it might cause issues.

@youknowriad
Copy link
Contributor Author

youknowriad commented Apr 24, 2020

This appears to work for me in the editor, and should not be needed on the frontend, but I can't think of how it might cause issues.

I think that's a good fix, I noticed this too but left it separate but I'm ok including it here. The reason there's no classnames here is to stay consistent, we don't use these classnames in the editor in general (not just within this PR), we tried using some of them on the image block recently but the inconsistency it created with other blocks that rely on data-align was not great.

Ideally, we'd remove data-align and only use the classnames to match frontend but since this would require updates and changes to frontend markup for the float alignments essentially, it's left separate.

I'll push the code, I'll just replace figure with > .wp-block-image though

@jasmussen
Copy link
Contributor

Ship it then! It seems like a good path forward.

@ellatrix
Copy link
Member

Yes, in one of the next iteration we'll try out the classnames again, but for all blocks to use it consistently rather than just the image block. This PR is a key step towards that.

@jasmussen
Copy link
Contributor

All good, go forth and conquer!

@youknowriad youknowriad merged commit c87c9b0 into master Apr 24, 2020
@youknowriad youknowriad deleted the add/unify-editor-alignments branch April 24, 2020 10:39
@github-actions github-actions bot added this to the Gutenberg 8.0 milestone Apr 24, 2020
@nfmohit
Copy link
Member

nfmohit commented Apr 25, 2020

Guys, I might be absolutely wrong but I think I've found some sort of a regression here. I noticed #21885 reporting that a centre-aligned image wasn't appearing as centre-aligned when they were using the Gutenberg plugin.

I started testing it out and eventually landed on this commit and PR.

It seems the quick fix would be to just remember to include some centering stuff? As mentioned, it works on the frontend, so what we could output in the editor could be something like:

.wp-block[data-align="center"] figure {
margin-left: auto;
margin-right: auto;
}

@jasmussen I'm not sure if this issue is specific to the theme, but this workaround only seems to work when the is-resized class is available on the figure element because that adds the display: table property to the element. Otherwise, it stays aligned to the left.

Also, after you add an image, it stays aligned to the very left. I'm not sure if this is related to this PR too though.

Let me share a screencast: https://take.ms/S54Si which may help understand the issue better.

Do you think the changes in this PR might've introduced these problems? If that is the case, could you point me towards a potential fix and I can quickly work on a PR?

If that is not the case, please excuse my concern, I might've just not done the investigation well. I can create a new issue in that case.

Thanks! ❤️

@nfmohit
Copy link
Member

nfmohit commented Apr 25, 2020

I’d like to add, adding text-align: center on the figure element under data-align: center does resolve the issue with the center alignment. I can write a PR with that upon getting your green light. Thanks!

@jasmussen
Copy link
Contributor

Excellent catch, @nfmohit-wpmudev. I can confirm that:

  • A small image that is not resized, when centered, does not show up as centered in the editor.
  • As soon as it is resized even a little bit, it does center itse.f
  • That this is an editor-only issue, on the frontend, the image is centered when aligned thusly, regardless of whether it's resized.

Centered but not resized:

Screenshot 2020-04-27 at 09 55 36

Centered and resized:

Screenshot 2020-04-27 at 09 55 40

At a glance, this change fixes it. Instead of:

.wp-block[data-align="center"] > .wp-block-image {
    margin-left: auto;
    margin-right: auto;
}

if we do this:

.wp-block[data-align="center"] > .wp-block-image {
    margin-left: auto;
    margin-right: auto;
    text-align: center;
}

it appears to work for both resized and unresized images.

@youknowriad any concerns with that one? Let me know if you'd like me to make a PR.

@nfmohit
Copy link
Member

nfmohit commented Apr 27, 2020

Hey @jasmussen !

Thank you very much for the confirmation. I'm very sorry, I didn't notice this response and submitted #21911, is that okay?

Thanks!

@jasmussen
Copy link
Contributor

Of course that's okay, it's incredibly helpful. Thank you!

@nfmohit
Copy link
Member

nfmohit commented Apr 27, 2020

Thank you very much!

Also, do you possibly have any idea why the image block gets added originally to the very left (like, left-aligned)? Here's a screencast. I can confirm that this doesn't happen on the core without the plugin. It aligned with the content when first added. Thank you!

@jasmussen
Copy link
Contributor

Yep, I believe that's an issue with the TwentyTwenty theme happening after some of these alignment refactors. It's unfortunate, but I believe, necessary, so as to improve the editor styles overall.

@nfmohit
Copy link
Member

nfmohit commented Apr 27, 2020

Thank you for the confirmation.

That's completely understandable. Just wanted to confirm that it is something that needs to be updated on the theme's end.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Block] Buttons Affects the Buttons Block [Block] Image Affects the Image Block [Feature] Blocks Overall functionality of blocks
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Button Block: Backwards compatibility floating doesn’t work properly
4 participants