Multiple TH's in a table row with multiple TD's (scope)

[Percept]

Hi,

I've got to create a template for a (to be generated) table and I'm wondering how to make it semantically correct.
I have 4 cols but 2 of the cols contain TH's with the related TD right next to it (the numbers indicate what TD is related to what TD).

I currently added scope="row" to each TH but since I have 2 TH's in each row I'm not sure if this is correct. Normally I would split the table in 2 separate tables but the program generating the table can't do that.

TH (1)	TD (1)	TH (2)	TD (2)
TH (3)	TD (3)	TH (4)	TD (4)
TH (5)	TD (5)	TH (6)	TD (6)
TH (7)	TD (7)	TH (8)	TD (8)
TH (9)	TD (9)	TH (10)	TD (10)

[ralph.m]

Is it feasible to make it just two columns, with the TDs all down the left side?

[Percept]

Is it feasible to make it just two columns, with the TDs all down the left side?

Nope, must be this layout.

[xhtmlcoder]

Possibly you'd add both: headers and id attributes http://www.w3.org/TR/html401/struct/...l#adef-headers but it would be a pain in the neck doing that.

[Stevie D]

Possibly you'd add both: headers and id attributes http://www.w3.org/TR/html401/struct/...l#adef-headers but it would be a pain in the neck doing that.

That is certainly the 'correct' way to go about it ... my only question is, is there any UA out there that actually uses headers and id? I'm not aware of one myself, and regardless of how technically correct it is, it seems a bit of a waste of time putting all that detail into the code if it's just going to be ignored.

@Percept - could you add in a new third column of blank cells to highlight the separation between the left and right halves?

[xhtmlcoder]

Supposedly all the mainstream browsers support the headers attribute and I'd suspect so do some of the major Screen readers e.g. JAWS (Job Access With Speech), etc. as it would be theoretically easier for the AT to deal with than the scope attribute. Though as you know in real-life testing actual levels of "support" can vary.

[Percept]

From reading the specs, my setup is actually correct ...

headers = idrefs [CS]This attribute specifies the list of header cells that provide header information for the current data cell. The value of this attribute is a space-separated list of cell names; those cells must be named by setting their id attribute. Authors generally use the headers attribute to help non-visual user agents render header information about data cells (e.g., header information is spoken prior to the cell data), but the attribute may also be used in conjunction with style sheets. See also the scope attribute.scope = scope-name [CI]This attribute specifies the set of data cells for which the current header cell provides header information. This attribute may be used in place of the headers attribute, particularly for simple tables. When specified, this attribute must have one of the following values:

• row: The current cell provides header information for the rest of the row that contains it (see also the section on table directionality).
• col: The current cell provides header information for the rest of the column that contains it.
• rowgroup: The header cell provides header information for the rest of the row group that contains it.
• colgroup: The header cell provides header information for the rest of the column group that contains it.

So I interpret 'rest' as 'everything after that'

So TH (1) is for TD (1) ... the parser find a new TH and the REST after TH (2) is only TD (2).

[Stevie D]

From reading the specs, my setup is actually correct ...



So I interpret 'rest' as 'everything after that'

So TH (1) is for TD (1) ... the parser find a new TH and the REST after TH (2) is only TD (2).

Not sure I agree with that ... I would say "the rest" is "everything apart from that one", not "everything after that one". I have used tables where I have had two rows of headings at the top, and it wouldn't make sense for the first <th> in each column to apply to nothing, which is the way your interpretation would work. It's for precisely this kind of more complicated situation that the ids/headers attributes were introduced.

[xhtmlcoder]

I'd side with Stevie here; you'd be better with the headers and id, since there are only 5 rows and I'd consider it a 'complex table' since there is no current indicator; TH (1) has anything directly to do with the TD (2) cell contents. Plus I'd suspect they'd also be additional structure to the table to explain the columns themselves, etc.

[zcorpan]

The algorithm in HTML will correctly associate all your cells correctly, with no attributes necessary.

http://www.whatwg.org/specs/web-apps...cell-semantics

The algorithm is quite complex because tables can be quite complex and it tries to do the best thing rather than the simplest thing, so I don't recommend reading the algorithm if you just want to know how to write table markup. Its target audience is implementors.

There once existed a table inspector at http://james.html5.org/tables/table_inspector.html but it no longer exists. I've asked James if he still has it around. It was useful for testing table markup and see how the spec associates the cells.

That said, I don't know how well ATs implement table cell association or what they make of your table without assistance with headers="", but I would be surprised if they didn't associate all your cells correctly. It's a simple table, really. So my recommendation for this table is to use no attributes.

[Stomme poes]

My recommendation is to do two tables of two rows each, and just place them side by side for the graphics weenies.

table1
TH,TD
TH, TD
TH, TD
TH, TD

table2
TH,TD
TH, TD
TH, TD
TH, TD

set them next to each other.

You would not need attributes for tables like this but I always use them (scope, headers *very* rarely but they seem to have decent support) because there's always some AT who is in a phase where they only do the right thing, or something sorta almost close to the right thing, when there are attributes.
I even use summary attributes if I feel it's necessary. With summary I state in a single sentence what a sighted viewer could quickly gather about the table information structure in a glance, which can be helpful for retardedly large tables like a shopping cart. See, I'm such a rebel. Summary has been obsoleted.

The algorithm in HTML will correctly associate all your cells correctly, with no attributes necessary.

http://www.whatwg.org/specs/web-apps...cell-semantics

According to that link, zero browsers have bothered implementing this.


The same AT can and do react differently to the same table in different browsers, so AT is very reliant on how the browser sees and reports the table. That and ATs still have lots of table bugs :/

Anyone curious about specifically screen readers and tables, Detlev Fischer has made a lot of tests in various browsers with various attributes: http://www.3needs.org/en/testing/sr-html.html

[zcorpan]

According to that link, zero browsers have bothered implementing this.

Well, the annotations aren't really being maintained. But it's not unlikely that the spec's td-th mapping hasn't been implemented anywhere yet.

[dresden_phoenix]

I was going to suggest the same as Stomme (even tho I am a graphics person, thank you)


I mean just cant figure out , semantically, what kind of tabular data has a TH running down the middle of it. There are multiple row of TH inside a THEAD, but still its all contained in one unit. If you had a row of THs then 7 rows of data and then a TH followed by more rows of data people would have seen this as actually begin two sets of tabular data, even if your you had a first column which was all THs. This seems like the same issue but with the axes reversed.

The question one has to ask is how does TH1 actually apply/relate to TD2?

[Stomme poes]

(even tho I am a graphics person, thank you)

be proud! You are indeed officially not in my "grafix weenies" list, despite the handicap of being a graphicker. :P