- From: Robert J Burns <rob@robburns.com>
- Date: Sat, 28 Feb 2009 16:47:25 -0500
- To: Leif Halvard Silli <lhs@malform.no>
- Cc: Steven Faulkner <faulkner.steve@gmail.com>, HTMLWG <public-html@w3.org>, W3C WAI-XTECH <wai-xtech@w3.org>, Janina Sajka <janina@rednote.net>, Sam Ruby <rubys@intertwingly.net>, Gez Lemon <gez.lemon@gmail.com>
Hi Leif, On Feb 28, 2009, at 12:10 PM, Leif Halvard Silli wrote: > Steven Faulkner 2009-02-27 13.18: >> Hi all, >> I have taken up Sam Rubys suggestion: >> "As for me, what I would most like to see in the next draft is a RFC >> 2119 compatible definition for table summaries, either in terms of a >> HTML 4 compatible attribute or in terms of a suitable replacement. >> Note that I am specifically saying "in a draft". What I am *not* >> looking for is a reply to this email on how such a topic might be >> approached." [1] >> and taken a stab at a RFC 2119 compatible definition for table >> summaries: >> http://esw.w3.org/topic/HTML/SummaryForTABLE/SummarySpecification >> If you have positive contributions to make to this definition please >> add comments to the wiki page in the notes section > > What I am missing in that text is a focus on authors. I've certainly tried to address authors in the text I wrote (actually some minor changes to Steve's original text; mine is not version B and his version A). I do feel more should be said and as Steve acknowledged any version requires some easy to follow examples. > We need to challenge authors: > > * to choose EITHER caption OR summary OR both. > * if they use identical captions. > * if the summary looks like caption > * if they seems to have written "this a layout table" info I agree with this for the most part. However, I think there is something to be said for a summary that looks like a caption. That is if an author considers a caption somewhat desirable, but in the end decides to omit it, those are cases where the caption should probably be included in the summary. For many simple tables it is very obvious what the purpose of the table is for the visual user. It is very easy to see the homogeneity of dates down a column and the homogeneity of text in another column. For the non-visual user, such table consumption requires a careful listen to every cell. So where an author considers a caption but decides to omit it, I think we should advise such authors to place the caption in the summary attribute instead of omitting it entirely. Certainly we should prohibit redundant summaries and captions (which I think the draft does) and also prohibit "layout table" summaries (which I think we have also done). > In short, authors needs help juxtaposing the two things. In general, > what one could do for this are: > > * somehow linking summary to caption; > * ways to let author see both simultaneously; I think displaying this and other values more obviously in the chrome is an important step. Also encouraging general purpose rendering engines and browsers to also offer authoring modes where a different authoring default stylesheet makes alternate content visible would also be helpful. > * ways to discover tables with caption but not summary; > * ways to discover tables with summary but not caption; I'm not clear what you mean by these two items. Could you explain this further? > I will try to offer a RFC 2119 compatible text that seeks accomodate > for this. I welcome wiki style changes to the version B I drafted[1]. Such edits should: 1) stick to the general thrust of a summary attribute and a caption element; 2) and any substantive changes should be added to the "Issues for discussion" section[2]. If, like Leif, anyone wants to add a different mechanism to address these use cases, then please add another version (currently both version A and version B involve a 'caption' element and a 'summary' attribute). Take care, Rob [1]: <http://esw.w3.org/topic/HTML/SummaryForTABLE/SummarySpecification#head-f7ae874dfb50ef6dfa17e222128fd04365ab691c > [2]: <http://esw.w3.org/topic/HTML/SummaryForTABLE/SummarySpecification#head-e24f017b97cef6950cb2f1a528e4c9a9ff5962c2 >
Received on Saturday, 28 February 2009 21:48:19 UTC