Media & Text Block: Add vertical alignment options #13989
Conversation
frontdevde
added
[Type] Enhancement
There was a problem hiding this comment.
Thanks for your work on this.
Looks great and works well. Some minor nit picks but nothing critical.
One thing it might be making it even more explicit in the PR description that feedback for anything other than the Media + Text Block (should be provided on my PR else we'll get in a real mess!).
|
Looks good so far, @frontdevde. I do have questions about a default state — if we're center aligning things by default, we should probably have that option selected in the toolbar. Another observation is that the additional margins that exist on these blocks currently mean that top + bottom aligned blocks will never actually line up with top/bottom of the image next to them. 😕 This is really obvious when the InnerBlock isn't being hovered over. In this case, it just looks like the text is being moved slightly up and down by the buttons, rather than being top/bottom aligned.
I'm not totally sure what we can do about this, but it's possible we can trim some of those margins a bit in this case. @jasmussen any thoughts on that? |
|
Thanks for the feedback, @kjellr 👍
I've had the same question myself before in the context of @getdave's PR #13899 that introduces the vertical alignment toolbar component. I'm quoting the reply I got at the time, in the context of said PR:
--
Yes, noticed that as well. Happy for suggestions! |
|
Thanks for the ping. Regarding having the button already pre-selected, I think it's okay for it not to. To me this is not so different from us having a Text align left button, but it not being selected despite most text being left aligned. It is also my understanding that the fewer actual properties we set on blocks, the more a theme can style the defaults. Regarding the innerblocks additional margin — yeah, this is a challenge. Whenever an innerblocks container is added, additional margin is added as well. This is also one of the challenges we have had to deal with for the columns block, where the singular column blocks add unnecessary margin. We've manually zeroed that out, which was a great headache, and kind of a mess. It seems like the solution to that might involve #7694. Or it might involve a slight refactor of how block paddings and margins are painted. That's likely a big one, and one to look at separately. Something in the vein of #8350 but good. |
|
Thanks for the feedback on this.
This is the key point here. We should avoid setting defaults that break existing Blocks backwards compatibility.
This feels like it could be something that needs to be addressed to ship this. @frontdevde might you be able to do some investigative research and advise on the amount of work that might be involved here? What's the scope of the problem? Then we can determine whether it can be realisitically be addressed within this PR. |
|
I dove in and took a look. It seems #8350 is definitely the concept to revisit. The thing right now is that every block is born with a top and bottom margin. That includes inner blocks. Normally content has margins applied on its own. I.e. a paragraph has a top and bottom margin. Those margins even collapse according to obtuse rules. But the Columns block should not have a top/bottom margin, neither should the column block that nests inside it. Only the content inside should have its own intrinsic margins. As mentioned, the columns block currently zeroes out and overrides this global block margin. Which is hacky. Any fix for this PR would likely involve the same. It seems revisiting #8350 separately is a best bet. I can probably take a look next week. But if anyone else feels adventurous, the margin to refactor out lives here: https://github.com/WordPress/gutenberg/blob/master/packages/editor/src/components/block-list/style.scss#L60 — I am almost convinced that's the margin that makes the innerblocks have margins they shouldn't have. But be aware this margin affects a lot, so it's not a simple thing to fix. |
|
The functionality looks really solid to me. Extra margins now noticeable with the top/bottom alignments. I see some extra files in here (like icons.js) but I assume it's just a matter of rebasing again on top of the #13899, right? |
That is correct! 👍 |
There was a problem hiding this comment.
Hi @frontdevde thank you for this enhancements 👍 I focused my review on media & text changes as the other artifacts are already being reviewed in #13899.
Things worked well in my tests, I just left some suggestions.
This PR is round 2 of #8350. The ultimate goal is to make it easier for themes to style the editor, and to do less CSS overriding in order to do so. Problem: Currently, every single block is born with an intrinsic top and bottom margin. This margin matches the padding that sits between the block and the "selected block" border, plus 2px of space. This margin is the same regardless of whether the block needs a margin or not, and it is applied to nesting containers as well. In the case of the Columns block for example, that means the _column_ block (singular) has top and bottom margin, even though it shouldn't have that. Since then a number of changes have been made to the editor to make it a good time to revisit this: - The block outlines and toolbars have been refactored to not rely on margins at all to position themselves. These will still be painted correctly outside of the block, though they may overlap content visibly if a zero margin block is selected. - A more solid editor style system has been introduced that makes it easier to customize the editor to look like the front-end. As a result of this, feedback around CSS specificity and having to override these margins have surfaced to a higher degree. Proposed solution: By removing the intrinsic margin, we can re-apply it only to the blocks that actually _should_ be born with an intrinsic margin, such as paragraphs, lists, quotes ,etc. Some discussion points that are likely to surface: where should those vanilla styles be stored? How should they be structured so that themes can easily override them? Should these _not_ be loaded if a theme provides its own editor styles? Should we leverage the cascade and store these generically in one location or should these be applied in the style.scss file for every block in the library? Given these intrinsic margins have been present since day one, can we expect plugin authors to remember to add these margins themselves for every block they make? Is there a back-compat way we provide these default margins to blocks that rely on them? This is a try branch, in order to figure out answers to those questions. This first commit only does a few things: - It rearranges some CSS to put things in more logical locations. - It removes the intrinsic margins, then blanket reapplies them in that new vanilla stylesheet location with a new CSS variable. Next commits will explore how to remove that blanket reapplication, and try to provide those vanilla styles in a per-block basis. See also: #13989 (comment) https://github.com/WordPress/gutenberg/pull/8350/files
|
This is nice! |
frontdevde
force-pushed
the
update/media-text-block-v-align
branch
from
7e291fc to
1e7ebdc
Compare
frontdevde
added
[Status] Blocked
I've updated the state of this Draft PR to only show the diff to PR #13899. We'll get back to this once PR #13899 has landed. For now I've added the |
This PR is round 2 of #8350. The ultimate goal is to make it easier for themes to style the editor, and to do less CSS overriding in order to do so. Problem: Currently, every single block is born with an intrinsic top and bottom margin. This margin matches the padding that sits between the block and the "selected block" border, plus 2px of space. This margin is the same regardless of whether the block needs a margin or not, and it is applied to nesting containers as well. In the case of the Columns block for example, that means the _column_ block (singular) has top and bottom margin, even though it shouldn't have that. Since then a number of changes have been made to the editor to make it a good time to revisit this: - The block outlines and toolbars have been refactored to not rely on margins at all to position themselves. These will still be painted correctly outside of the block, though they may overlap content visibly if a zero margin block is selected. - A more solid editor style system has been introduced that makes it easier to customize the editor to look like the front-end. As a result of this, feedback around CSS specificity and having to override these margins have surfaced to a higher degree. Proposed solution: By removing the intrinsic margin, we can re-apply it only to the blocks that actually _should_ be born with an intrinsic margin, such as paragraphs, lists, quotes ,etc. Some discussion points that are likely to surface: where should those vanilla styles be stored? How should they be structured so that themes can easily override them? Should these _not_ be loaded if a theme provides its own editor styles? Should we leverage the cascade and store these generically in one location or should these be applied in the style.scss file for every block in the library? Given these intrinsic margins have been present since day one, can we expect plugin authors to remember to add these margins themselves for every block they make? Is there a back-compat way we provide these default margins to blocks that rely on them? This is a try branch, in order to figure out answers to those questions. This first commit only does a few things: - It rearranges some CSS to put things in more logical locations. - It removes the intrinsic margins, then blanket reapplies them in that new vanilla stylesheet location with a new CSS variable. Next commits will explore how to remove that blanket reapplication, and try to provide those vanilla styles in a per-block basis. See also: #13989 (comment) https://github.com/WordPress/gutenberg/pull/8350/files
This PR is round 2 of #8350. The ultimate goal is to make it easier for themes to style the editor, and to do less CSS overriding in order to do so. Problem: Currently, every single block is born with an intrinsic top and bottom margin. This margin matches the padding that sits between the block and the "selected block" border, plus 2px of space. This margin is the same regardless of whether the block needs a margin or not, and it is applied to nesting containers as well. In the case of the Columns block for example, that means the _column_ block (singular) has top and bottom margin, even though it shouldn't have that. Since then a number of changes have been made to the editor to make it a good time to revisit this: - The block outlines and toolbars have been refactored to not rely on margins at all to position themselves. These will still be painted correctly outside of the block, though they may overlap content visibly if a zero margin block is selected. - A more solid editor style system has been introduced that makes it easier to customize the editor to look like the front-end. As a result of this, feedback around CSS specificity and having to override these margins have surfaced to a higher degree. Proposed solution: By removing the intrinsic margin, we can re-apply it only to the blocks that actually _should_ be born with an intrinsic margin, such as paragraphs, lists, quotes ,etc. Some discussion points that are likely to surface: where should those vanilla styles be stored? How should they be structured so that themes can easily override them? Should these _not_ be loaded if a theme provides its own editor styles? Should we leverage the cascade and store these generically in one location or should these be applied in the style.scss file for every block in the library? Given these intrinsic margins have been present since day one, can we expect plugin authors to remember to add these margins themselves for every block they make? Is there a back-compat way we provide these default margins to blocks that rely on them? This is a try branch, in order to figure out answers to those questions. This first commit only does a few things: - It rearranges some CSS to put things in more logical locations. - It removes the intrinsic margins, then blanket reapplies them in that new vanilla stylesheet location with a new CSS variable. Next commits will explore how to remove that blanket reapplication, and try to provide those vanilla styles in a per-block basis. See also: #13989 (comment) https://github.com/WordPress/gutenberg/pull/8350/files
|
@frontdevde The VAlign PR is now merged. Note that |
|
@mtias to quote @frontdevde here #13989 (comment)
😄 |
frontdevde
removed
the
[Status] Blocked
@getdave No! I forgot to remove the tag, thanks for pointing that out. Just added a fixture for a vertical alignment test. That resolves the last open comment on this one. |
This PR is round 2 of #8350. The ultimate goal is to make it easier for themes to style the editor, and to do less CSS overriding in order to do so. Problem: Currently, every single block is born with an intrinsic top and bottom margin. This margin matches the padding that sits between the block and the "selected block" border, plus 2px of space. This margin is the same regardless of whether the block needs a margin or not, and it is applied to nesting containers as well. In the case of the Columns block for example, that means the _column_ block (singular) has top and bottom margin, even though it shouldn't have that. Since then a number of changes have been made to the editor to make it a good time to revisit this: - The block outlines and toolbars have been refactored to not rely on margins at all to position themselves. These will still be painted correctly outside of the block, though they may overlap content visibly if a zero margin block is selected. - A more solid editor style system has been introduced that makes it easier to customize the editor to look like the front-end. As a result of this, feedback around CSS specificity and having to override these margins have surfaced to a higher degree. Proposed solution: By removing the intrinsic margin, we can re-apply it only to the blocks that actually _should_ be born with an intrinsic margin, such as paragraphs, lists, quotes ,etc. Some discussion points that are likely to surface: where should those vanilla styles be stored? How should they be structured so that themes can easily override them? Should these _not_ be loaded if a theme provides its own editor styles? Should we leverage the cascade and store these generically in one location or should these be applied in the style.scss file for every block in the library? Given these intrinsic margins have been present since day one, can we expect plugin authors to remember to add these margins themselves for every block they make? Is there a back-compat way we provide these default margins to blocks that rely on them? This is a try branch, in order to figure out answers to those questions. This first commit only does a few things: - It rearranges some CSS to put things in more logical locations. - It removes the intrinsic margins, then blanket reapplies them in that new vanilla stylesheet location with a new CSS variable. Next commits will explore how to remove that blanket reapplication, and try to provide those vanilla styles in a per-block basis. See also: #13989 (comment) https://github.com/WordPress/gutenberg/pull/8350/files
This PR is round 2 of #8350. The ultimate goal is to make it easier for themes to style the editor, and to do less CSS overriding in order to do so. Problem: Currently, every single block is born with an intrinsic top and bottom margin. This margin matches the padding that sits between the block and the "selected block" border, plus 2px of space. This margin is the same regardless of whether the block needs a margin or not, and it is applied to nesting containers as well. In the case of the Columns block for example, that means the _column_ block (singular) has top and bottom margin, even though it shouldn't have that. Since then a number of changes have been made to the editor to make it a good time to revisit this: - The block outlines and toolbars have been refactored to not rely on margins at all to position themselves. These will still be painted correctly outside of the block, though they may overlap content visibly if a zero margin block is selected. - A more solid editor style system has been introduced that makes it easier to customize the editor to look like the front-end. As a result of this, feedback around CSS specificity and having to override these margins have surfaced to a higher degree. Proposed solution: By removing the intrinsic margin, we can re-apply it only to the blocks that actually _should_ be born with an intrinsic margin, such as paragraphs, lists, quotes ,etc. Some discussion points that are likely to surface: where should those vanilla styles be stored? How should they be structured so that themes can easily override them? Should these _not_ be loaded if a theme provides its own editor styles? Should we leverage the cascade and store these generically in one location or should these be applied in the style.scss file for every block in the library? Given these intrinsic margins have been present since day one, can we expect plugin authors to remember to add these margins themselves for every block they make? Is there a back-compat way we provide these default margins to blocks that rely on them? This is a try branch, in order to figure out answers to those questions. This first commit only does a few things: - It rearranges some CSS to put things in more logical locations. - It removes the intrinsic margins, then blanket reapplies them in that new vanilla stylesheet location with a new CSS variable. Next commits will explore how to remove that blanket reapplication, and try to provide those vanilla styles in a per-block basis. See also: #13989 (comment) https://github.com/WordPress/gutenberg/pull/8350/files
This PR is round 2 of #8350. The ultimate goal is to make it easier for themes to style the editor, and to do less CSS overriding in order to do so. Problem: Currently, every single block is born with an intrinsic top and bottom margin. This margin matches the padding that sits between the block and the "selected block" border, plus 2px of space. This margin is the same regardless of whether the block needs a margin or not, and it is applied to nesting containers as well. In the case of the Columns block for example, that means the _column_ block (singular) has top and bottom margin, even though it shouldn't have that. Since then a number of changes have been made to the editor to make it a good time to revisit this: - The block outlines and toolbars have been refactored to not rely on margins at all to position themselves. These will still be painted correctly outside of the block, though they may overlap content visibly if a zero margin block is selected. - A more solid editor style system has been introduced that makes it easier to customize the editor to look like the front-end. As a result of this, feedback around CSS specificity and having to override these margins have surfaced to a higher degree. Proposed solution: By removing the intrinsic margin, we can re-apply it only to the blocks that actually _should_ be born with an intrinsic margin, such as paragraphs, lists, quotes ,etc. Some discussion points that are likely to surface: where should those vanilla styles be stored? How should they be structured so that themes can easily override them? Should these _not_ be loaded if a theme provides its own editor styles? Should we leverage the cascade and store these generically in one location or should these be applied in the style.scss file for every block in the library? Given these intrinsic margins have been present since day one, can we expect plugin authors to remember to add these margins themselves for every block they make? Is there a back-compat way we provide these default margins to blocks that rely on them? This is a try branch, in order to figure out answers to those questions. This first commit only does a few things: - It rearranges some CSS to put things in more logical locations. - It removes the intrinsic margins, then blanket reapplies them in that new vanilla stylesheet location with a new CSS variable. Next commits will explore how to remove that blanket reapplication, and try to provide those vanilla styles in a per-block basis. See also: #13989 (comment) https://github.com/WordPress/gutenberg/pull/8350/files
…htly (#14407) * Try: Remove intrinsic block margins, rely on cascade This PR is round 2 of #8350. The ultimate goal is to make it easier for themes to style the editor, and to do less CSS overriding in order to do so. Problem: Currently, every single block is born with an intrinsic top and bottom margin. This margin matches the padding that sits between the block and the "selected block" border, plus 2px of space. This margin is the same regardless of whether the block needs a margin or not, and it is applied to nesting containers as well. In the case of the Columns block for example, that means the _column_ block (singular) has top and bottom margin, even though it shouldn't have that. Since then a number of changes have been made to the editor to make it a good time to revisit this: - The block outlines and toolbars have been refactored to not rely on margins at all to position themselves. These will still be painted correctly outside of the block, though they may overlap content visibly if a zero margin block is selected. - A more solid editor style system has been introduced that makes it easier to customize the editor to look like the front-end. As a result of this, feedback around CSS specificity and having to override these margins have surfaced to a higher degree. Proposed solution: By removing the intrinsic margin, we can re-apply it only to the blocks that actually _should_ be born with an intrinsic margin, such as paragraphs, lists, quotes ,etc. Some discussion points that are likely to surface: where should those vanilla styles be stored? How should they be structured so that themes can easily override them? Should these _not_ be loaded if a theme provides its own editor styles? Should we leverage the cascade and store these generically in one location or should these be applied in the style.scss file for every block in the library? Given these intrinsic margins have been present since day one, can we expect plugin authors to remember to add these margins themselves for every block they make? Is there a back-compat way we provide these default margins to blocks that rely on them? This is a try branch, in order to figure out answers to those questions. This first commit only does a few things: - It rearranges some CSS to put things in more logical locations. - It removes the intrinsic margins, then blanket reapplies them in that new vanilla stylesheet location with a new CSS variable. Next commits will explore how to remove that blanket reapplication, and try to provide those vanilla styles in a per-block basis. See also: #13989 (comment) https://github.com/WordPress/gutenberg/pull/8350/files * Try a new "Safety Margin" This commit includes a few typo fixes, documentation cleanup, general polish. But moreso than that, it does a few things: - It removes as many margins as it can, now only bottom margins remain. - It introduces a new "safety margin" rule that targets every block. More on this in a bit. If you look over the code, you can see that it's quite a few steps forward with regards to simplifying selectors and cleaning up the code. But due to the [data-block] selector targetting the _wrapper_ of a block, rather than where the block starts (which is usually the first encounter of a `wp-block-*` class), this margin is actually applied outside of the content of the block. Which means this aspect is only the tiniest step forward, compared to the selector it replaces, which was also outside the content of the block. * Add top margin also.
|
A question from a new-ish Gutenberg user: this is exactly what I need. Is it available to us regular folks yet? Or do you have a date for its availability yet? We sure need it for the new site we're creating! Thanks, Linda |
|
Hi @cdnlin, this feature is currently available for sites using the Gutenberg plugin and will soon be available for all sites running WordPress 5.3. |
|
Hey, great news, noisysocks! Thanks so much for letting me know. 5.3 has to be getting close since we're at 5.2.1 now. Until then, appreciate the heads up about the plugin. I haven't downloaded it yet, but will now. |
Description
This PR aims to add vertical alignment options to the Media & Text Block.
Important Note:
Instead of the initially custom vertical alignment implementation, this PR now builds upon the great work that @getdave has been doing to streamline this functionality by creating the
BlockVerticalAlignmentToolbarcomponent. Thus this PR will remain in Draft stage until the PR #13899, which includes theBlockVerticalAlignmentToolbarcomponent, has been merged.Screenshots
Todo
BlockVerticalAlignmentToolbarHow has this been tested?
editormodedeprecation) when upgrading from old form of the Block to the one in this PR (you can do this by switching tomasteradding the old Block, publishing/updating the post, then switching back to this PR and testing)Checklist: