How should tables work?

[matthew-carroll]

Super Editor would like to support tables. What is the state of the art? What do other table implementations do, and what should Super Editor do?

HTML

HTML tables include tags for table rows, table headers, and table data.

The only difference between a table header and table data is semantics and default styling.

Column boundaries are implied by the position of table data <td> tags within a parent table row <tr> tag.

Row 1, Col 1

Row 1, Col 2

<table>
  <tr>
    <td>Row 1, Col 1</td>
    <td>Row 1, Col 2</td>
  </tr>
</table>

A table data can span multiple columns.

Row 1, Col 1	Row 1, Col 2
Span 2 cols

<table>
  <tr>
    <td>Row 1, Col 1</td>
    <td>Row 1, Col 2</td>
  </tr>
  <tr>
    <td colspan="2">Span 2 cols</td>
  </tr>
</table>

A table data can span multiple rows.

Span 2 rows	Row 1, Col 1
	Row 1, Col 2

<table>
  <tr>
    <td rowspan="2">Span 2 rows</td>
    <td>Row 1, Col 1</td>
  </tr>
  <tr>
    <td>Row 1, Col 2</td>
  </tr>
</table>

Notice the table data layout order when spanning rows.

Styling

HTML has <colgroup> so that an entire column can be targeted for styling.

ISBN	Title	Price
3476896	My first HTML	$53

<table>
  <colgroup>
    <col span="2" style="background-color:red">
    <col style="background-color:yellow">
  </colgroup>
  <tr>
    <th>ISBN</th>
    <th>Title</th>
    <th>Price</th>
  </tr>
  <tr>
    <td>3476896</td>
    <td>My first HTML</td>
    <td>$53</td>
  </tr>
</table>

Styles

<table>, <th>, and <td> are all CSS-targets, each of which can receive a border, background, etc. These borders are all box borders, e.g., a border for table surrounds the whole table, it doesn't create internal borders between cells. To achieve inner borders on a table, each cell must be styled appropriately.

Scrolling

HTML can separate table segments with <thead>, <tbody>, and <tfoot>. This allows the body to scroll while the header and footer remain stationary. However, when the table is printed, the full body contents are displayed between the header and footer.

Selection

Double clicking selects the word under the mouse, like a typical document.

Triple clicking selects all the content within a cell, like a single paragraph within a document.

There's no gesture recognition beyond 3 clicks.

Drag selections flow from left-to-right, and then top-to-bottom. I assume the horizontal direction reverses in right-to-left languages. I don't know if it's possible to invert the priority from horizontal to vertical.

The Firefox browser (not Chrome or IE) let's the user select a single column by holding down Ctrl and dragging vertically.

Editing

HTML tables don't have any editing functionality by default, because they're for display purposes only. Any editing would be implemented by webpage developers.

Google Docs

Google Docs support editable tables.

Creation

A user creates a table by selecting a desired grid size (which can be changed later).

A user can also select a pre-defined table template.

Layout

Cells can be merged to span rows and/or columns.

Even when a merged cell cross column boundaries, dragging to resize the column from any cell will change the boundary for the entire column, across the merged cell boundary.

Rows and columns expand to fit their content. Dragging a row boundary up and over a line of text has no impact on the size of the row. The row remains as tall as needed to fit the text. Dragging a column boundary to make it thinner will cause the text to reflow. Once the column gets down to a single character of width, it won't get any thinner.

Each column can have a set width, or an implicit distribution with other implicit-width columns.

Rows can have a minimum height, but not a set height. And the minimum height is overridden by the intrinsic height of the row's content.

Styling

Borders are styled as first-class citizens, rather than properties of cells.

When the user selects one of those border configurations from the dropdown in the screenshot, that selection doesn't alter the borders. Instead, some subset of the border lines within the table are selected. The user can then apply whatever color or thickness is desired for those specific lines.

Desired cells can receive any desired background color.

Selection

Double clicking selects a word.

Triple clicking selects the entire cell. Functionally, it's the same as selecting all cell content, but visually the entire cell is highlighted.

Unlike HTML forms, Google Doc form selection is based on intersections between the drag rectangle the cells. Selection doesn't follow language layout flow.

That said, there are some unpredictable behaviors. For example, if the user drags from cell "two and" down to cell "twelve", the fourth column is selected, despite not intersecting the drag area.

Then, if the user keeps dragging down, into cell "fifteen", the fourth column is deselected.

Also, partial content selection across cells is not possible. The moment a drag selection crosses a cell boundary, the entirety of both cells is selected.

[bk-one]

I would start simple and not add complex table layouts with row or col-spans. Just having a simple table with rows and cols only is sufficient as a first step. Making it more flexible in the future can always be added, but I rather have an MVP shipped and experimented with, than to overly complicate things early on.

Same with allowing customizing borders or even cell colors. As long as you can theme the layout of a table - and identify a table header, it's good enough for a start imho.

[matthew-carroll]

Would you like to provide a specification?

[bk-one]

Sure, can do - but shouldn't we focus on the tasks until 0.3 before? I'm happy to write down specs, just feel it's premature? But if it helps, I can write something up until next week.

[matthew-carroll]

There are definitely other dev priorities ahead of this. My goal here is for us to iron out the requirements so that when we get here, we don't spend cycles hashing out these details that we could have figured out earlier. We can chat more in our next meeting, but I think this is the kind of thing that would help improve the timeline issues that we discussed previously.