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

Fix table header and body column misalignment #10011

Closed
wants to merge 7 commits into from

Conversation

talldan
Copy link
Contributor

@talldan talldan commented Sep 18, 2018

Description

Fixes #9779 - table header misalignment issue

Changes:

  1. The issue was caused by thead, tbody and tfoot elements being given the display: table property (SO explanation - https://stackoverflow.com/a/12153220). This styling has now been removed so that the elements have their default display property.
  2. table-layout: fixed; was previously applied on the thead, tbody and tfoot elements, but since they're no longer display: table that was no longer working. This style is now applied to the table element and the table element has been changed from display: block to display: table
  3. The above changes break the overflow-x: auto style that was applied to the table element, so a new wrapping div has been introduced to the editor and front-end rendered output of the block. Overflow is now applied to this div.
  4. Table block deprecation has been introduced since the output of the block has been changed.

How has this been tested?

Column alignment

  1. Paste a table with a thead directly into the editor (e.g. <table><thead><tr><td><strong>Column One</strong></td><td><strong>Column Two</strong></td></tr></thead><tbody><tr><td>one</td><td>two</td></tr><tr><td>three</td><td>four</td></tr></tbody></table>)
  2. Observed in the editor that the table header columns are aligned with the body regardless of whether the 'Fixed width table cells' option is enabled.
  3. Observed in the preview that everything is aligned.

Overflow

  1. Enter long content without spaces or line breaks in a cell to make the table wider than the editor width.
  2. Observed that the user can scroll horizontally in the editor to view all the content of the table
  3. Observed that the user can scroll horizontally in the preview to view the entire table. (To test this, add_theme_support( 'wp-block-styles' ); needs to be added somewhere (e.g. in client-assets.php)).

Fixed width table cells

  1. Toggle fixed width table cells
  2. Ensured that table cells are equal spaced and that long content wraps in both the editor and preview

Deprecation

  1. Create a table block on master branch and save post
  2. Checkout this branch and load post in editor.
  3. Ensured 'This block has been modified externally.' message is not present, and table displayed as expected

Screenshots

Before
screen shot 2018-09-18 at 6 09 04 pm

After
screen shot 2018-09-18 at 5 57 30 pm

Types of changes

Bug fix (non-breaking change which fixes an issue)

Checklist:

  • My code is tested.
  • My code follows the WordPress code style.
  • My code follows the accessibility standards.
  • My code has proper inline documentation.

@talldan talldan added the [Type] Bug An existing feature does not function as intended label Sep 18, 2018
@talldan talldan added this to the 4.0 milestone Sep 18, 2018
@talldan talldan self-assigned this Sep 18, 2018
&.has-fixed-layout tbody,
&.has-fixed-layout tfoot {
display: table;
overflow-x: auto;
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@jasmussen ah, I think this should be in theme.scss instead of style.scss, is that right?

Copy link
Contributor

Choose a reason for hiding this comment

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

Fixed-width layout has to work everywhere because it's a user-set option.

But the table doesn't have to be responsive out of the box, no, so okay to remove the width, min-width, and overflow rules and put those in theme.scss 👍 👍

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for taking a look at this 😄

I've moved the overflow rule to theme.scss 👍

@talldan talldan mentioned this pull request Sep 18, 2018
4 tasks
@jasmussen
Copy link
Contributor

Very cool, thanks so much for working on this. Really really appreciate it.

It seems to be working:

screen shot 2018-09-19 at 08 34 44

I detected an issue with my own theme as part of this where I broke the files. But that was an issue in my theme.

Awesome work.

- `table` element needs to be `display: table` so that `table-layout: fixed`
works correctly.
- `thead`, `tbody` and `tfoot` need to use their default display properties,
otherwise columns become misaligned between header, body and footer. (#9779)
- Remove unecessary width on `thead`, `tbody`, and `tfoot` which is implicitly
100%
@talldan talldan force-pushed the fix/table-misalignment branch from 3aad4db to eab3703 Compare September 19, 2018 10:23
@talldan talldan requested a review from a team September 20, 2018 11:49
Copy link
Member

@noisysocks noisysocks left a comment

Choose a reason for hiding this comment

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

Looking good! Will test this in a bit 🙂

<Section type="body" rows={ body } />
<Section type="foot" rows={ foot } />
</table>
<div className={ classes }>
Copy link
Member

Choose a reason for hiding this comment

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

It's unfortunate that we have to introduce a wrapper <div>. Are there any alternatives? I wonder if Gutenberg could be less opinionated about this and leave table overflow styling up to the theme?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sadly no other solutions I could find. Table elements are designed not to overflow and always grow to fit their contents.

@jasmussen what do you think about this suggestion of not worrying about overflowing tables?

Copy link
Contributor

Choose a reason for hiding this comment

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

I feel like by putting these styles in theme.scss we are already making themes opt in to this, and I also feel like we need a responsive play for any block that comes with Gutenberg. Even by making this opt in we're already watering down that aspect a bit.

If that requires a div to be compatible, I think that's okay, but as is always the case I'm okay with being overruled by @mtias or @karmatosed

Copy link
Contributor Author

@talldan talldan Sep 28, 2018

Choose a reason for hiding this comment

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

Hey @jasmussen & @noisysocks - after a chat with Matias, I've decided to try an alternative where we wrap content instead of overflowing it. The advantage is that this doesn't involve a deprecation and is a much smaller change. I think it'll also be easier to undo if we decide change our minds in the future. There's a new PR here:
#10230

I'll close this one, but it's here in case we need to refer back to it.


supports: {
align: true,
},
Copy link
Member

Choose a reason for hiding this comment

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

In other parts of the codebase we pull the attributes and supports object out into variables so that we can re-use them both in the block definition and in the deprecated object. Might be worth doing this here as a way of simplifying things.

deprecated: [
	{
		attributes,
		supports,
		save( { attributes } ) { ... },
	},
],

Copy link
Contributor Author

Choose a reason for hiding this comment

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

👍

Given that, I'm guessing that deprecated blocks don't care about newly added attributes? Would they just ignore them? There aren't any in this PR, but I do have some in another PR.

Copy link
Member

Choose a reason for hiding this comment

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

Judging by the source code, that should be safe, so long as the new attribute doesn't cause the output of the old save function to change. (I can't think of an example that would.)

&.has-fixed-layout thead,
&.has-fixed-layout tbody,
&.has-fixed-layout tfoot {
display: table;
Copy link
Member

Choose a reason for hiding this comment

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

Letting the <table> be a display: table makes sense 🙂

@noisysocks
Copy link
Member

noisysocks commented Sep 25, 2018

Everything works great in my testing except for this step:

  1. Observed that the user can scroll horizontally in the preview to view the entire table.

screen shot 2018-09-25 at 14 04 00

I'm using the default WordPress theme.

edit: I was missing a add_theme_support( 'wp-block-styles' ); 🙂

Copy link
Member

@noisysocks noisysocks left a comment

Choose a reason for hiding this comment

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

Works great in my testing!

@talldan
Copy link
Contributor Author

talldan commented Sep 25, 2018

Thanks for the review! Pushed commit f7a8fc3 to make those recommended changes. Will wait on an answer to the thread above before merging.

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

Successfully merging this pull request may close these issues.

Table Block: table cells in thead are misaligned when "Fixed width table cells" is toggled off
3 participants