Allow to split cells only if they have been merged

[Alfonso Martínez de Lizarrondo]

I don't know about you, but in my mind splitting a cell that hasn't been previously merged just looks strange.

By restricting those operations only to cells that have colspan or rowspan >1 we will avoid ugly tables and the code will be very easy to manage, we just need to decrement the colspan or rowspan value, there's no other things to worry about.

[Koen Willems]

I'm sorry, but to my opinion that would seriously decrease flexibility.
Especially when one has to create a complex table the possibility to split a cell is of great importance (previously beeing merged or not).
Furthermore I wouldn't know why a table with some splitted cells would be ugly.

Regards,

Koen Willems

[Alfonso Martínez de Lizarrondo]

From my point of view, splitting any cell is linked to using tables for layout, instead of being used properly for data.

There will be always things that could provide greater flexibility, but that they are bad for example for accessibility, and I think that we should try to help the user avoid that kind of mistakes, instead of adding all kind of things "because they might be useful".

Splitting a cell means adding a new row, and then merging the cells of both rows (excluding the splitted one), and I fail to see how that fits in a data table. Merging two header cells into a single one is logical, but splitting in order to create a new row is strange.

And this way we avoid showing two options in the context menus, so usually it will be better for the user to find what they need. Less options -> less time to read them.

[Koen Willems]

I can agree that tables should only be used for a tabular representsation of data and not for layout purposes.
But on the other hand: sometimes a webeditor has to make a complex table and in those cases the option to split a cell is of significant importance.

Let me show three examples (but i can send more):

​http://www.regels-stadskanaal.nl/regelingen/Legesverordening_Stadskanaal_2008/01-03-2008 (scroll to the bottom)
​http://www.regels-stadskanaal.nl/regelingen/Handhaving_kwaliteit_kinderopvang_en_peuterspeelzaakwerk_Gemeente_Stadskanaal/27-07-2006
​http://www.regels-stadskanaal.nl/regelingen/Handhaving_van_de_milieuregelgeving_in_de_gemeente_Stadskanaal/27-04-2006(see table number 4)

Regards,

Koen Willems

[Alfonso Martínez de Lizarrondo]

The table at ​http://www.regels-stadskanaal.nl/regelingen/Legesverordening_Stadskanaal_2008/01-03-2008 is a perfect example of why this feature can be used wrongly.

At 10.2 and 10.4 there are what should be two nested tables, but they have been created by splitting the column, and that way they are forcing the rest of the rows to have a colspan that is wrong, those columns aren't really part of the main table.

In ​http://www.regels-stadskanaal.nl/regelingen/Handhaving_kwaliteit_kinderopvang_en_peuterspeelzaakwerk_Gemeente_Stadskanaal/27-07-2006 (I don't understand the data to know if what I'm proposing could be right or wrong), I would have put the splitted rows of Sanctie-instrument in a single cell, as different paragraphs, or as <ul> <li> items

​http://www.regels-stadskanaal.nl/regelingen/Handhaving_van_de_milieuregelgeving_in_de_gemeente_Stadskanaal/27-04-2006 is a typical usage of headers, and I think that it's almost as easy to do it splitting the cells than adding the new row and merging the desired cells.

[Koen Willems]

Considering your comment on my first example: amongst others it's my strong opinion that nested tables decrease accessibility and should be avoided as much as possible. I would like to refer to an article Joe Clark wrote about this subject: ​http://joeclark.org/book/sashay/serialization/Chapter10.html.

About my second example: that website contains the legislation of a city. The content should be published the same way as it is officially authorised (on paper). So, although I can understand your point at combining some content in a single cell, in this special case it's not allowed. Furthermore, since combining the data in a single cell (or not) would not have any influence on the accessibility of the table, the example I've given is completely valid.

Concerning the third example: of course there are several methods to realise that table. But splitting cells would be the more logic method.

Well anyway, my major concern is that, when splitting a cell is only possible if it has been merged before, things get more and more complicated in case one has to make a complex table.

[Julia]

I'm interesting in following that discussion!