Table feature

[Reinmar]

We plan to bootstrap the table feature very soon, so let's do it under this ticket. I don't have any concrete information yet, so I'll just leave this ticket like this...

[scofalik]

One of the first things we have to settle on is how will we represent a table in the model structure. The easiest and more obvious solution is by doing it how it is in HTML. However, keep in mind that our model gives us some room for experiments. Maybe we can gain something from a different table representation in the model, as we did with lists. Lists converters got much complicated in the process, but we were able to use same mechanisms and algorithms as we had for paragraphs which was a big gain.

Another thing is an "add row + add column" collaborative-editing problem. We had an idea to use deltas for this, but since we already decided to drop deltas, we will have to resort to either having this managed by post-fixer or having this managed by a custom model data structure.

[fredck]

This is a preliminary analysis of requirements.

When it comes to use cases, we want to support data tables. This comes in contrast with the use case we don't want to support at this stage, which is clearly described in the HTML5 specs for tabular data:

Tables should not be used as layout aids. Historically, many Web authors have tables in HTML as a way to control their page layout making it difficult to extract tabular data from such documents.

We'll still see developers asking for the above though and we'll handle such requests in a separate issue.

Macro elements

The macro elements of the table feature are:

• Table: represents the whole table, including the following elements:
• Row: a sequence of horizontal cells.
• Column: a sequence of vertical cells.
• Cell: the smallest unit of the table.
• Caption: a caption description for the table.

Users would like to operate on all the above elements.

HTML-wise, we follow the Editor Recommendations specs on tables.

Features

These list of features may be incomplete and it focuses just on UX and high-level features. The order in the list matters as this is the proposed way to releasing enhancements to the feature as a whole.

Milestone 1 (MVP)

• Insert / remove tables.
• CSS controlled styling (kinda nothing to do here... it should just work).
• Custom selection (table).
• Type and insert content inside cells and the caption.
• Caret navigation through the cells.
• Insert row / column.
• Remove row / column.
• Merge cells (if UX is found for it, otherwise part of Milestone 2 will have to be anticipated).
• Table copy / paste.
• Set the table header rows.

Milestone 2

• Custom selection (table + row + columns + cells).
• Multi-cell styling.
• Multi-cell copy/paste.
• Styles, which set classes to tables, to define alignment (like image styles) and different design for different kinds o table.
• Set the table footer rows.
• Column resizing.
• Rearrange rows and columns (move them). This may be available as copy/cut + paste first and later as DnD.

Details

• Captions should work exactly like in the image feature.
• Cells selection can contain multiple cells in both horizontal and vertical directions in the middle of a table.
• Coping cells sends a table to the clipboard based on the subset of cells selected.
• Pasting behavior is to define, much probably based on CKEditor 4.

[Reinmar]

CSS controlled styling (kinda nothing to do here... it should just work).

There's one tricky bit – table's default width. If you won't set any then it's 0px and you can't put caret inside table cells. 100% width is not always preferred. Padding in table cells may help, but it's not applied by all developers (depends on page styling). Etc, etc.

I also wonder if we shouldn't propose a similar feature here as image styles. In a certain way, tables are very similar to images (they are blocks of content). (EDIT: I can see it's in milestone 2)

Set the table header rows.

Two things here:

• do we need/want to support setting multiple rows as headings?
• should we support the scope=row attribute? (I guess this is a valid, but rare case so we can skip it, yes?)

Merge cells (if UX is found for it, otherwise part of Milestone 2 will have to be anticipated).

What about split?

[pjasiun]

One of the first things we have to settle on is how will we represent a table in the model structure. The easiest and more obvious solution is by doing it how it is in HTML. However, keep in mind that our model gives us some room for experiments. Maybe we can gain something from a different table representation in the model, as we did with lists. Lists converters got much complicated in the process, but we were able to use same mechanisms and algorithms as we had for paragraphs which was a big gain.

I am against having a custom data format (no surprise ;) ). I was thinking about some formats we could use and don't see much we can get using a custom one, but I see much we can lose.

Another thing is an "add row + add column" collaborative-editing problem. We had an idea to use deltas for this, but since we already decided to drop deltas, we will have to resort to either having this managed by post-fixer or having this managed by a custom model data structure.

I think that post-fixers are the way to go.

[oleq]

I was thinking about the UX of the feature and this is what it should look like IMO:

Insert / remove tables.

That should be possible using the (main) toolbar button, which opens a drop-down representing a clickable, highlightable grid. Using the grid, the user selects the shape of the table they want to insert at current caret location (2x2, 1x4, etc.).

CSS controlled styling (kinda nothing to do here... it should just work).

I think the table should come with an in–place toolbar just like the image, which offers different styles (side table, full–width table).

Type and insert content inside cells and the caption.

The caption "field", just like in images, should appear once the selection lands in the table.

Insert row / column.
Remove row / column.
Merge cells

This is where things become tricky. Most text processors use contextual menus to provide these features and we don't have this option. That's why we must either:

• put these features in the table button in the toolbar, e.g. below the grid, when the selection is in the table
• create a contextual menu that floats in the table cell, which sounds like a better idea to me.

We can't use the image–like balloon toolbar here because it's huge and we can't cover the content with it. There's a lot of things happening around the table so this UI must be small and smart.

BTW: Let's create a ckeditor5-table repository with dedicated issues for the engine, UX, UI, etc..

[fredck]

When it comes to the caption, it is still unclear to me if this should be in the bottom, like in images, or at the top.

Anyway, I found this interesting resource, which clarifies how CSS can control its positioning:
https://www.w3.org/Style/Examples/007/figures.en.html

So, it doesn't matter much if we output it at the beginning or the end of the figure element. Maybe to make it in line with the image element, we leave it at the end.

[wwalc]

@oleq Regarding the dropdown in table cells, how it would work? Would the menu button appear only when the cell is selected? I'm wondering how a table with some financial data would look like (plenty of narrow columns with numbers) with this proposal.

[oleq]

Regarding the dropdown in table cells, how it would work? Would the menu button appear only when the cell is selected?

Yes, that was the idea. Then I figured it might not be the best idea after all because of what you just mentioned. Knowing that, I'd rather see a balloon attached to the table cell instead.

[jefflam]

@oleq I thought Froala's (https://www.froala.com/wysiwyg-editor) way of handling the UI for tables -- both for inserting them and for modifying them on cell click, is pretty clean and simple.

With regards to the modifying of tables on cell click, they do have quite a bit of bells and whistles though, hence resulting in quite a bit of buttons.

[fredck]

Thanks for the feedback, @jefflam.

We've been considering that option and we're now undecided whether to attach the toolbar to the cell or to the table, so we have just one static toolbar floating around, instead of having it moving over the table contents whenever I move between cells.

What do you think about that option?

[jefflam]

There are definitely pros and cons for both decisions, but the concern I would have with one fixed static toolbar would be the lack of context in making changes: i.e. adding a row below a certain row, or a column to the left of another column.

In addition, in the event that a table grows quite large, would the static table toolbar -- if say, positioned at the top of the table -- make it a hassle for the end user to make changes contextually and quickly?

[fredck]

By static, I meant to say that it is always in a predictable place, no matter the cell you are. If you start scrolling on a long table, we could think about having the balloon stuck to the top of the viewport, always visible to the user. But this is indeed a problem to take in consideration though.

[fredck]

An additional problem is that the editor itself may have its main toolbar stuck at the top of the viewport, so the table ballon could collide with it.

It sounds like the "on cell" toolbar is leading this contest.

[DaveInMaine]

Just wanted to mention that there is another use case for tables when creating HTML email content. For HTML email, "tables" are really the only possible mechanism for controlling page layout. So for users creating html email content, there may be a layout table (maybe 100% height and width, invisible borders). Then one cell in that layout table would typically be the main content cell. That cell would contain paragraphs, headings, images, or even other (tabular data) tables.

Probably, a layout table would be managed by a separate plugin - like an Email Layout Template plugin. I just mention it here so that when designing support for regular tables, you can consider the possibility that a table might be nested inside a cell of another table. The normal table editor should probably ignore the layout table (maybe some class name says "I'm not a real table, ignore me") as any layout properties would be set by the layout-table plugin.

I guess the only real concern for your regular table plugin would be that the regular table implementation does not break if the table is inside a cell of an outer layout table.

[fredck]

Probably, a layout table would be managed by a separate plugin - like an Email Layout Template plugin.

+1

Very well said... I totally agree that this is a different use case that requires its own implementation to work right.

But then, what is the really right way to face this requirement? Have an editor where you can insert a layout table inside of it or having an application tool that handles the layout tables and then create small little editors inside such table cells, eventually even having different editors for different purposes (title, text, image, etc.).

I would go with the later option. It is much more work ofc, but it makes a much more powerful solution.

[Reinmar]

Closing in favor of https://github.com/ckeditor/ckeditor5-table/issues/1 (and issues reported in that repository).

[Reinmar]

I reported https://github.com/ckeditor/ckeditor5-table/issues/3 to discuss functional requirements for this feature.

[Reinmar]

I can see that people look for this ticket, so I'm reopening. I shouldn't have closed it until it's done.

The entire development of this feature takes place in the https://github.com/ckeditor/ckeditor5-table repository.

• https://github.com/ckeditor/ckeditor5-table/issues/3 contains functional requirements
• https://github.com/ckeditor/ckeditor5-table/issues/1 discusses the UI aspects

[retro-blaster]

@Reinmar

Have you considered providing support for complex, accessible data tables?

[Reinmar]

For now, we're going to implement the accessibility level defined in http://ckeditor.github.io/editor-recommendations/features/table.html. With time, we may add more a11y features. That would certainly be nice and we'd like to do that.

But, at the same time, we will need to be realistic about the cost which may be significant because designing and implementing usable UI for such features is generally tough. And I'm curious what's the benefit. How many people will actually use such a feature? How many of them will do this correctly? How often people create such complex tables? Actually, the longer I think about this the more I'd see this as a 3rd party plugin.

[Reinmar]

cc @Comandeer

[fredck]

Those sound like advanced HTML editing features, while we must be focused on creating a text editor that produces quality content without making it too technical. It must be a well-balanced solution without going to extremes in any direction.

The "summary" feature is one we could take in consideration for the future, though, similarly to what we have for the "alt" attribute in images.

[jodator]

I can see that people look for this ticket, so I'm reopening. I shouldn't have closed it until it's done.

@Reinmar Since we've published Table feature as an MVP I think that this might be closed as the discussion on particular tables features & bugs would go to https://github.com/ckeditor/ckeditor5-table. Also many ideas from this ticket are already obsolete.