Re: Teatment of <th> inside HDITA documents

Leif Halvard Silli <[email protected]> Sat, 17 Aug 2024 22:34:42 +0200
Newsgroups gmane.editors.xxe.general
Message-ID <[email protected]>
On 08.08.2024 16:36, Hussein Shafie:

> I'm sorry but I don't understand any of this.
>
> «most HTML5 elements are faithfully translated to their DITA 
> equivalent», yes, hence HTML <td> and <th> are both translated to a 
> DITA <entry>.

According to my interpretation, <th> does not have an exact DITA (or 
CALS) equivalent. CALS uses a different method for for conveying that a 
cell is a header cell.

In the DITA table, a table header is an <entry> that occurs inside a 
table header row. Whereas in HTML, a table header is simply a <th> 
element, regardless of where it occurs - inside or outside a table 
header row.

So for instance following HTML table semantics,

——TH TH
TH TD TD
TH TD TD

would get converted/reduced to these DITA table semantics:

——TH TH
TD TD TD
TD TD TD

Except that it turns out that this is not completely true: if the CALS 
table is outfitted with the @rowheader attribute, then it is possible to 
convey that the first column is a rowheader column, see below.

> (DITA has simplified CALS tables, 
> http://docs.oasis-open.org/dita/dita/v1.3/errata02/os/complete/part2-tech-content/langRef/base/table.html, 
> and also <simpletable>s, 
> http://docs.oasis-open.org/dita/dita/v1.3/errata02/os/complete/part2-tech-content/langRef/base/simpletable.html.)

At first, I thought that the problem I describe, is due to a limitation 
of the simplified CALS tables of DITA. However, after I read the CALS 
table document you pointed to above, I changed my opinon.

Please see Figure 2 in the section called «Example: Complex table with 
implied accessibility markup». And below that example, they have 
inserted a HTML output (look for 'Table 1') - where they have converted 
the first column of the CALS table to column with <th> elements.

The way that CALS 'communicate' that the cells of that column are header 
cells, is different from the way HTML communicates the same thing. It 
involves applying the @rowheader attribute to the <table> element, with 
the enumerated keyword 'firstcol'. Thus <table rowheader="firstcol">. 
(Hence, in CALS tables, it seems like it is only the first column that 
can be a header column.)

The @rowheader attribute is more fully described in DOCBOOK 5: 
https://tdg.docbook.org/tdg/5.0/cals.table

By contrast, in HTML, we use the <th> element - which allow us to have 
header cells not only in the first column, but in any column. But the 
support for first column rowheaders of cours covers the majority of HTML 
tables.

Thus, to me, this means that when a table in a HDITA document gets 
converted to a CALS table, it must take care to at least convert the 
first column to rowheader column, whenever the HTML table requires that.

> I've attached sample Lightweight DITA "sample.ditamap" referencing 
> sample HDITA "table.xhtml", itself containing a non-trivial table.
>
> When I convert "sample.ditamap" to PDF or to an HTML page, everything 
> looks just fine to me.

I disagree. Because: In the HTML table, all the cells with **bold** text 
are table header cells.  In the HTML table, <th> cells occurs both 
inside <thead> <tbody> and <tfoot> (as well as inside <tbody>). The 
<tfoot> and the <thead> are equivalents - the only difference being that 
<tfoot> occurs at the foot of the table. Hence, the <th> of <tfoot> and 
<thead> ought to be translated to DITA construct with the same semantic 
meaning. The DITA conversion takes care of this by simply deleting the 
<tfoot>.

But by contrast, the third column, which in HTML is a column of <th> 
cells, when it is converted to DITA, it has suddenly been reduced (or, 
in fact, one could say "upgraded") to data cells - which they are not 
(provided the HTML table uses correct semantics).

Unfortunately, this problems seems unsolvable, on the semantic level, as 
long CALS, inside <tbody>, does not support header cells any other place 
than in the first column. (But it would still be possible to fake or 
hack support by adding <strong> or <b> around the content of the 
"unsupported" header cells.)

Yes, the DITA output looks just fine, but it is also true that the DITA 
table is a flattened version of the HTML table – it has lost some of the 
semantics of the HTML table.

> May be you have found an issue with the way a DITA (simplified CALS) 
> <table> is converted to HTML, but this issue, if any, would not be 
> related to the HDITA support in our Lightweight DITA implementation.

Well, what I proposed was that you do a hack, by converting this

——TH TH
TH TD TD
TH TD TD

to this

————————  TH TH
<b>TD</b> TD TD
<b>TD</b> TD TD

This clearly something that the DITA converter could be made to do. 
Allthough, I must admit that it is a hack.

The good news is that, as long as the header cells occurs in the first 
column, the hack is not necessary. You can instead just make sure that 
the DITA converter adds <table rowheader="firstcol"> whenever the first 
column of the HTML table contains <th> elements.

Hope this made sense.


Leif Halvard Silli


--
XMLmind XML Editor Support List
[email protected]
http://www.xmlmind.com/mailman/listinfo/xmleditor-support