Table Block: Default Styling

[anna-harrison]

The Table Block #850 currently gets inserted with a very simple 2x2 configuration with a thin black border applied to all cells:

This issue looks at what the default styling of the table block should be

• Number of rows, columns
• Header row, or column
• Borders
• Shading

[mtias]

Agreed this could be improved. What are your thoughts?

[StaggerLeee]

Subtle alternate rows colors, to start with. Borders not so strong in color.

[StaggerLeee]

I would suggest using deliberately smaller font size inside tables. (Difference in Gutenberg content width and front-end content width can be up to 500px. Regardless looks more nice with smaller font-size inside tables)
People making tables know what they are inserting. On front-end tables can be with bigger font size, of course. Do not know if mixing font-sizes goes against core nature.

[ammist]

It would be great if one could pull the table styling from the theme (if it has one). Is that possible w/ Gutenberg?

[mtias]

@ammist yes, that's possible. It's how I put together the videos on this post.

[gonzomir]

I think it would be good practice the default table template to include at least thead with th cells at the top. This will help the users to create more accessible content.

Shouldn't borders, colours, fonts, etc. come from the theme? The way the block sets it's styles through a class overwrites the default table styles from the theme, so setting these properties there will be in conflict with the theme.

[mtias]

The way the block sets it's styles through a class overwrites the default table styles from the theme, so setting these properties there will be in conflict with the theme.

The expectation is that themes would provide styles targeting block classes. That way we can provide defaults and let theme overwrite or disable.

[gonzomir]

The expectation is that themes would provide styles targeting block classes. That way we can provide defaults and let theme overwrite or disable.

Yes, but themes already provide styles for tables, my concern is not to overwrite them and force theme authors to overwrite again.

[karmatosed]

@annaephox do you have any mockups you'd like to share based on your suggestions?

[00travelgirl00]

I agree with the lighter color for the border. But I would not make the fonts smaller, because smaller fonts are harder to read and it is also not consistent.

Also I found the process to add or delete a new raw or column not super smooth. What about adding some Edit options to the sidebar?

Maybe there could be a setting-area for the table in general (like border-color, ...) and an setting-area for the specific raw or column wich is active. There you could set things like thead.

[samikeijonen]

Yes, but themes already provide styles for tables, my concern is not to overwrite them and force theme authors to overwrite again.

Exactly. Where ever possible there is no need to output any styles in the front-end. <table> block is one of them.

Only problem is the editor (Gutenberg) styles. They would not match the styles in the front-end. The same issue is in other blocks where theme already have styles and Gutenberg styles overlap with them. <blockquote> is one of them.

[jwold]

Wanted to drop a quick update. @annaephox, Brendan Woods, and myself have been working on some ideas for the Table Block. Wanted to drop a quick sketch that represents some of the ideas we've been going through.

1. When you add a new Table Block, you'll be presented with a blank state, asking you to input a few details about the block (rows and columns), or you can just submit and it defaults to x rows and x columns.
2. You're presented with a table based on the options you've chosen

From here you can tweak and modify the layout/styles and content of the table between the TinyMCE edit buttons and the settings panel.

We have some ideas to improve on this and will be sharing soon!

[karmatosed]

Thanks for the sketches. Some good starting points here and I would love to encourage even earlier sharing of things - my door is always open for iterating via messages along with issues. I really want to encourage you to use #core-editor or #design on .org Slack to have some design discussions also.

I do think things have got a little complicated in the sketch you are showing. Is there data evidence that this much is needed in the case of what we're doing? It feels like we've gone form a simple solution to something that maybe is too much. I totally get wanting to add a little more, but seems we've gone too far in the other direction.

Another caution is the insert having a layer, I am not sure that's intuitive to users and we are getting into a case where we have a very complicated, somewhat cluttered UI. How do other writing apps do this? What examples can you find in some research beyond Google?

I would like us to think more of what issue we're trying to solve and how we can do that in the simplest form. I am still not convinced we need 'everything'.

[anna-harrison]

@jwold : these are really neat ideas! Thanks for the sketches
As a starting point, do you think we could assume that the table block is unchanged (from its current state), and figure out some aesthetically improved styling for how that table block looks when it is first inserted (in the absence of styling from themes)?

[jasmussen]

Don't want to chime in too much here, just want to ask: can we use the CSS property currentColor to style the border color? If yes, then the border color will always be the same as the text color, which seems like a nice default rather than pure black.

[brendan-woods]

Good job on the sketches @jwold, nice to see some thoughts become pictures.

I think if we're looking for simple additions here, and I think the table block could use a few, perhaps these are the ones I might suggest:

• Ability to create initial number of rows/columns.
• More options on TinyMCE for text editing
• Ability to edit cell colour
• Border options

I'd imagine for the time being it's best to leave the side panel alone, but I think we could make some iterative changes without going too far.

[StaggerLeee]

It is a way to much styling GUI options.
Something usually themes do, and easy to call Gutenberg custom CSS file.

Of all this I personally would like to see first drag & drop table rows/columns solved.

[jwold]

Thanks everyone for the great feedback! Want to touch on a few points.

1. What I shared above represented some quick brainstorming of the potential of the block. I'm not married to any or all of the parts in the sketch. Just wanted to share a very initial work in progress, so glad to get feedback on that.
2. Based on the above feedback I agree that we need to simplify the scope of what the table block does right now, so we we can ship something that's helpful.
3. My thought right now is that we can suggest some basic improvements on this issue, then blue sky improvements can go in a separate issue.

[jwold]

Current State

The current state of the table block looks like this:

It starts with 2 rows and 2 columns and you can add rows and columns from there. There are a few challenges with using the table block in it's current state:

If you try typing into one of the cells it automatically pushes the whole column over:

If I switch to column 2 (can’t tab, have to click) it then pushes it back to center. But if my text gets longer it moves it past center. To fix this I have to drag the row or column back over. The problem with dragging is I can't see the movement of my dragging, I can only see what happens when I let go. In addition, the active target area for clicking on the dragging space is really small.

Tiny suggestions

Below are some suggestions to improve the table block.

1. Don’t re-size columns when typing - Columns should stay equally distributed by default (perhaps we could add a checkbox in the settings panel to toggle this option). At least for me, when I go to create a table, I expect to be able to type stuff in and have the column stay to the size I set it until I choose to move it.

2. Tabbing between cells
   Extremely important for keyboard use.

3. Make resizing easier
   The clickable area to start dragging should be a bit bigger. Right now when I try to drag a row or a column I have to be RIGHT on the pixel to have the cursor change to a dragging option.

4. Improve the insert/delete rows buttons

The current way it’s setup is a bit hard to read. I’d suggest we remove the icons for everything in the dropdown (but keep the icon in the menu) and re-arrange them. Or we could look at some ways to simplify the icons (the icons on Excel for iOS iPad might be something to consider)

Another approach (inspired by an awesome sketch from @brendanwoods-xwp ) would be to play around with the table block toolbar (regardless of whether it's fixed or right above the block). The main goal being to try and give another way of adjusting columns and rows.

5. Add header rows and columns

For accessibility purposes this is important to be able to set what is the header row/column. Even if we don’t allow for any styling differences, this seems quite important to include. Experimented with a concept earlier on this: #1470 (comment).

Beyond that I've added some additional suggestions to #2609 with some more advanced features we could add in the future.

[jasmussen]

Will put some more thoughts to it next week, but just wanted to note that I really appreciate your work here, @jwold, very nice.

[StaggerLeee]

Can you save yourself time and take some inspiration from this plugin ?
https://wordpress.org/plugins/advanced-custom-fields-table-field/

I really like it how this developer made it.

[jasmussen]

@jwold

Your "Tiny Suggestions" all sound good to me. @annaephox with regards to the resizing behavior, can you speak to what the TinyMCE table feature comes with out of the box? Given its pretty good track record for accessibility, I'm wondering why you can't tab between cells? Is there a different way to move between cells like arrowkeys?

Don’t re-size columns when typing - Columns should stay equally distributed by default (perhaps we could add a checkbox in the settings panel to toggle this option). At least for me, when I go to create a table, I expect to be able to type stuff in and have the column stay to the size I set it until I choose to move it.

This seems like something we should open a separate ticket for, and put into "Block Settings".

Another approach (inspired by an awesome sketch from @brendanwoods-xwp ) would be to play around with the table block toolbar (regardless of whether it's fixed or right above the block). The main goal being to try and give another way of adjusting columns and rows.

Looks good, though I'm worried it puts too much effort in quick toolbar customizations that are unique to the table block. I think we should be doing improvements (like grouping alignments into dropdowns when there isn't room) globally for the quick toolbar, which is sort of tracked in #2898. To be clear, the improvements look cool — I thought adding the alignments to the inline toolbar (because it would effectively work as inline when inside table cells) is really interesting. But the single dropdown as it works today seems worth keeping largely as is for V1 (though with the addition of the rearrangement + separator you sketched Joshua).

[brendan-woods]

@StaggerLeee Would love to hear some more thoughts from you on what you like about the ACF:Table plugin? I've been sifting through various table plugins and this is one of the better ones, in particular adding rows/columns. I think it comes up short in a few other ways but would like to hear any suggestions for improving the table block we could draw from it.

[brendan-woods]

@jasmussen yes I hear what you're saying, and I actually think if the toolbar for the table block retained the "alignment" options that are in the toolbar for the Paragraph block, this would be fine. I think the dropdowns were an attempt to save space, as the current inline toolbar for the table block has a lot of real estate devoted to entire block alignment.

[StaggerLeee]

Hi @brendanwoods-xwp.

• I like those mouseover minimalistic obstructive plus-minus icons. Works better with beginners then select menu with same options.
• I like small popup(s) for cell content. Works on any screen.
• Drag & Drop of course as most important.
• Automatic numbering of rows. For various reasons.

[StaggerLeee]

I wonder if all this lost time is worth today.

Working right now on an website and had to switch all HTML tables solutions to Bootstrap solutions. It is near impossible to make tables play nice in smartphones. Table header/footer and small screens, two different galaxies.

[BoardJames]

So the reason you can't tab between table cells is because in the table block tinymce settings we do:
table_tab_navigation: false,

This was done because otherwise it was impossible to escape the table using tab.
See #1938

[jasmussen]

Thanks for the info, @EphoxJames. If Andrea is okay with having arrowkey navigation only inside tables (and that arrow key navigation indeed works), I think it's totally fine to now have tab also.

[BoardJames]

Yeah the arrow key navigation between blocks probably makes the changes in #1938 obsolete.

[jasmussen]

Yeah the arrow key navigation between blocks probably makes the changes in #1938 obsolete.

Oh interesting — does it break the table cell arrow navigation?

[BoardJames]

No, I'm saying that the reason for turning off tab navigation was that we could not escape the block only using the keyboard.

Basically because when you press tab in the last cell it would create a new row. In TinyMCE the solution was that you just press down arrow to get out of the table but when the whole TinyMCE instance is the table there was no cursor position after the table. So to solve that we had to turn off tab navigation.

Now that the inter-block arrow key system works reasonably well it might not be needed.

[karmatosed]

@jwold, your tiny suggestions make sense and I think it's important to iterate and add slowly on these. I have to admit I am not fond of this solution:

It seems incredible complex to me visually. I am not convinced this is the right place to add extra elements that are just for a single block, in the toolbar.

[anna-harrison]

New tables in iOS Notes - worth playing around with!

[jwold]

I have to admit I am not fond of this solution:

To just followup on this, are you concerned because, as on the text alignment example, hiding two options under a dropdown is a bad use of space/mystery nav? If that's the primary concern I could see how we might want to be careful going this route.

[karmatosed]

I feel there are a few issues @jwold - the complexity of it and visibility. I do think we are creating mystery navigation. I would take a look now with fresh eyes and consider what you need or don't and iterate down.

[mtias]

Note with the proposal in #5360 we should feel free to supply a theme.scss file for the table block with whatever default design we desire, giving themes the ability to not load them if they want to overwrite from scratch.

[jasmussen]

Noting that i #6314 I did a bunch of work on the table block. It now has an option, off by default, to fix the widths of table columns, as suggested by @jwold. I also surfaced the resizing tools, so they are easier to use.

I tried to make a responsive table, this is just not doable.

In order to get moving on a "v1" of this whole table project, I would suggest the next step is to find a way to surface the "cell properties" feature in TinyMCE. This would allow a user to mark a cell as a "heading" cell, which I feel would be sufficient to close this ticket as "mvp fixed".

A v2 should probably focus on being responsive first, which as it turns out, a table can't easily be. So perhaps we need to look at flexbox for that.

[karmatosed]

I think we should close this for now, we can iterate and I suggest pulling out the cell properties feature would be a great start. We can have a new issue for that to avoid the complexity of this one and bring focus.

[helen]

@karmatosed I'm looking at our (10up's) MCE Table Buttons plugin to see what it means to create Gutenberg compatibility, would it make sense for us to investigate it as a potential core enhancement as opposed to extending the existing block or a custom block? It's a lot of functionality, which I've outlined here: 10up/mce-table-buttons#2

Happy to open a new issue for that, just don't want to wander too far down a given path without us syncing up first. At first glance it does not appear that the existing TinyMCE plugin can easily be ported over. I don't know what TinyMCE's plans are with a new plugin or where that landed. @anna-harrison @EphoxJames

I can take more screenshots, but here's a basic look at what the current button adds:

[karmatosed]

@helen I think that totally makes sense and a new issue would work.