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

Duplicated data-align attribute #24721

Closed
sandrowuermli opened this issue Aug 21, 2020 · 2 comments
Closed

Duplicated data-align attribute #24721

sandrowuermli opened this issue Aug 21, 2020 · 2 comments
Labels
[Block] Latest Posts Affects the Latest Posts Block [Type] Bug An existing feature does not function as intended

Comments

@sandrowuermli
Copy link

Describe the bug
As soon as i choose an alignment option (align-wide, align-full, align-left, align-right, align-center) the gutenberg editor will add two data-align attributes. This is a pain for creating a custom theme. Of course, you have many selector options, but it will always end in a DRY problem.

And because the <div class="wp-block" data-align="wide">…</div> has no other option, it will end at something like this:
div:not(.wp-block)[data-align="wide"] { … }.

On Default themes, if i chose align wide, the toolbar will float to the left border, instead of align seamless with the block itself.

To reproduce
Steps to reproduce the behavior:

  1. Create a new page or post.
  2. Add the "Latest posts" block.
  3. Chose align wide.
  4. See the toolbar is not aligned with the block itself.

Expected behavior
I Expect, that the toolbar is aligned with the block, like you see in the "fixed" screenshot.

Screenshots
Without css fix
with-duplicated-data-align-attribute

With css fix
with-duplicated-data-align-attribute-but-fixed-css

Editor version (please complete the following information):

  • WordPress version: 5.5
  • Does the website has Gutenberg plugin installed, or is it using the block editor that comes by default?: default

Desktop (please complete the following information):

  • OS: macOS Catalina (10.15.6)
  • Browser: Chrome 84.0.4147.125

Smartphone (please complete the following information):
Not tested.

@talldan talldan added [Block] Latest Posts Affects the Latest Posts Block [Type] Bug An existing feature does not function as intended labels Aug 28, 2020
@galloppinggryphon
Copy link

galloppinggryphon commented Sep 2, 2020

Edit: What I report in this post was just filed as a separate issue in #25088.


I have found the same (WP 5.5.1, default Gutenberg). In addition, I noticed a difference in behaviour between certain non-text blocks that take alignment. I'm hanging it on this issue because I think it is related.

With core/image and core/buttons, the editor creates this DOM structure in the editor:

<div class="wp-block" data-align="center">
  <figure data-type="core/image"  {...other props}>{block content}</figure>
</div>

Here, alignment is not duplicated and the alignment is wrapped around the block. It is possible other blocks also follow this pattern

For most other blocks (e.g. core/table) the alignment becomes a wrapper inside the block, around inner content, and the data-align attribute is duplicated:

<div class="wp-block {...other classes}" data-type="core/table" data-align="left" {...other props}>
  <div class="wp-block" data-align="left">
    <figure class="wp-block-table">{table}</figure>
  </div>
</div>

I don't know if this is by design, but it makes it much harder to write CSS for the editor, for three reasons:

  1. Alignment wrapper is sometimes inside, sometimes outside the block.
  2. When alignment is wrapped around the block, it becomes hard to target with CSS. As I develop custom blocks, I would like the ability to target children of .block-editor-block-list__layout by data-type or even ID.
  3. In addition, the wrapper is absent if there is no alignment, meaning I have to write extra CSS rules to target a block's inner blocks with child combinators.

I can't say I was happy that alignment was separated out to its own DOM element and I would much prefer it to revert to belonging to element with the data-type attribute, which should be the immediate child of .block-editor-block-list__layout. It seems to be going in the opposite direction of lightening the editor DOM.

@youknowriad
Copy link
Contributor

I've followed the steps above and I can't reproduce this issue anymore. Thanks for the report.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Block] Latest Posts Affects the Latest Posts Block [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

No branches or pull requests

4 participants