Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Fix table regressions. #9306
This PR fixes table block regressions introduced in #7899 (comment)
The block property for the table makes sure that it's mobile responsive. The "display table" is necessary for fixed layout to work.
Note that the responsiveness for the table is in the
Please test this PR with and without the fixed table cells option enabled, frontend and backend. And please verify that this PR does not regress what #7899 was meant to fix.
Wondering if there could be any alternative fix for unresponsiveness. I'm guessing tables are by nature unresponsive though... If you have a few columns, you'll want to scroll them, not have them all squashed together. I wouldn't mess with the normal CSS rules of a table to make it more responsive. Could it help to wrap the table in a (scrollable)
All good feedback, thank you.
As a preface, there are two features of the table block being discussed. One is the fixed layout, which is off by default and toggled on in the sidebar.
The other is the responsiveness, which, note, is stored in the
But the idea here is that every block should come with a minimum level of mobile responsiveness. And a "true" responsive table isn't really a table anymore, it's a rather complex collection of divs put together to look like a table. This is completely fair to explores separately, but as the vanilla offering we have to consider the basics which are accessible.
For that reason, the most minimal responsiveness I could find, was to have the table scroll horizontally, if less than 360px wide. You can see that here: https://codepen.io/joen/pen/RYojVZ
Due to the nature of how the
Here's a GIF:
If we can accomplish a minimally responsive table in a different way, I'd love suggestions.
I think the thead and tfoot should also be added. I feel a bit uncomfortable with changing the display of a table from the default, but if this is valid and the way to do it, ok. Is there any way tests could be added for this (unsure here)? This seems like something with so many different configurations that we could easily break in the future.
I could use some help getting this PR in ship shape if you have bandwidth. I feel strongly that all blocks we ship should have some measure of responsiveness, remember it's opt-in for themes.
Right now both the responsiveness and the fixed-cell-width are broken in master, so it would be nice to find some solution soon, even if we need to refine it later.
Hmm, you're right. And this suggests @iseulde was right to be nervous as well, because what causes the table to collapse like that is the changing to
I pushed a fix in b7d41bf, and I do think we should merge this because it fixes a regression — it is frustrating that the fixed width switch is broken in master.
But if we discover that changing the display properties of the table, thead, tbody, and tfoot, we should look at an alternative fix, which I think would include a wrapping div, see: https://codepen.io/joen/pen/RYojVZ.
What do you think? Should we get this merged so we can fix the regression?
Aug 30, 2018
1 check passed
thead, tbody and tfoot need to be set to their default style properties for columns to properly align. We then also have the secondary issue that the table needs to be
Unfortunately it looks like we need another approach. Probably a wrapping
Seeing as we're discussing it on #9801, I think I'll introduce a fix there. That PR also handily introduces a block deprecation, so probably makes sense to handle it there.