Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tables are broken! #38

Open
dubinsky opened this issue Jun 19, 2020 · 0 comments
Open

Tables are broken! #38

dubinsky opened this issue Jun 19, 2020 · 0 comments

Comments

@dubinsky
Copy link
Contributor

dubinsky commented Jun 19, 2020

Acceptance Criteria

First, what does it mean for tables to work (in my opinion).

  1. Boundaries between the cells are aligned across the rows (cell borders form vertical lines - column borders).
  2. Column widths depend on the content of the cells (e.g., column with document numbers will be narrower than the column with document descriptions in the same table).
  3. TEI cols attribute, if present on a cell, is handled properly.

Recent Change

Until recently, table behavior was used to translate TEI tables into HTML tables and cols attribute on TEI cells into colspan attribute on the td elements. As a result, all three criteria above were satisfied.

Recently (e62c329), table behavior was removed as "horrible and hacky". I am not sure if the code was considered "horrible" (I do not see it as more horrible than the note or list behaviors) or the resulting DOM (which seems no more difficult to use than that produced by the ptr or list behaviors), but it is not my aesthetics that was offended :)

Now that tables are left untranslated as nested tei-table, tei-row and tei-cell elements, all the "tables work" criteria above are broken; it seems to be implied that the breakage can be fixed by styling the tables with CSS.

CSS Grid

Judging from the commit comment and the addition of display: grid to the CSS rule for tei-row, CSS Grid is the recommended way to style the tables. Since table cells are nested within the rows, CSS Grid, which is designed to "gridify" a bunch of non-nested elements, can not be used to style the table as a whole. (Not sure if CSS Subgrid would help with that, but it is not yet supported by the browsers in any case.) As a result, table rows have to be styled as independent grids.

To force boundaries of the cells belonging to the same column (that CSS Grid knows nothing about) into alignment (criterion 1), all rows of the same table have to be styled exactly the same. Indeed, that is what sample CETEIcean.css does, allotting 1fr (one fraction) to each cell in a row.

Unfortunately, this breaks criterion 2 above: resulting column widths are completely oblivious to the cell content. To regain reasonable table widths - which previous approach delivered automatically - each table now has to be styled manually by the user of CETEIcean (talk about horrible and hacky!), and even then, responsiveness of the table to overall resizing - which previously was handled by the in-browser algorithm refined over a few decades - is now lost.

Criterion 3 above is also broken: nothing looks at the cols attribute; I suspect that desired result is not expressible with CSS Grid in principle, but even if it is - there is enough functionality regression to invalidate the CSS Grid approach.

display: table*

There is an alternative approach: set CSS display attribute on tei-table to table, on tei-row to table-row, and on tei-cell to table-cell. This brings back automatic compliance with criteria 1 and 2 above.

Unfortunately, browsers ignore colspan attribute unless it is set on a td element, so even if conversion of TEI cols to HTML colspan was added, criterion 3 above would still be broken.

table behavior

It seems that the only way to regain functionality previously provided by the table behavior is to bring the table behavior back :(

Of course, I can maintain my own copy in every project that uses CETEicean, but is forcing all your users to do that or face their tables stop working a reasonable price to pay for a little less horrible and hacky code? :)

endnote duplication

If you do bring table behavior back, please look into the endnote duplication issue that it causes:
an endnote residing in a table cell is appended to the endnote container twice. (I suspect that endnote behavior (and all others, whose results are not visible) is applied to such endnotes twice:
once as a part of the same "apply behaviors" run that triggered the table behavior, and once again when behaviors are applied to the results of the table behavior.)

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant