odd... for 12/12/2005 and Budgeted
16:14:26 GZ: table which might be used by investment company - small table that demonstrates point of why headers necessary - for each datum, screen reader user needs to know values (has actual headers) - "running cost" is a pure header, but "partner portal" is not a TH, but should be a TD; all data need to be marked up as TD, but need @headers associations for assistive tech to work with such a simple table
16:14:34 but what about budgeted, actual, etc - they can't be THs/
16:14:41 and they're even styled to look like headers, despite using in the markup
16:14:51 @DanC why odd?
16:14:51 so they should just use TH
16:14:57 lachy, style is irrelevant - separate content from presentatio
16:14:59 Regarding the idea of nested headers: The headers attribute can reference a th, so if the tds are changed to ths, the relationship would be complete. But that isn't allowed in the editor's draft, as nested headers aren't allowed. It also creates a new problem of what is the automatic scope association of a th in the middle of a table. Does it apply to the row (to the left?, to the right?, both directions?), does it apply to the column (above? below? both
16:15:04 s/presentatio/presentation
16:15:11 DC: look like headers
16:15:25 CW: running dates headers, but not budgeted, actual, etc.
16:15:27 oedipus, I know. But the fact that, to a sited user, they're made to look as if they are headers, then it means the author is trying to convey that they are headers
16:15:39 They could have been styled on thead, but that's just how our client styled it
16:15:40 s/sited/sighted/
16:15:49 lachy, not really - they are just "important" to the author
16:16:00 These relationships need semantic hooks that AT can use.. hence the suggestion.
16:16:03 MS: table header cell is exact language
16:16:17 MS: not defined in much detail beyond that
16:16:29 CW: could argue that anything that should be considered a header should be a TH?
16:16:41 yes
16:16:41 CW: forecasted in example would then be TH
16:16:48 DC: that would be my first guess
16:17:15 tds will act as virtual headers - as such - if their ids can be referenced by headers.
16:17:32 By *true* headers, as such.
16:17:39 ed has joined #html-wg
16:17:41 GZ: if had more data in table, total cost of ownership etc. in extreme right column; if ended up with budgeted anual forcast as TH, would look like that is header for rest of row, which isn't correct; nested headers don't make such sent
16:18:10 q+ to ask about solution of restructuring the data into a different table
16:18:17 CW: additional content to the right of running cost - essentially making running cost a nested table containing running cost over time, but can't carry table alignment across multiple partner portals
16:18:25 At the very least this example shows a deficiency in the current spec that needs to be addressed,
16:18:27 (while in this case, "Budgeted" looks like a | to me, it seems like there's an established state-of-the-art that uses | , and it works, and I don't see much reason to stop them.)
16:18:46 GZ: yes - if sighted easy, if using AT have to drill into table - massive disadvantage
16:19:05 yes.
16:19:14 q?
16:19:16 q+ to suggest that one assessment of this particular table might be that it's simply poorly designed, regardless of what class of user needs to use it
16:19:19 yes, but we're not in person, so don't see a better way
16:19:22 ack MikeSmith
16:19:22 MikeSmith, you wanted to ask about solution of restructuring the data into a different table and to suggest that one assessment of this particular table might be that it's simply
16:19:25 ... poorly designed, regardless of what class of user needs to use it
16:19:30 Gez: Most of the examples of complex data tables that require headers/id associations have not been built by hand. They're usually built server-side, after analysts select the data they want to report on, and generating the relationships is easy for the software. When composite data is included, headers are usually required, as the composite data has a finite range that might not run for the remaining column/row. This can sometimes be overcome (if there a
16:19:57 Quering and interogating data tables is a complex task for many users of AT.
16:20:02 q+
16:20:11 q+
16:20:17 MS: part of discussion and solutions that have been advanced for some cases - don't know if this table falls into that case - there are certain tables that are fundamentally badly designed - not fixing poor design by adding features for AT software - better solution is to redesign table
16:20:18 q+
16:20:19 q+ to wonder about "poorly designed" vs established norms
16:20:56 MS: do wonder about case of fixing via markup versus fixing data into more appropriate form; nested rowspans can be presented in other ways that don't rely on rowspans
16:20:59 DC: true
16:21:00 "It may be true that it is possible to restructure many complex data tables by adding rowgroup or colgroup elements to the table and by altering the spans of cells in such a way that the scope attribute can specify the header cells for all data cells. I am not convinced but it is true for some of the "classic" examples. That process is complicated and cumbersome. It basically requires rewriting the table. Compare that with the headers/id approach. ANY Tab
16:21:02 http://lists.w3.org/Archives/Public/public-html/2007Jun/0103.html
16:21:11 s DC/CW
16:21:14 MS: not helping by enabling bad design
16:21:18 q?
16:21:38 CW: suggesting re-design table model to take into account compound data scenarios
16:21:41 MS: right
16:22:09 @MS: The mark up should facilitate how authors *will* mark up tables, though I agree that tables are often very badly designed.
16:22:26 Gez, do you have an URL for an unmodified "complexdatatable" example available? (with the additional rows and such to the right of the "running cost")
16:22:37 CW: not sure if suggesting way solving problem in example - can understand why this set of data would be presented in this manner - is a compound data scenario - not representible today, so authors have to use hack; are you saying authors shouldn't do this or improve the table algorithm
16:22:58 Note that headers/id association are rather well supported by much current AT so Gez's solution is rather simple and elegant.
16:22:59 MS: case-by-case stuff comes up and have to decide if real solution is restructuring the data
16:23:10 q?
16:23:13 ack Stevef
16:23:17 MS: don't know if would be right solution for majority of cases, but been discussed on list
16:23:53 Will authors change the way that they mark up tables that much as we transition to HTML 5? Probably not.
16:23:59 q-
16:24:06 (Steve is making the point I was queued to make)
16:24:22 SF: understand MS' argument, but this table is an example of a table that came from a custormer - generated by database into multiple formats, all quite complex - shouldn't be in business of telling people how to order data, rather than providing binding so data can be presented in accordance with author's wishes/client's needs
16:24:36 SF: cannot markup tables in this way" proscription will be ignored
16:24:58 +1 Steve and Dan.
16:24:59 q?
16:25:09 ack Gez
16:25:17 Real world cases will define how the language should behave to a degree..
16:25:18 SF: need to provide way to mark up so is accessible - people are doing this, and that isn't going to change
16:26:13 ack oedipus
16:26:15 | | |