- From: Ian Hickson <ian@hixie.ch>
- Date: Sun, 23 Mar 2008 19:29:56 +0000 (UTC)
- Cc: whatwg@whatwg.org, HTML WG <public-html@w3.org>
- Message-ID: <Pine.LNX.4.62.0803090347080.21599@hixie.dreamhostps.com>
Executive summary:
* header/id is in.
* summary="" is not in.
* axis="" is not in.
* the automatic header association algorithm has been expanded.
* a number of minor fixes and editorial edits were made.
For details, see revisions r1373 to r1396.
On Fri, 4 May 2007, aurelien levy wrote:
>
> the problem is not on the use of scope instead of headers/id, it's that
> at this time headers/id have a better support in the assistive
> technology so it's very important to keep them in html 5
On Thu, 17 May 2007, Maciej Stachowiak wrote:
> >
> > 1. headers="" is more widely implemented than scope="",
>
> I think this argument is pretty strong, actually. If someone wanted to
> make table markup that can be understood by screen readers and wished to
> address older screen readers, it seems like headers="" is the option
> that degrades gracefully. This seems like a reason to at least specify
> headers="" as a UA requirement for UAs that associate cells and headers,
> and possibly a reason to make it conforming for documents so that
> authors can write conforming HTML5 without leaving out older screen
> readers. HTML5 goes to some lengths to allow markup that degrades
> gracefully in older browsers, and it seems reasonable to do this for
> screen readers as well.
>
> > 2. headers="" handles some edge cases that scope="" cannot.
> >
> > However, in the case of the second of these points, I do not think
> > that we should necessarily optimise for such rare cases, and in the
> > case of the first, I think it would be more helpful to have input from
> > AT authors to explain *why* scope="" hasn't been implemented as
> > widely. Is it simply that AT implementors haven't gotten there yet? Is
> > the HTML4 definition to vague? Does the HTML5 definition help? Is the
> > feature somehow fundamentally flawed?
>
> I agree that feedback from AT authors would be very valuable. It seems
> that scope="" is much more author-friendly and its support should be
> advocated since it lowers the bar to making accessible markup.
Given the problem of conveying the meaning of tables to users who are not
able to directly see the tables, solutions (such as headers="") have to be
evaluated on the basis of whether or not they address the problem better
than not having the solution at all.
In particular, with headers="", given that implementations of this feature
already exist, the first question is whether user agents that support this
feature can convey the table semantics more usefully on existing tables
that include the feature, or on equivalent tables that omit it -- that
is, whether in practice the feature is a net improvement to the
accessibility of tables or whether it actually makes matters worse.
(Theoretically it would always make matters, better, of course, but in
practice authors' misunderstandings can often make things worse.)
I did a study last July which suggested that roughly 0.2% of pages with
<table> elements used the headers="" attribute, and that rougly 0.08% of
pages used the headers="" attribute in a non-trivial way (i.e. in a way
that could actually improve the accessibility of the page over simply
applying a simple set of heuristics to determine what table headers
applied to what cell). Now clearly this isn't especially useful, since the
whole point is that accessibility tools at the moment _don't_ implement
even the most basic of heuristics to determine table/cell associations,
sadly (let alone the more advanced heuristics discussed later in this
e-mail). However, this study also involved the collection of a sample of
pages that use the headers="" attribute in a correct but non-trivial
manner, from which we can maybe get an idea of whether headers="" does
indeed help or not. This same study also determined through automated
analysis that about 20% of tables that use headers="" have some sort of
fundamental error in the header association, e.g. dangling IDs (the most
common error), duplicate IDs, self-reference or cycles in the header
definitions, IDs that contain spaces (and thus can't be used to make
header associations), and so forth.
Looking at ten pages selected at random from the sample (specifically, I
took a random sample of 100 URIs from the millions that were deemed
interesting by the script, sorted this sample lexically, and then took
every tenth URI, or the closest thereto, skipping URIs that are now 404),
we find the following:
http://w3.bcn.es/ab/asia/agenda/controller/0,2314,1886716_1893804_2,00.html?accio=fitxa_ag&idActe=99400157985
This page has so many deeply nested presentational tables (71, in total)
that it's hardly worth even examining it. What's funny is that the three
headers="" attributes are all on cells that themselves contain tables.
What's surprising is that all three are actually used correctly, though
redundantly, given a simple table heading association algorithm.
Conclusion: headers="" probably neither helps nor harms this page in
existing user agents.
http://doe.state.wy.us/lmi/20042pub/tes/PAG14072.HTM
All of the headers="" in this page could be removed and a single <td>
turned into a <th> with a net increase in the accessibility of the page --
as it stands, one of the cells that would be best considered a header is
not. This page also has nested tables, by the way, in the captions.
Conclusion: headers="" probably neither helps nor harms this page in
existing user agents.
http://trac.feedtree.net/project/ticket/45
The headers="" on this page are redundant with a decent heuristic.
Conclusion: headers="" probably improves matters in today's user agents,
which are pretty simplistic in their processing of tables.
http://www.essen.de/Module/Veranstaltung/v_liste.asp?DatVon=03.07.2006&Dauer=999&ReiheID=28&singleday_Anfang=581&multiday_Anfang=181
http://www.essen.de/module/veranstaltung/v_liste.asp?DatVon=31.12.2006&Dauer=1&VAID=&singleday_Anfang=11
The headers="" on these pages are used correctly and actually improve
matters. This is probably the first site I've seen that has tables that
are understandable visually for which the headers="" actually help
non-visually-able users. (This site is a major source of headers=""
attributes, hence it appearing twice in a sample of ten URIs out of
several million.)
Conclusion: headers="" probably improves matters in today's user agents.
This is also a case where there really isn't another solution that I can
see that would allow the semantics of the table to be expressed.
http://www.plandechoque-ahorrodeagua.es/pag/eus/100_listado.asp?prov=03
These headers="" are all wrong. They don't match the visually apparent
header structure of the table.
Conclusion: headers="" probably hurts the accessibility of this page.
http://www.eu2006.gv.at/de/Media_Service/showFoto.html?month=3&day=1&backpath=%2Fhtdocs%2Ffr%2FMedia_Service%2FPhotos%2FApril%2F0604ECOFIN_Tag1.html&path=%2Fhtdocs%2Fincludes%2Fphotos%2FApril%2F0704ECOFIN%2FkG6406403_thumb
The table here is the calendar on the right. The headers="" here are again
all wrong -- they make the first week all Mondays, the second week all
Tuesdays, and so forth.
Conclusion: headers="" probably hurts the accessibility of this page.
http://www.kurierlubelski.pl/index.php?module=forum&func=viewtopic&topic=3219
The headers="" here seem pointless. They roughly match what heuristics
would generally do anyway, but sadly that's no comfort because the headers
in question really don't help understand the page (the header used for
most of the cells is really a page header, not a table cell header).
Conclusion: headers="" probably neither helps nor harms this page in
existing user agents, though it may marginally harm them due to the user
agents' otherwise simplistic handling of header association.
http://www.ncreportcards.org/src/schDetails.jsp?pSchCode=328&pLEACode=230&pYear=2005-2006
The headers="" here are again rather redundant given any basic heuristics,
except that in addition, the only time they are used, simply not reading
any header labels (and just reading the table straight out loud) would be
the simplest and most useful interpretation of the table. This page
contains a large number of tables (24), mostly presentational.
Conclusion: headers="" probably neither helps nor harms this page in
existing user agents.
http://www2.westfalia.de/shops/werkzeug/handwerkzeuge/messen_ausrichten_markieren/messschieber/1000-streichmass_200mm.htm
Again, a site full of presentational tables, with one data table in the
middle using headers="". This one also has a second table, using
headers="" in a bogus fashion. In both cases, a simple heuristic could do
at least as well, or better, than honouring headers="".
Conclusion: headers="" probably doesn't help this page, and may harm it
due to the incorrect usage.
Summary:
On 3 pages the headers="" feature helps the user.
On 3 pages the headers="" feature neither helps nor hurts the user.
On 2 pages the headers="" feature may harm the user in some minor way.
On 2 pages the headers="" feature harms the user.
This suggests that we should include the feature.
I have added headers="" support to the HTML5 spec.
A second question is whether on the long term, headers="" is the solution
that can best solve the problem of conveying the meaning of tables to
users who are not able to directly see the tables. I think that it is
clear that explicit markup for non-visual users is not something most
authors even remotely consider including on their pages, and thus
headers="" is actually quite a bad way of solving the core problem of
conveying the meaning of tables to users who are not able to directly see
the tables. Our best bet is to hook into the visual interpretation of the
table, using well-defined heuristics. For the cases where more hints need
to be given by the author, the scope="" attribute provides a much cheaper
solution for authors, and we therefore should focus on pushing that rather
than on pushing headers="", when advocating accessible markup.
However, to make tables more accessible by default, we have to study
actual tables and see what would work for them all. Here's a list of some
of the tables I've looked at, derived from the work of Ben, Laura, Steve,
and others who have e-mailed the list or participated in various forums in
the past few months. I actually looked at hundreds of tables; those I've
listed below are merely a sample showing some of the more interesting
features that were used. (Not all can be handled by HTML5's algorithm
without use of headers="", but most now can.)
http://broads-authority.gov.uk/boating/navigating/tide-tables.html
http://www.usability.com.au/resources/tables.cfm
http://www.gutenberg.org/files/17128/17128-h/17128-h.htm
http://www.gutenberg.org/files/19598/19598-h/19598-h.htm
http://www.socialsecurity.gov/policy/docs/statcomps/eedata_sc/2004/table01.html
http://www.dol.govt.nz/publications/general/soi2006/21statfinperf.html
http://www.msd.govt.nz/publications/statement-of-intent/2007/forecast-financial-statements.html
http://www.mfe.govt.nz/publications/about/soi/2007/html/part2/vote-environment.html
http://www.linz.govt.nz/publications/statement%2Dintent%2D0607/financial/financial-statements/financial-performance/index.html
http://elabs.govt.nz/web-standards/table-ids-and-headers.html
http://daf.csulb.edu/offices/financial/procurement/printshop/copying.html
http://www.wisc.edu/about/facts/budget.php
http://joeclark.org/access/cinema/reviews/
http://www.flickr.com/photos/joeclark/192878174/
http://www.flickr.com/photos/joeclark/192878416/
http://www.flickr.com/photos/joeclark/192878366/
http://www.flickr.com/photos/joeclark/185786265/
http://www.flickr.com/photos/joeclark/185786161/
http://www.flickr.com/photos/joeclark/185786065/
http://www.flickr.com/photos/joeclark/185786134/
http://www.flickr.com/photos/joeclark/185786111/
http://annualreport07.telecom.co.nz/governance/remuneration/employees
http://annualreport07.telecom.co.nz/performance/financial-statements/balance-sheet
http://sitesurgeon.co.uk/tables/astro/06-seasons/minimal.html
http://harmonia.terrainformatica.com/map.html
http://www.premierleague.com/page/LeagueTable/
http://www.federalreserve.gov/generalinfo/basel2/docs2005/potentialimpact.htm
I also looked in detail at the information that Ben and James provided,
which was incredibly useful.
Based on all the above, I have updated the algorithms in the spec to
handle a greater number of tables automatically.
This addresses ISSUE-20.
[ISSUE-20] http://www.w3.org/html/wg/tracker/issues/20
On Tue, 13 Mar 2007, Simon Pieters wrote:
>
> Many pages use tables where only the first column are header cells,
> e.g.:
>
> <table>
> <tr><th>Foo <td>Bar
> <tr><th>Foo <td>Bar
> <tr><th>Foo <td>Bar
> </table>
>
> With the current algorithm for assigning header cells to data cells, the
> first <th> won't be a header cell for any data cells. In order to be
> more compatible with existing content, and in order to not require
> authors to use more complex markup for such a simple table like the one
> above, I think it probably should be.
On Tue, 13 Mar 2007, Asbjørn Ulsberg wrote:
>
> Can't 'scope="row"' be used?
On Tue, 13 Mar 2007, Simon Pieters wrote:
>
> I see that as a workaround. The current algorithm works fine if you flip
> the table so that the header cells are on the first row; I think it
> should just work for the above case as well.
On Tue, 13 Mar 2007, Kornel Lesinski wrote:
>
> It can, but in this case scope of row is so obvious, that it would be
> counter-intuitive if specification said otherwise.
On Thu, 22 Mar 2007, Henri Sivonen wrote:
>
> When the options are badgering innumerable authors into doing something
> and making relatively few users agents implement slightly smarter
> heuristics, the latter should win.
On Sun, 27 Jan 2008, Ben Boyle wrote:
>
> Assume I am authoring a table and want it to be fully accessible. This
> table has both row and column headings... as an example, imagine it's a
> TV guide and the columns represent hours in the day and the rows
> represent various channels (the data being what's on).
>
> It's the top left cell that bugs me.
>
> If it contains "Time" then it should be a <th scope="row">
>
> If it contains "Channel" then it should be a <th scope="col">
>
> How can this be unambiguous (to a UA) without @scope?
On Sun, 27 Jan 2008, Ben 'Cerbera' Millard wrote:
>
> Without scope, I think [the top-left cell] should apply downwards. From
> the tables I've seen, a header in that position is always labelling the
> row headers below it. But I haven't seen every table which exists. :-)
>
> If an author wants to apply it across that row, I think scope="row" is a
> sensible way to make that happen.
The heuristics have been updated to handle this case. (In fact it handles
both the horizontal headers case and the vertical headers case.)
Basically, it just labels all data cells in both directions, to the right
and downwards, until it hits another header cell. (In HTML5, header cells
aren't hierarchical. As I mentioned above I studied a large number of
tables and I couldn't really find a case where there was a real need to
read the headers' own headers. (In the rare cases where such verbosity is
indeed desired, the headers="" attribute can be used to point to all the
headers.)
> Ben Boyle wrote:
> > Often this cell is blank in tables (which is easy, I just use
> > <td></td>... even within <thead>) [...]
>
> That's what I do, too. An empty <th> would also work there. Real tables
> use either, IIRC.
Per the current spec, you'd have to use <td> if it wasn't a real header.
> Sometimes a cell contains insignificant content, such as or <br>.
> These should be [ignored]. Among other things, this would avoid
> functionally empty top-left header cells being associated with data
> cells. Thus supporting real tables accessibly.
I've mentioned this in the spec.
On Mon, 4 Jun 2007, Thomas Broyer wrote:
>
> 2007/6/4, Leif Halvard Silli:
> >
> > And does anyone know what happens if I put SCOPE on a TH within the
> > THEAD element. And then add SCOPE to the correpsonding TH in same
> > column in the TFOOT element, in HTML5 (or in HTML4)? A cell in this
> > column would then be scoped from top and from bottom. In the code, it
> > would come after the SCOPE in the THEAD.
>
> HTML5 defines scope= in terms of "slots". If you put <tfoot> before
> <tbody> in the <table>, then all your data cells will be associated with
> header cells in both <thead> and <tfoot>. On the other hand, if you put
> <tfoot> after <tbody>s, then you data cells will be associated with
> header cells only in <thead>, and header cells in <tfoot> won't be
> column headers of any data cells.
>
> At least that's how I read the algorithms with the "Processing model"
> section
> http://www.whatwg.org/specs/web-apps/current-work/multipage/section-tabular.html#processing
I've fixed this to make the <tfoot>s always go to the bottom.
On Wed, 30 May 2007, Adam Roben wrote:
>
> The omission of a createTBody method from HTMLTableElement makes it
> rather inconvenient to create a table with both a thead and a tbody
> using the table DOM APIs. After creating a thead, you have to manually
> create and append the tbody to start putting rows into the body of the
> table, so you cannot exclusively use the HTMLTableElement methods to
> populate the table. If a createTBody method is added, I'd suggest that
> it always create a new tbody rather than ever returning an existing one.
Added.
On Thu, 16 Aug 2007, Ben Boyle wrote:
>
> Look at the balance sheet (3rd table). It's like we have nested sections
> within the table. There's "net assets" that's broken down into "current
> assets", "non-current assets" and "liabilities", each either their own
> heading and totals (footer).
>
> It would be interesting to investigate table markup that could support
> complex relationships within tables like this. It may be a bit esoteric,
> and can probably be handled through classes for those that need it. In
> either case it's very important we can clearly associate the headers
> with the right cells. I think it would be useful to be able to identity
> the "totals" (footers?) in each section too.
For simple cases like:
WATER FOOD
CATS
male 871 12
female 900 10
TOTALS FOR CATS 1771 22
DOGS
male 871 12
female 900 10
TOTALS FOR DOGS 1771 22
TOTALS 3542 44
...you can now easily get this effect by putting everything in the left
hand column into <th>s, everything on the top row into <th>s, and
everything on the bottom row into its own <tfoot>.
Does that work?
> I'm going to through a crazy idea into the mix and suggest that
> <section>, <header> and <footer> may be useful within data tables for
> this very purpose.
I'm not clear on how that would work. (Especially considering backwards
compatibility and the CSS table model.)
On Tue, 22 Jan 2008, Ben 'Cerbera' Millard wrote:
>
> James Graham wrote:
> > I'm just wondering if, in your research into HTML tables, you have ever come
> > across a table that would require the use of scope=rowgroup/colgroup
> > assuming [...] something like the smart[ ]colspan
>
> I don't recall any which used it and needed it.
>
> However, there are largely regular tables which have the odd quirk inside
> them. If authors were to retrofit accessibility to these, scope might help
> disambiguate.
>
> A quick look through my collection turned up some smart colspan worries:
>
> 1. <http://harmonia.terrainformatica.com/map.html>
> [[[
> This might prevent the “smart colspan” algorithm working.
> ]]]
> Specifically, the "measure, parser, render, scanner, style, tableengine"
> cell.
So long as everything in columns 2 and 3 is a <th>, it should work fine.
(In this particular table there's no header cells, but that's another
problem.)
> 2. <http://sports.espn.go.com/nhl/boxscore?gameId=270519002>
> [[[
> 1st Period Summary:
> * Columns 3 and 4 start with individual headers but are replaced by a
> spanned header. “Smart colspan” wouldn’t recognise this because it would fail
> in other tables, IIRC.
> 2nd Period Summary, 3rd Period Summary and OT Summary are the same as 1st
> Period Summary.
> ]]]
> Specifically, the "PENALTY DETAIL" header cell in each table.
>
> The data cells below this would get that header applied to them, but smart
> colspan would also apply the "SCORING DETAIL" and "SCORE" headers? I'm not
> sure how to solve this case.
Yeah, this one I don't have a solution for. Even scope="" an row groups
can't help with this one.
On Sun, 27 Jan 2008, James Graham wrote:
>
> FWIW the HTML 4 behavior which turns a <td scope="somthing"> into a
> heading from the point of view of the UA is, in principle, useful since
> there are cases (particularly for row headings) where one cell is
> effectively both data and a heading but the formatting should be
> data-like rather than heading like. However I strongly doubt this is
> actually used enough in practice to make it worthwhile; [1] shows very
> few pages using it and a random selection of those I checked seemed to
> be using it unnecessarily or incorrectly. In any case, it is only a
> convenience, one could argue that a purer approach is to mark up
> anything that a UA should regard as a heading as <th> and then change
> the style as required.
That's what I've settled for in HTML5 for now.
> On the subject of which, does anyone have a strong opinion on how
> scope="colgroup" and scope="rowgroup" ought to work? For example, in the
> following table, assuming the header is scope="rowgroup", the direction
> is ltr, and there is only one rowgroup, which cells should it apply to:
>
> | Cell 1 | Cell 2 | Cell 3 |
> | Cell 4 | Header 1 | Cell 5 |
> | Cell 6 | Cell 7 | Cell 8 |
Spec says 5, 7, 8, assuming none have headers="" attributes set.
> What about cases where the scope is colgroup and the header trails into
> parts of multiple colgroups
>
> | colgroup 1 | colgroup 2 |
> | Cell 1 | Cell 2 | Heading 1 | Cell 4 | Cell 5 |
> | Cell 6 | Cell 7 | Cell 8 | Cell 9 | Cell 10| Cell 11|
>
> These seem kindof like unimportant edge cases to me, but it seems like
> these scope values are only going to be useful in uncommon situations,
> so I guess someone might have a use case for one behavior over
> another...
Spec says 8.
On Mon, 28 Jan 2008, James Graham wrote:
>
> @headers is supported. The attribute's value is split on whitespace and
> each resulting token is used as an id for getElementById on the subtree
> rooted at the <table> element. If a match is found that header is
> associated with the cell. If no match is found the token is ignored. If
> any headings are found from @headers, no other header associations are
> applied to that cell (I believe this is necessary for the few legitimate
> @headers use cases)
That's basically what the spec now does, except only cells inside the
table itself will be used, not those in nested tables.
On Tue, 19 Jul 2005, Christoph Päper wrote:
>
> both table models, HTML and CSS, are row-centric, i.e. sequential data
> is shown horizontally. Sometimes the opposite is desired. Therefore I
> wonder if it was feasible to add a "boolean" 'transpose' attribute to
> the 'table' element type? With it set, a table would be rendered
> column-progressive despite 'tr' meaning "table row"; it includes the
> row-groups ('thead', 'tfoot' and 'tbody'). Actually I am not sure
> whether it is not too presentational and thus would better be done in
> CSS.
This is an interesting idea... I'm certainly not opposed to it, my concern
is that browser vendors are unlikely to implement it (especially since it
isn't compatible with the CSS model). I'd recommend trying to get a
browser vendor to implement it experimentally; with a proof of concept it
would be much easier for us to argue for its inclusion in the spec.
On Thu, 26 Oct 2006, David Walbert wrote:
>
> It strikes me that the axis and headers attributes could both
> potentially be very useful; but if I were to use them, I'd almost
> certainly generate the table and attributes with server-side script
> (such as PHP), and then there would be no need for the HTML attributes
> since I could generate any desired reports the same way. They seem to me
> to provide alternative functionality for tables in lieu of an actual
> database, but if the tables aren't generated from a database they'd have
> to be marked up by hand, and that would be a tremendous amount of work
> in which errors could easily be introduced. That may explain why the
> attributes are underused.
On Sat, 28 Oct 2006, Lachlan Hunt wrote:
>
> I suspect that the problem with the axis attribute is that it's not
> entirely clear from the HTML 4 spec how or when to use it, and, AFAIK,
> there are no known useful implementations that use it.
On Thu, 26 Oct 2006, Sander Tekelenburg wrote:
>
> I can't follow this. AFAIK axis[*], headers and scope are all intended
> to improve accessibility and useability of tabular data; they allow
> authors to help user-agents help users to navigate tables. For example,
> a speech browser could provide a mechanism to speak the table headers
> that apply to a cell; a visual browser could render the table header for
> a cell when that table header cell is outside of the viewport (that way
> we wouldn't even need scrolling TBODYs anymore), draw lines to the
> corresponsing table cell headers of a selected cell, or maybe even
> hide/grey-out all non-related (header) cells; Etc.
>
> [*] I have to admit I don't understand axis. The HTML 4.01 description
> of it is way beyond rocket science to me. So thus far I've only used
> headers and scope.
On Thu, 26 Oct 2006, Sander Tekelenburg wrote:
>
> I suspect [axis/headers] not being used is more likely due to UAs not
> supporting them. (As well as this being one of those non-visual features
> of the Web... Just not Flashy enough for most Web publishers ;))
I haven't added axis, mostly because nobody seems to understand it, so it
would likely not be used well even if supported.
On Fri, 27 Oct 2006, Lachlan Hunt wrote:
>
> All of these attributes should be kept, because they are supported and
> non-presentational.
>
> TABLE
> * summary (supported by screen readers)
>
> TH and TD
> * abbr (I think that's supported by screen readers, but need to verify)
I don't really see that these attributes actually help anyone.
On Tue, 13 Feb 2007, David Latapie wrote:
>
> Do you know some guidelines on this (<table summary="">)? I usually
> write the number of rows and columns, sometimes with an adjective like
> "long", "complex", because this is what I think come to my eye first.
That, or the most common "This is a layout table" (or words to that
effect) seem rather pointless to me.
If the problem is that the table is especially complicated and needs a
summary to be understood, why disenfranchise the sighted users by only
showing the summary to disabled users? It seems like the table would be
better served by a paragraph before or after the table explaining it for
everyone.
A single attribute is hardly going to be expressive enough to usefully
describe tables to users.
On Tue, 5 Feb 2008, Joshue O Connor wrote:
> >
> > Well, as noted above, I haven't yet done much research on summary="",
> > it's waiting with all the other table issues. However, with all due
> > respect, one of the most convincing pieces of research I have seen
> > examining summary="" -- and most excellent research it was -- was your
> > own usability study video, which showed a screen reader user dismiss
> > summary="" out of hand as being useless and annoying (paraphrasing
> > from memory).
>
> I knew that my colleague's comment would come back to haunt me :-)
Please don't consider this as it haunting you -- we often come across
unexpected truths when doing research, that's why we do it.
> To put that comment into context, he is a power user and is experienced
> in using his screen reader controls to interrogate data tables.
I would imagine that this would put him amongst those more able to deal
with summary="" attributes, so that doesn't really help your case. :-)
> As an aside, when the camera was off and I explained to him how @summary
> could be useful to other users Stuart agreed with me.
He agreed with you on camera, too. But that doesn't stop his initial,
unbiased reaction being one of dismissal. :-)
> I can always put together more footage to build a more solid case :-)
That's not how research works. :-)
This addresses ISSUE-32. It proobably doesn't address it to everyone's
satisfaction, so if this issue is to be reopened, please start a new
thread and describe in detail what problem we are trying to solve (without
mentioning summary="" in the e-mail, so as not to bias the problem
description with an assumed solution). The e-mails above don't really
describe what the problem being solved is, so I can't really evaluate the
merits of the solution being proposed.
[ISSUE-32] http://www.w3.org/html/wg/tracker/issues/32
On Fri, 27 Oct 2006, Michel Fortin wrote:
>
> Le 27 oct. 2006 à 9:17, Lachlan Hunt a écrit :
>
> > I'd say drop all of these because they're either presentational or not
> > supported.
> >
> > * align
>
> I don't agree. Yes it is presentational, but data tables can look pretty
> crappy if you remove their alignement information. Delegating alignment
> to CSS will just make tables harder to read without the corresponding
> stylesheet to align the data as intended. That's not just style, it's
> also a usability issue. So I think align="" should be preserved for
> table cells, rows and columns.
On Sat, 28 Oct 2006, Anne van Kesteren wrote:
>
> It's known that styling and good design improves usability. That doesn't
> make "align" any less presentational.
On Sat, 28 Oct 2006, Michel Fortin wrote:
>
> align="" is presentational; I didn't say the contrary. And all styling
> has an influence on usability, I'm not contesting that. But some style
> information is more tied to the content than other, and some style
> information should be known even when CSS is not available because *not
> having that information* makes the document less readable.
>
> Sometime, presentational information is needed to display a document
> correctly, and in those few cases where the presentation is tied to the
> content, I think it belongs in the markup. The align attribute, when
> used on table cells, covers one of those cases.
On Sat, 28 Oct 2006, Anne van Kesteren wrote:
>
> I still disagree. It only seems a benefit for visual documents and even
> there the user agent could optimize display when CSS is not supported or
> turned off by running some specific algorithm.
On Thu, 9 Nov 2006, fantasai wrote:
>
> I think that is a stronger argument for keeping char than align.
>
> Another argument for align is that CSS alone can't do anything useful
> about alignment in columns, since inheritance only works through the
> element tree. Of course, I'd prefer to see that fixed in CSS.
On Wed, 21 Mar 2007, Nicholas Shanks wrote:
>
> Alternatively it could just be allowed on the <col> and <colspan>, where
> it would affect <td> cells (but not <th> cells). Just a random thought.
I haven't added align and char, but if CSS support for text-align:
<string> becomes widespread, I'd be happy to add char="" back to the spec,
as it is indeed quite appropriate. I also agree that having it as a
shorthand on columns, applying only to <td>s, would make sense.
On Thu, 9 Nov 2006, fantasai wrote:
>
> The HTML 4 spec says to use TD for a cell that functions both as data
> cell and an header cell. [1] For these cases, it would be necessary to
> allow scope on TDs.
On Fri, 27 Oct 2006, Simon Pieters wrote:
>
> In HTML4, as I understand it, TDs can act as both data cells and header cells
> if they have scope="" or have headers="" pointing at them.
HTML5 does away with the concept of a hybrid cell, at least for now.
On Tue, 1 May 2007, Roger Johansson wrote:
>
> While reading the HTML 5 Working Draft I noticed that two attributes
> that can be used to increase the accessibility of data tables in HTML 4
> have been removed. The attributes are the table element's "summary"
> attribute and the td element's "headers" attribute.
>
> What is the rationale for removing those attributes?
>
> I have discussed this with a couple of Web accessibility experts who
> were surprised by it, since both attributes can be very useful. Has
> accessibility been considered before removing the attributes? What is
> needed to bring them back in?
They weren't removed, they just hadn't been added. (HTML5 starts from a
clean slate, only things that can be justified are added.)
headers="" has now been justified and has been added.
It isn't clear that summary="" actually helps anything. (Indeed, it seems
to be almost -- but not quite -- as bad as longdesc="" in terms of being
widely used in a useless way that doesn't actually help users.)
On Mon, 16 Jul 2007, Debi Orton wrote:
>
> GENERAL COMMENTS: I suggest that there needs to be more explanation of
> the use of each of the elements within the table model, including simple
> examples.
I've added a placeholder for an introduction to tables, which will be
filled in in due course.
> I also suggest for each of the elements within the table model that
> there be an explicit indication of whether these elements require a
> closing tag, as the HTML 4.01 specification indicated that several
> (e.g., thead, tfoot, tbody) did NOT require a closing tag.
This is an issue for more than just the table elements. Right now there's
an explicit section on it. In practice it's a lot more complicated than
just "the tag is optional":
http://www.whatwg.org/specs/web-apps/current-work/#optional
For example, for <tbody> the rule is:
A tbody element's start tag may be omitted if the first thing inside
the tbody element is a tr element, and if the element is not
immediately preceded by a tbody, thead, or tfoot element whose end tag
has been omitted.
It's not clear exactly how to say that in the element definitions.
This will be reexamined in due course.
> I am also disappointed that attributes particularly useful to the users
> of screen reading software are not included, specifically the id
> attribute of the th element and the headers attribute of the td element.
These are now included.
On Fri, 27 Oct 2006, Lachlan Hunt wrote:
>
> Ian Hickson wrote:
> > I think it would be good to require table integrity. Specifically I think
> > overlapping cells would be a MUST NOT.
>
> That's fine for document conformance, but what about how browsers will
> handle it? Is the spec still going to require browsers to render
> overlapping cells, or would it be possible to resolve this difference
> between HTML and XHTML rendering, as documented in CSS 2.1 [1]?
Both.
> Do you have any statistics on the number of sites that depend on
> overlapping cells in HTML? Could that rendering be removed from
> standards mode (but left in quirks mode) without breaking a significant
> number of pages?
I have not collected that information.
> I think the spec should define an algorithm to unambiguously determine
> which rows and columns a cell fits into. If browsers can calculate
> that, there are 2 benefits I can think of.
We have that now.
On Fri, 27 Oct 2006, Rohan Prabhu wrote:
>
> even i think that overlapping cells should not be supported, as it would
> be an encouragement to table based layouts. The specifications not
> supporting overlapping cells would encourage developers to use table for
> tabular data only.
I don't think that there is any evidence to support overlapping cells
being a source of encouragement for table-based layouts.
On Sat, 4 Nov 2006, Henri Sivonen wrote:
>
> None of Opera 9.02, Firefox 2.0, IE7 and Safari 2.0.4 implement
> colspan="0" as specified in HTML 4.01. Trident, Presto and WebKit at
> least agree on what to do with it: they treat it like colspan="1".
>
> I suggest that only positive integers be conforming and that
> non-conforming values be treated as 1.
>
> Test case:
> http://hsivonen.iki.fi/test/wa10/tables/colspan-0.html
So specified.
On Sun, 5 Nov 2006, Matthew Paul Thomas wrote:
>
> I know browser vendors have had a long time to implement this, but
> still, I think giving up on it would be a shame. The number of rows or
> columns in a table is often rather expensive to calculate ahead of time.
> As long as this has to be done to calculate the rowspan= or colspan= of
> header cells, this can substantially increase the time an application
> takes to generate a table. For the browser to interpret colspan="0" or
> rowspan="0" instead would both make life easier for application authors,
> and make such pages faster overall.
rowspan=0 is supported; colspan=0 is not, as it is somewhat harder to
implement. (Consider what exactly you would want changed in the algorithm
right now to support it.)
On Wed, 22 Nov 2006, Henri Sivonen wrote:
>
> "Cell can either be data cells or header cells."
>
> Incongruent singular and plural.
Fixed.
> "Not every row is necessarily in a row group."
>
> What terminology is suggested for consecutive rows that are not in a row
> group? (I have tentatively used "implicit row group".)
"Rows".
> "Not every column is necessarily in a column group."
>
> Noting that in HTML 4.01 terminology, in the absence of explicit column
> groups, there is a single implicit column group.
The only effect here is that scope=colgroup doesn't work in HTML5 without
a <colgroup>. Bug? Feature?
> "A cell cannot covers slots that are from two or more row groups or two
> or more column groups"
>
> I agree about row groups, but Firefox 2.0, Opera 9.02, Safari 2.0.4 and
> IE7 allow cells to span over column group boundaries interoperably.
> http://hsivonen.iki.fi/test/wa10/tables/colspan-over-colgroups.html
Fixed.
> The algorithm for establishing explicit columns and column groups does
> not cover the (non-conforming) case of <col> elements as children of
> <table> (via XHTML or DOM manipulation). From the behavior of Firefox
> 2.0, Opera 9.02 and Safari 2.0.4, I suggest that consecutive <col>s as
> children of <table> for an implicit row group. (And I don't see why that
> couldn't even be conforming.)
Compatibility with IE, which implies <colgroup>s, resulted in the current
spec. Desire to not have the same problem <tbody> has been causing is what
made it non-conforming in XHTML.
> Step 14. "Otherwise, run the algorithm for ending a row group." implies
> that there are implicit row groups. :-)
Don't read between the lines!
> In step 17., how could y_max >= y_start not hold?
I think I fixed that.
> It seems to me that the "algorithm for ending a row group" extends the
> cells in the "list of downward-growing cells" from y_current to y_max.
> This seems wrong. Browsers clip cells whose rowspan is still pending
> when a row group ends. It follows that the y_max established in one row
> group should be reset when a new row group starts.
The spec follows Safari at the moment. It seems to make sense to honour
the rowspans.
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Ctable%20border%3E%0D%0A%3Ctr%3E%3Ctd%20rowspan%3D1%3EX%3Ctd%20rowspan%3D2%3EY%3Cbr%3EY%3Ctd%20rowspan%3D3%3EZ%3Cbr%3EZ%3Cbr%3EZ%3Cbr%3EZ%0D%0A%3Ctbody%3E%0D%0A%3Ctr%3E%3Ctd%3Ezzz
> The steps dealing with parsing colspan and rowspan do not dictate the
> algorithm like the steps for parsing span or col and colgroup do.
Oops, a typo prevented the cross-referencer from working.
> Personally, I found it easier to handle cells with rowspan='0' by
> setting them to span until row infinite (that is the max value of int)
> as opposed to having a separate flag. For each cell, I keep track of the
> start column, start row, the column until which the cell spans and the
> row until which the cell spans. I put all cells whose rowspan != 1 in a
> set that I call cells in effect. When a row ends, I remove all cells
> that no longer span onto the next row from the set. When a row group
> (which can be implicit) ends, it is an error to have cells in the set
> whose spans-until-row is not infinite. When a new row starts, I sort the
> set of cells in effect by the start column so that the sorted list can
> easily be searched for the next free slot by examining each cell in
> effect at most once per row. Note that keeping track of the extent of
> each cell in effect makes it unnecessary to keep track of overall y_max.
> (My algorithm works without actually instantiating a data structure for
> the slot grid, so memory requirements are relative to the number of
> cells in effect and to the number of elements that have caused columns
> to be established and not to the number of slots in the table.)
That's a fine implementation of the algorithm in the spec.
> I notice that, unlike discussed previously, the table model does not
> make it an error if a column or row does not have any cells starting on
> it.
This is now an error.
> Also, having x_max grow over what was established by explicit
> columns is not an error. Nor are ragged tables in any way shunned
> (except when there are empty explicit columns).
Should these be made errors?
On Sun, 15 Jul 2007, Simon Pieters wrote:
>
> Shouldn't the <col> element be allowed as child of the <table> element for the
> same reason <tr> is (i.e., for compat with XHTML 1.0 and for ease of authoring
> in the XML or DOM case)?
(replied as part of the previous e-mail)
On Tue, 19 Jun 2007, Lachlan Hunt wrote:
> Ian Hickson wrote:
> > On Sat, 24 Feb 2007, Keryx Web wrote:
> > > - A table within a table cell (Has this ever been used for anything
> > > but layout?)
> >
> > There are valid uses of that, though they are rare.
>
> Really? What are they?
Consider a table for a roleplaying game where the table is giving
information about various locations. One of the columns could be "local
monsters" and the cell describing local monsters would quite plausibly
itself contain tables with the stats of the various monsters at that
location.
On Tue, 29 Aug 2006, Henri Sivonen wrote:
>
> Should one expect HTML table row/column integrity to become an HTML5
> conformance requirement?
>
> That is, will these tables be non-conforming:
>
> <table>
> <tr><td rowspan="2"></td></tr>
> </table>
>
> <table>
> <tr><td></td></tr>
> <tr><td></td><td></td></tr>
> </table>
>
> ?
>
> (This is something static document authors probably would prefer to have
> flagged, and for dynamic document authors it isn't a particularly good
> idea to leave the DOM in an incoherent state for prolonged times.)
The first of those is a table model error. The second is not. Is that ok?
On Fri, 27 Oct 2006, Lachlan Hunt wrote:
> >
> > I think cells extending (via colspan/rowspan) into columns or rows that
> > contain no cells other than extended cells should be at least a SHOULD NOT,
> > maybe a MUST NOT.
>
> I don't think it should be a must not. Here's a use case for where it's
> useful to span cells across multiple columns like that.
>
> Consider a online TV guide where columns represent the time and rows represent
> the channel. The headers for the times could be split into half hour time
> slots, because most shows take up units of half an hours. However, there are
> some programs that only take 5 or 10 minutes (e.g. lottery draws or short news
> breaks) and to allocate such programs a full half hour slot in the table
> wouldn't be very useful. Consider this markup demonstrating this:
>
> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0A%3Chtml%3E%0A%3Chead%3E%0A%3Cmeta%20http-equiv%3D%22Content-Type%22%20content%3D%22text/html%3B%20charset%3Dutf-8%22%3E%0A%3Ctitle%3ETable%20Cells%3C/title%3E%0A%3Cstyle%3E%0A%09col%20%7B%20width%3A%205em%3B%20%7D%0A%09table%2C%20td%2C%20th%20%7B%20border%3A%201px%20solid%20black%3B%20border-collapse%3A%20collapse%3B%20%7D%0A%3C/style%3E%0A%3C/head%3E%0A%3Cbody%3E%0A%0A%3Ctable%3E%0A%09%3Ccol%3E%0A%09%3Ccol%3E%0A%09%3Ccol%3E%0A%09%3Ccol%3E%0A%09%3Ccol%3E%0A%09%3Ccol%3E%0A%09%3Ccol%3E%0A%09%3Ccol%3E%0A%09%3Ccol%3E%0A%09%3Ccol%3E%0A%09%3Ccol%3E%0A%09%3Ccol%3E%0A%3Cthead%3E%0A%09%3Ctr%3E%0A%09%09%3Cth%3E%3C/th%3E%0A%09%09%3Cth%20colspan%3D%226%22%3E20%3A00%3C/th%3E%0A%09%09%3Cth%20colspan%3D%226%22%3E20%3A30%3C/th%3E%0A%09%3C/tr%3E%0A%3C/thead%3E%0A%3Ctbody%3E%0A%09%3Ctr%3E%0A%09%09%3Cth%20scope%3D%22row%22%3EChannel%201%3C/th%3E%0A%09%09%3Ctd%20colspan%3D%225%22%3E20%3A00%20-%2025%20minute%20program%3C/td%3E%0A%09%09%3Ctd%20colspan%3D%221%22%3E20%3A25%20-%205%20minute%20program%3C/td%3E%0A%09%09%3Ctd%20colspan%3D%226%22%3E20%3A30%20-%2030%20minute%20program%3C/td%3E%0A%09%3C/tr%3E%0A%09%3Ctr%3E%0A%09%09%3Cth%20scope%3D%22row%22%3EChannel%202%3C/th%3E%0A%09%09%3Ctd%20colspan%3D%226%22%3E20%3A00%20-%2030%20minute%20program%3C/td%3E%0A%09%09%3Ctd%20colspan%3D%226%22%3E20%3A30%20-%2030%20minute%20program%3C/td%3E%0A%09%3C/tr%3E%0A%09%3Ctr%3E%0A%09%09%3Cth%20scope%3D%22row%22%3EChannel%203%3C/th%3E%0A%09%09%3Ctd%20colspan%3D%2210%22%3E20%3A00%20-%2050%20minute%20program%3C/td%3E%0A%09%09%3Ctd%20colspan%3D%222%22%3E20%3A50%20-%2010%20minute%20program%3C/td%3E%0A%09%3C/tr%3E%0A%3C/tbody%3E%0A%3C/table%3E%0A%0A%3C/body%3E%0A%3C/html%3E%0A
The horrible lack of interop on this table is a bit worrying.
(I also think this table would be really confusing to a screen reader.)
I'm not sure about this case. Is it really a table?
> > headers="" will have a MUST requirement to point to TH elements in the
> > same table, and will probably only be allowed on TDs.
>
> Maybe. What about in tables where one th is like a subheading of the
> one above?
What about them?
> > scope="" will probably only be allowed for THs. Maybe it should be
> > REQUIRED for THs that aren't in obvious locations (first row, first
> > column, or whatever).
>
> Maybe. I think the spec should explicitly define how to determine which
> header cells are associated with each cell. IIRC, the HTML 4 spec does
> define an algorithm like that, so maybe it could be improved.
Done.
On Thu, 9 Nov 2006, Henri Sivonen wrote:
>
> Made it an error. Also made it an error to have rows that exceed the
> width established by column markup.
This is not an error in the spec. Should it be? (It would mean
distinguishing tables that have no column markup from columns that have
any column markup, and requiring the latter to cover all columns. That
seems overly strict.)
> Specifically, the errors are:
> [...]
> * Table cell spans past the end of its row group.
> * Row has no cells starting on it.
Isn't the first of these a subset of the second?
> * Table row column count is greater than the column count established by
> cols/colgroups.
> * Table row column count is less than the column count established by
> cols/colgroups.
These aren't errors per the spec at the moment.
> The warnings are:
> * A col element causes a span attribute to be ignored on the parent colgroup.
This is an error, per spec. (Content model error.)
On Tue, 14 Nov 2006, Simon Pieters wrote:
>
> Currently <tbody> requires at least one <tr> element. [1] Why not zero
> or more? I think <tr> is for <tbody> like <li> is for <ul>/<ol> (or a
> <dt><dd> group is for <dl>).
Because if you have zero <tr> elements, you actually have zero <tbody>
elements, which is allowed.
On Tue, 14 Nov 2006, Simon Pieters wrote:
>
> <th> allows either inline-level content or block-level elements. [1] I
> know that HTML4 allows block-level elements too, but I suspect that
> might have to do with convenience when writing the DTD, actually.
>
> <h1> and <dt> don't allow block-level elements. What's the use-case for
> having block-level elements in <th> that doesn't apply to <h1> or <dt>
> as well?
Changed.
On Thu, 5 Apr 2007, Simon Pieters wrote:
>
> Why does <tbody> require one or more <tr> elements, as opposed to zero
> or more?
Fixed.
On Thu, 5 Apr 2007, Simon Pieters wrote:
>
> Also... since tables are allowed to have <tr>s as direct children of <table>,
> if <tbody> is allowed to be empty then presumably <table> should be allowed to
> contain no <tbody> and no <tr> elements.
It is.
On Sun, 15 Jul 2007, Simon Pieters wrote:
>
> The spec says about HTMLTableColElement.span:
>
> The span DOM attribute must reflect the content attribute of the same
> name, with the exception that on setting, if the new value is 0, then an
> INDEX_SIZE_ERR exception must be raised.
>
> Shouldn't this say:
>
> The span DOM attribute must reflect the content attribute of the same
> name, limited to only positive non-zero numbers.
>
> ...? (In which case, it doesn't need a default value, either, two paragraphs
> above that one.)
>
> This applies to these two sections:
>
> http://www.whatwg.org/specs/web-apps/current-work/#colgroup
> http://www.whatwg.org/specs/web-apps/current-work/#col
Fixed.
On Mon, 16 Jul 2007, Debi Orton wrote:
>
> 3.15.1 The table Element
>
> Suggested text in response to "we need some editorial text on how layout
> tables are bad practice and non-conforming":
>
> The only semantic use for a table is to collect similar information and
> define each data item's relationship to other data items within the
> collection. To use a table for layout is not a semantically appropriate
> use, and will be considered non-conforming.
The problem is that that is basically redundant with the rest of the
spec... I'm not sure how to do this really.
> I suggest moving the discussion of the table model to the top of this
> section to provide more context for subsequent discussions.
I'd rather introduce the elements before defining how they work together.
Eventually we'll have an intro section that mentions the table model,
though, so it won't be totally out of the blue.
> I'm also not sure why the DOM definitions of each of the table-related
> elements is written up here. I didn't see any of the other sections
> treated this way.
I don't understand.
On Mon, 16 Jul 2007, Debi Orton wrote:
>
> 3.15.2 The caption Element
>
> "The caption element represents the title of the table that is its
> parent, if it has a parent and that is a table element."
>
> What other legitimate usage is there for the caption element? I know of
> none, although this verbiage makes it appear as if there are others.
> Can we simplify it?
There are no other legitimate uses. However, a <caption> in a <p> doesn't
represent the caption of the table that is its parent, since it doesn't
have a parent table. Saying "The caption element represents the title of
the table that is its parent" begs the question when the parent is not a
table.
On Mon, 16 Jul 2007, Debi Orton wrote:
>
> 3.15.3 The colgroup Element
>
> Same confusing verbiage regarding the colgroup element as in the caption
> element. Suggest eliminating everything after "that is its parent."
Same reason.
> The section talks about the syntax of the colgroup element, but gives no
> indication of its intended usage. I think an example or two would be
> helpful here, unless we are planning to lift the examples from the HTML
> 4.01 spec.
>
> Another reference to the "table model", which has not yet been
> introduced.
Will be solved by the intro section in due course.
On Mon, 16 Jul 2007, Debi Orton wrote:
>
> 3.15.4 The col Element
>
> I wonder if the span attribute needs more explanation in this context –
> again, we can probably recycle something from HTML 4.01.
Tutorial-type explanation will be in the intro section.
On Mon, 16 Jul 2007, Debi Orton wrote:
>
> 3.15.5 The tbody Element
>
> Same general comments as the other sections.
>
> Regarding:
>
> "The rows attribute must return an HTMLCollection rooted at the
> element, whose filter matches only tr elements that are children of the
> element."
>
> Is "rows" a new attribute or is this a typo for rowspan?
DOM attribute.
On Mon, 16 Jul 2007, Debi Orton wrote:
>
> 3.15.6 The thead Element
>
> NOTE: Since both thead and tfoot must precede tbody (at least in the HTML
> 4.01 spec), shouldn't that same order be reflected here? If you are making
> the order more intuitive (i.e., thead à tbody à tfoot), that will need to be
> explained explicitly.
On Mon, 16 Jul 2007, Debi Orton wrote:
>
> 3.15.7 The tfoot Element
>
> Same general comments…
>
> "As a child of a table element, after any caption, colgroup, thead,
> tbody, and tr elements, but only if there are no other tfoot elements
> that are children of the table element."
>
> This entry makes it appear as if you are intending that the sequence of
> elements within the table model is intended to be different from that of
> HTML 4.01. Again, if that's the case, it will require further
> explanation.
Whatever the order, it has to be explained. :-) It will be mentioned in
the intro section, probably.
On Tue, 17 Jul 2007, Robert Burns wrote:
>
> I'm not sure if this is what Debi was referring to, but I find the
> phrase "but only if there are no other tfoot elements that are children
> of the table element.' that is often used to be needlessly wordy and
> awkward. Would the same meaning be conveyed by saying that "one tfoot
> may be the child of a table element after any caption, colgroup, and
> thead elements and either: 1) before any tbody and tr elements or 2)
> after all of the tbody elements too"
I'm not sure that's really much better. It also seems to misuse RFC2119
terminology.
On Mon, 16 Jul 2007, Debi Orton wrote:
>
> 3.15.8 The tr Element
>
> "The rowIndex element must, if the element has a parent table element,
> or a parent tbody, thead, or tfoot element and a grandparent table
> element, return the index of the tr element in that table element's rows
> collection. If there is no such table element, then the attribute must
> return 0."
>
> I am not familiar with "the rowIndex element." Is this something new,
> and if so, why is the "I" capitalized?
>
> I am not familiar with the cells attribute. What is it and how is it
> used?
On Mon, 16 Jul 2007, Simon Pieters wrote:
>
> It is a typo. Should say "the rowIndex attribute". This is a DOM
> attribute.
Fixed.
On Mon, 16 Jul 2007, Debi Orton wrote:
>
> 3.15.10 The th Element
>
> I would like to see the id attribute restored to the th element.
The id attribute has always applied to all elements.
> I understand the four named states for the scope attribute , but the
> definition provided for the auto scope attribute is confusing. Can it
> be stated more clearly?
Which part is confusing?
On Wed, 18 Jul 2007, Simon Pieters wrote:
>
> Shouldn't the HTMLTableCellElement.colSpan and rowSpan attributes be
> unsigned long instead of long in the IDL?
"long" is what DOM2 said.
> Also, shouldn't the colSpan be "limited to only positive non-zero
> numbers" in the reflecting paragraph?
Done.
> Also, the attributes are spelled in all lowercase in the reflecting
> paragraphs.
Fixed.
On Mon, 20 Aug 2007, James Graham wrote:
>
> 3.15.11.1. Forming a table
>
> Step 4 reads:
>
> "If the table element has no table children, then return the table
> (which will be empty), and abort these steps."
>
> It's not clear what is meant by "table children" as opposed to other
> kinds of children here.
That term is gone now.
> Somewhere around step 18. the current element needs to be advanced to
> the next child of the table. I'm not sure if I'm missing something
> obvious but I can't see where this occurs in the current algorithm.
Fixed.
> In the algorithm for processing a row it is not stated which algorithm
> should be used to parse colspan and rowspan attributes (I assume it is
> the algorithm for parsing non-negative integers).
Fixed.
> Data in the <caption> and <colgroup> elements only seem to be included
> if the elements are correctly placed in the table. It seems more robust
> to define the UA requirements so that the information in these elements
> (especially caption) is included whether it appears before or after the
> row grouping elements.
Fixed.
On Wed, 22 Aug 2007, Mihai Sucan wrote:
>
> 1. "Big Issue: we need some editorial text on how layout tables are bad
> practice and non-conforming"
>
> Here's my try:
>
> "Due to historic reasons, tables are being used by Web authors for
> designing layouts. However, this is considered bad practice and it's
> strongly discouraged. As a conformance criteria, layout tables are
> disallowed. Web authors must only use tables for tabular data."
>
> I think this has to be short and to the point - no dramatic depiction of
> the layout tables abuse.
Something like that might work, though we probably need more
RFC2119-compatible language. I'll figure something out in due course.
> 2. "The caption DOM attribute must return, on getting, the first caption
> element child of the table element. On setting, if the new value is a
> caption element, the first caption element child of the table element,
> if any, must be removed, and the new value must be inserted as the first
> node of the table element. If the new value is not a caption element,
> then a HIERARCHY_REQUEST_ERR DOM exception must be raised instead."
>
> The spec does not define the returned value for the caption DOM
> attribute when there's no caption element child in the table element.
>
> 3. Similarly to the above:
>
> "The tHead DOM attribute must return, on getting, the first thead
> element child of the table element."
>
> The same goes for the tFoot DOM attribute.
Fixed.
> 4. Looking at the definition of the tr element [2] one can see some
> errors:
>
> "The rowIndex *element* must, if the element has a parent table element,
> or a parent tbody, thead, or tfoot element and a grandparent table
> element, return the index of the tr element in that table element's rows
> collection. If there is no such table element, then the attribute must
> return 0.
>
> The *rowIndex* DOM attribute must, if the element has a parent table,
> tbody, thead, or tfoot element, return the index of the tr element in
> the parent element's rows collection (for tables, that's the rows
> collection; for table sections, that's the rows collection). If there is
> no such parent element, then the attribute must return 0."
>
> Corrections:
>
> element = DOM attribute
> rowIndex = sectionRowIndex
Fixed.
> 5. In the 3.15.11.1. "Forming a table" section [3] there's an editorial
> "error" when defining the processing for colgroups:
>
> "Column groups. Process the current element according to the appropriate one
> of the following two cases:"
Fixed.
On Wed, 22 Aug 2007, Boris Zbarsky wrote:
>
> Mihai Sucan wrote:
> > The *rowIndex* DOM attribute must, if the element has a parent table, tbody,
> > thead, or tfoot element, return the index of the tr element in the parent
> > element's rows collection (for tables, that's the rows collection; for table
> > sections, that's the rows collection).
>
> This is a little confusing... The DOM2 HTML definition is:
>
> This is in logical order and not in document order. The rowIndex does take
> into account sections (THEAD, TFOOT, or TBODY) within the table, placing
> THEAD rows first in the index, followed by TBODY rows, followed by TFOOT
> rows.
>
> In other words, rowIndex is the index in the table's .rows. That's not what
> your text above says.
I'm not sure I understand the problem. The <table>.rows attribute defines
this in detail.
> > If there is no such parent element, then the attribute must return 0."
>
> Are we sure? That makes it impossible to tell that case apart from the case
> when this is in fact the first row. Would -1 make more sense?
On Wed, 22 Aug 2007, Mihai Sucan wrote:
> >
> > Are we sure? That makes it impossible to tell that case apart from the case
> > when this is in fact the first row. Would -1 make more sense?
>
> Yes, that's somewhat confusing. Returning -1 would be better.
Change to -1. There's no compat issue here, the browsers are wildly
non-interoperable on this issue.
On Tue, 1 Jan 2008, Darin Adler wrote:
>
> The DOM Level 2 document
> <http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-13114938> says that
> deleteRow(-1) deletes the last row.
>
> The current HTML 5 draft
> <http://www.whatwg.org/specs/web-apps/current-work/#deleterow> does not
> mention -1 for deleteRow, only for insertRow.
Fixed.
On Fri, 8 Feb 2008, James Graham wrote:
>
> In step 9.1 of the table model processing algorithm, first case under
>
> "Column groups. Process the current element according to the appropriate
> one of the following two cases: If the current element has any col
> element children"
>
> Step 9.1.7 sets the final width of the colgroup is given as
> x_max-x_start-1. I think this should be x_max-x_start+1.
>
> Rationale:
>
> Define the initial value of x_max to be x_max_0. According to step 9.1.1
> x_start is x_max_0 + 1
>
> In step 9.1.4 x_max is increased by the current col's span and this step is
> run once per col child of the colgroup, so if there is a total width w of
> columns in this colgroup, x_max -> x_max_0 + w
>
> So at step 9.1.7 we have:
> x_start = x_max_0 + 1
> x_max = x_max_0 + w => x_max_0 = x_max - w
> x_start = x_max - w + 1
> w = x_max - x_start + 1
This all changed recently. I can't work out what it became. Can you check
this again and see if I fixed it?
I snipped a big discussion comparing <dl> to <table>, because, well, I
couldn't see what I was supposed to do about it.
There were also some other e-mails that seemed to ramble on about the same
points already made more succintly in the e-mails above that I snipped.
Let me know if I accidentally missed anything in the trimming.
Cheers,
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Sunday, 23 March 2008 19:30:50 UTC