You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First, what does it mean for tables to work (in my opinion).
Boundaries between the cells are aligned across the rows (cell borders form vertical lines - column borders).
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).
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!
The text was updated successfully, but these errors were encountered:
Acceptance Criteria
First, what does it mean for tables to work (in my opinion).
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 andcols
attribute on TEI cells intocolspan
attribute on thetd
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 thenote
orlist
behaviors) or the resulting DOM (which seems no more difficult to use than that produced by theptr
orlist
behaviors), but it is not my aesthetics that was offended :)Now that tables are left untranslated as nested
tei-table
,tei-row
andtei-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 fortei-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, allotting1fr
(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 ontei-table
totable
, ontei-row
totable-row
, and ontei-cell
totable-cell
. This brings back automatic compliance with criteria 1 and 2 above.Unfortunately, browsers ignore
colspan
attribute unless it is set on atd
element, so even if conversion of TEIcols
to HTMLcolspan
was added, criterion 3 above would still be broken.table
behaviorIt seems that the only way to regain functionality previously provided by the
table
behavior is to bring thetable
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 thetable
behavior.)Thanks!
The text was updated successfully, but these errors were encountered: