Gutenberg: Add table block to Insertion Block

[aahani]

Adding Tabbed Interface to Insertion Block (https://github.com/WordPress/gutenberg/issues/81 ) is a great idea. I thinks its better to consider adding a table block (https://wordpress.org/plugins/mce-table-buttons/) to it:

1. Insert table block:

2. Edit table block:

[jasmussen]

A table block is a good idea. See also #16

[androb]

I would guess tables is a big reason why TinyMCE Advanced is popular.

Whether it is supported in core, or can be added back via a plugin the way TinyMCE Advanced does right now we definitely need to make it possible. There will be screams otherwise :)

[TheSpyder]

For editing tables, extra buttons on the contextual toolbar are much better than a menu. Play with tables on the tinymce.com front page demo; common operations are available immediately (the menu is still available for less frequently used operations).

[mapk]

Wow, the Table block is no joke! This is complex. I've created some UI thoughts around these to be inline with our current direction. The UI design might be off, but I'm hoping the interaction aspects are close.

Table block - Selected
This follows similarly to @iseulde's current prototype. Basically when selected, only high level table layout is shown.

Table block - Dropdown to change block
Would the table be able to be converted into some other block? If so, I'm keeping this inline with our current block switcher.

Table block - Edit Table
I'm surfacing the ability to add/delete rows/columns. It seems the common practice is to hide these abilities to a 'right-click' event, so I'm not entirely sure which direction we want to go. One problem with this version below is that, while it is surfaced visually, it also adds another dropdown to the menu.

Table block - Edit Text
We have a way to edit the table, but we need to edit the text within the table cells. So when the user has highlighted text, this should remove the table editing menu items in place for text editing menu items. Does this sound right?

There's even more UI work that needs to be done like "border styling" for tables, etc. I'm sharing some early thoughts to get conversation going on how we want to approach this.

I love the ability to prompt the user to select the rows and columns right away like the current textbox.io and Google docs does. I'm trying to understand how that would fit in with the current "Block Creator" we've got going.

@annaephox Any thoughts around this?

[TheSpyder]

If you're going down the menu route I recommend the structure we use in textbox.io. It groups functions by target cell(s) instead of by insert/delete. We have found this to be a much more natural structure, and as an added bonus you don't need to repeat the word "row" or "column" in the submenu text.

These are screenshots of the context menu.

[jasmussen]

Solid work @mapk! Thanks for tackling this. Overall it seems like you've been stellar in following the UI patterns we've laid out so far, that's heartening to see.

Some quick thoughts:

Table block - Dropdown to change block

They key for the switcher is that conversions have to be non-destructive, and allow plugins to register themselves as nondestructive conversions. In this case I can't think of any conversion that might make sense.

Incidentally that highlights a good question: should we simply not show the switcher, when it's not useful? Or should we show it as disabled? I'm leaning towards the former, even though in the audio block, I mocked up the latter:

Table block - Edit Table

Table block - Edit Text

For now — and this will require more exploration — the "Edit" button is intended to open either a modal, or an "inspector" in the sidebar. See mockups here: https://wpcoredesign.mystagingwebsite.com/gutenberg/#admin

This would prevent it from being a dropdown.

I think you are on to something, though, and combined with advice from @TheSpyder and inspiration from Textbox.io, I think we can find something that would work well in our universe where toolbars are highly contextual, which you so perfectly captured in the "Edit Text" portion.

Think of toolbars like this:

[Switcher] [Block level] [Inline Level] [More]

The above would be contextual to what you have selected, as you've captured already.

I'm wondering what the simplest possible implementation might be. Could it be enough that you simply type in, numbers-wise, how many columns and rows you have? I.e. there could be a "Configure Table" button that opens a modal to let you type in numbers.

Alternately it sort of feels like we have to go ultra contextual here. When a single cell is selected, you have insert row, insert column, delete row, delete column.

When you want to merge two cells, you have to drag across them to select, to surface a "merge cells" button.

---

The above may be overthinking it, though. I believe TinyMCE has a table block with some of these features already. @annaephox can you provide some screenshots or context? Perhaps we can simply use the TinyMCE block as-is, with just a little bit of UI refresh?

[jasmussen]

Let's omit the caption option, btw, and keep this primarily for media items. If you want a caption you should be able to center text below it.

[mapk]

I made a few visual changes based on some of the above feedback.

Selected Table Block
I dropped the block-switcher and changed the 'edit table dropdown' icon.

Edit Table
I'm still keeping all functions in one dropdown. While it does add more text options here, I feel more comfortable showing it all together with dividers rather than extending further sub-menus. I'm open to discussion here though! :)

Merge Cells
Surfacing the 'merge cells' option in the dropdown when it's relevant.

Edit Text
Swapping out inline menu with relevant edit options.

[jasmussen]

💖 Really love this.

The dropdown is growing on me. Though perhaps we can use a table icon instead of the cog. We are using Dashicons for the actual plugin, so you can use perhaps this icon from that set. The mockups/sketch file still use Gridicons, no reason to swap those out, we'll need them for Calypso down the road regardless.

The final question remains: if we are to leverage TinyMCE here, can we do the above, @annaephox?

[mapk]

Yeah, the dropdown worked better for me than these:

I didn't quite understand what those ^ arrows did until I clicked them, then it added a column or row, but I didn't know how to remove it. So I don't think having individual buttons/icons for these actions works well.

The dropdown provides space for clear text instead of vague icons. My thoughts around the dropdown were thus:

1. The dropdown should be accessed from a contextual menu item as I have it in the mockups instead of a right-click action. Maybe it could also appear on right-click, but that shouldn't be the only way.

2. I like having all relevant options visible in one list. It's nice to get an overview of what my options are instead of hovering over items to get a third-level sub-nav to show me my options.

I'd love to hear other's thoughts!

[joyously]

I'm all for text instead of icons! My brain apparently works differently than most, and I have a hard time figuring what the icons mean.
But I don't know about the translations. There was a recent discussion on the media widget (I think it was) about how some languages have much longer words and they don't fit on the buttons -- or on the menu.

[jasmussen]

I'm not sure where you got that existing table block from. It looks like it could have been a screenshot from one of the prototypes, but I can't find it. In any case, you should not take any preceeding work as gospel for how this should look, as little to no design work has actually been put into a table block yet (except for the work TinyMCE has done, which is why it's good to sanity check with them). Absolutely run with what you feel works best here.

The dropdown feels good primarily because it:

a) can hold a lot of options
b) those options are likely "set it and forget it" somewhat advanced options you might not need all the time
c) it frees up valuable whitespace

This has less to do with icons vs. text, which is sort of a "settled debate". Icon plus label always reads better than icon or labels on their own. But we still need to be thoughtful here, because if an icon _can_ stand on its own (and it seems Bold and Italic have proven that they can) it means we can fit more options in the same visual space.

I noticed something that might beg us to reconsider a bit. Compare this

and this

These two together make it feel like the dropdown works only when a table cell is _selected_ (i.e. drag+release), and the formatting options only appear when the caret is placed inside a cell. Both should probably work. That is, place the caret inside a table cell and you can use both dropdown and "insert column to the right".

Edit: The difficulty I'm seeing is: how do you select just the table, vs. place the caret inside a cell? Do you click the block boundaries? (That might actually work fine). In any case this might be one of the things where just starting to build the block is the way to go.

[afercia]

Ideally, tables should be used to present tabular data. There's bit of ambiguity in the spec, it implicitly admits that tables can be used also as a layout aids.

Layout tables can be built in a way that doesn't introduce accessibility barriers. The spec itself suggests a few techniques, such as the use of role="presentation", to help user agents and assistive technologies understand the table is used for layout purposes. Also, any element or attributes that assistive technologies could use to identify a table as "data table" should be removed.

Instead, data tables should make full use of those elements and attributes.

If the editor is really going to allow users to use tables, then the two cases should be distinguished and should use different markup. Otherwise, I'm afraid there's the serious risk to encourage the production of non-accessible content.

[ellatrix]

I think I've tried to point this out several times, but adding tables does not mean that we should allow just anything to be put into them. We can just limit it to inline text. If people add stuff to them in the text editor, then sure it's probably more presentational, but they can do this today too. We can visualise it, but not allow anything more than text to be added, which is the case today too. The only difference is that we would allow people to add tables with text in the visual editor.

[afercia]

Sure, that doesn't mean the Table block should produce invalid and not-accessible content though.

What users can paste in a "freeform" block can't be prevented. However, if the Editor is going to have a Table block, it should ensure it produces nice, semantic, accessible HTML.

Layout table:
should use role="presentation" and don't allow thead, tfoot, tbody, th, and the scope attribute. Should use just tr and td.

Data table:
should allow all the above semantic elements and ensure they're used properly.

[ellatrix]

For inserting columns and rows, I was thinking about something like this. Of course the question is where to put other buttons at the top.

       [+] [×] [+]
+-------+-------+-------+
|       |       |       |
+-------+-------+-------+ [+]
|       | Text| |       | [×]
+-------+-------+-------+ [+]
|       |       |       |
+-------+-------+-------+

cc @joen @mapk

[ellatrix]

Ooor

|      [+] [×] [+]      |
+-------+-------+[+]----+
|       | Text| |[×]    |
+-------+-------+[+]----+
|       |       |       |
+-------+-------+-------+

[jasmussen]

I like that. We could use the "floating toolbar" chrome for the toolbars. Would be fun to see those as vertical toolbars on the right.

This material for the plus buttons:

[ellatrix]

Yeah I meant the toolbar design that we already have. Sorry for the plain text mockups, but I guess they're the ultimate lo-fi mockups. 😄

[jasmussen]

No no I realized after the fact that was probably what you meant. I just got excited!

[anna-harrison]

Hi! @EphoxJames is making progress on the table block - a few questions regarding the finer details:

_Table operations_

• Should these be in a dropdown as per @jasmussen sketches above (from a "settings" cog on the right)
• Should they be off a floating toolbar positioned (inside?) the table itself as per @iseulde sketches above (nice ascii-art BTW :-)
• Should they be as per TinyMCE contextual toolbar - @EphoxJames is experimenting with this in a branch, screenshot below (we have adapted icons from TinyMCE: I think we'll want to update these)

A more general question: it looks like gutenberg is positioning the contextual toolbar (in this case the table operations) as the left-most toolbar. Is this what we want? I ask as, intuitively, I was expecting that this toolbar will be placed on the right (but it's possible that this expectation is not universal). What do you think?

[jasmussen]

Nice!

Should these be in a dropdown as per @jasmussen sketches above (from a "settings" cog on the right)

I think either is fine at this point. I think the important thing is we get the actions in there, then we can iterate!

Should they be as per TinyMCE contextual toolbar - @EphoxJames is experimenting with this in a branch, screenshot below (we have adapted icons from TinyMCE: I think we'll want to update these)

In the Editable component, we have an inline mode which we're using for captions. This places the toolbar in context of the field being edited. I think that could work well for table cells, so we don't need bold, italic, etc. from there.

In general I think we should avoid any "onSelect" invoked toolbars, like those of TinyMCEs Inlite theme.

A more general question: it looks like gutenberg is positioning the contextual toolbar (in this case the table operations) as the left-most toolbar. Is this what we want? I ask as, intuitively, I was expecting that this toolbar will be placed on the right (but it's possible that this expectation is not universal). What do you think?

The sort order we want is [switcher] [style] [block level] [inline level]. Style is for blocks that have multiple styles like quotes. Block level is alignments or floats, that apply to the whole block (with a few exceptions for alignments, which apply to the HTML block element).

In this case I'd put the table operations after alignments, but before the inline tools (though per the comment previously it would be nice to use the Editable inline mode for those). Also, the table will probably not have a switcher, it doesn't seem to make sense so good on that front.

[EphoxJames]

The block.js (which is what I am currently using via registerBlock) seems to have the items ordered [switcher] [block controls] [alignment controls] [style controls]. To change the order I'd have to somehow override that - maybe by providing a different value to the <Fill name="Formatting.Toolbar">? Honestly I'm not certain how that works so it may not be possible.

[youknowriad]

If we follow the path proposed here #830 each block would control the order of the controls itself.

[EphoxJames]

I've had a chance to go back and update my vision of the table block now the list indenting is merged and I have a better idea of how to access the TinyMCE instance. I've put in a pull request (more a request for comment but it could be evolved into a worthy replacement for the current table block):
https://github.com/WordPress/gutenberg/pull/850

[EphoxJames]

@jasmussen I changed my pull request to put the table functions in a menu. It's not like your concept yet but it is closer:

[jasmussen]

Looks great!

[jasmussen]

Can we replace the menu icon with a table icon? Like https://developer.wordpress.org/resource/dashicons/#editor-table?

Also, do you need dashicon versions of the various insert/delete icons in the menu?

[jasmussen]

Oh looks like you already did in https://github.com/WordPress/gutenberg/pull/850/files/e591c3116b3eda88a0da8ea8fdcd27431e9214ec..7af4bba1d8ca0d10df61be69debfe914b55b18e5, nice.

[EphoxJames]

Yes, I switched out the generic icon for the table icon that you suggested. I have now also added the block alignment modes from the existing table block.

[jasmussen]

The pull request (#850) looks like it is on a great path. To limit discussion, and simplify the beta milestone (https://github.com/WordPress/gutenberg/milestone/7), I'm closing this one as fixed! 🎉

[StaggerLeee]

Best to make all cells draggable. If it is not much coding and would slow down whole project.

[EphoxJames]

How would you envisage that working? Would you select some cells then dragging them somewhere would be like copying and pasting the content? Would you only allow dragging one cell/row/column at a time and then swap it with the one at the drop location?

[StaggerLeee]

Drag & Drop rows and columns. Cell separate cannot be dragged, it would not work. My mistake, wrong explained.
See how Tablepress plugin works, or Table addon for ACF field.

[jasmussen]

One of the key values for Gutenberg is to ensure that every important action that can be taken in the editor needs to be available as a clickable (or tab then space) action. Drag and drop is totally cool to explore once those basic actions are in place. For example we have moving blocks up and down using the arrows, so it's fine if someone wants to explore adding drag and drop to blocks on top of that.

In this case, I think the dropdown interface used for tables is pretty good.

[StaggerLeee]

Do anything but not like old TinyMce table plugin. Anything is welcome. This old one was simply not usable. Not even for experienced editors.