- From: Murray Maloney <murray@muzmo.com>
- Date: Fri, 07 Aug 2009 21:39:06 -0500
- To: Leif Halvard Silli <lhs@malform.no>
- Cc: Steven Faulkner <faulkner.steve@gmail.com>, Henri Sivonen <hsivonen@iki.fi>,HTML WG <public-html@w3.org>, W3C WAI-XTECH <wai-xtech@w3.org>
At 02:15 AM 8/8/2009 +0200, Leif Halvard Silli wrote: >>agreed, but I do not consider that the title attribute would ahve been >>then or is now an appropriate container for summary information of this >>kind as i consider it would be annoying to many people if the summary >>information was displayed whenever a user moved their mouse over the table That was one reason that we abandoned @title. Many of us also wanted to ensure that @title could be relied on to be a global attribute, with exactly the same meaning and purpose on every element. SCO and SoftQuad each had software-specific features which counted on title containing a pre-processed simple ASCII string representing the title of the object upon which it was found, for building cross references and TOCs, etc. Other organizations also counted on the @title in similar ways because of their existing production practices, using DocBook and other document types. >HTML 4.01's Appendix A, section "A.3 Changes between HTML 3.2 and HTML >4.0 (18 December 1997)") [1] links @summary to the issue of "long >descriptions": > >[...] >Does this hint that <table longdesc="URI"> was considered as an option? >Or, opposite, what about @summary for images - instead of @longdesc? Yes, we did discuss having a longdesc and a shortdesc on every table, image and object. We could not establish such a simple rule because @alt was already an exception. Dave Raggett didn't like '@shortdesc'; he preferred '@summary'. It simply appeared. >Answer: Probably table@summary was thought to have a much more limited >role than longdesc pages could have, namely, the rather brief task of >describing the table structure. (A longdesc image description could itself >contain a table ...) @shortdesc was thought to be a simple ASCII string containing a short description (i.e. <1k) @longdesc could be a reference to a full HTML document, an audio presentation of the material, etc. >The choice of @summary instead of @longdesc also points out that the >summary is intended to be read quickly - just before reading the table. >Whereas image descriptions are an extra option - when @alt isn't enough. >(Of course, @summary also becomes an option - or something extra - if the >UA doesn't support it ...) That would be a reasonable inference, I suppose. Or perhaps Dave just transliterated between 'short description' and 'summary' using a mental thesaurus. >[...] >So, might it be that table@summary was meant to be presented to AT users >/before/ the entire table had been rendered? If so, then this might also >explain why some @summary texts perhaps are more wordy than we today >consider kosher: In such a scenario it would perhaps not matter if the >summary repeated bits of what the user later would read inside a caption. >(For instance, perhaps the user would use the @summary info to simply skip >reading/loading the table?) Exactly. The reader gets to the table and pauses. My understanding at the time was the user could proceed apace or ask for the table title and summary, then possibly look ahead to the caption and legend, before deciding whether to simply skip over the table or proceed. Developers at the time felt that having @summary on <TABLE allowed for a breakpoint to be set, facilitating skipping over the table and saving cycles in the process. The D tag another idea that surfaced at the time. It would have been used inside a textual element to present a link to along description, and/or read a title and short description [visual presentation in a tooltip box over the 'D']. Developers wanted to ensure that they didn't have to look ahead of the table to find the related long and short descriptions. <D idref=#pic/tbl/obj" href="..." title="..." shortdesc="The picture/table/object ...">D</D> >Of course - just speculations. > >As for truncated @title tooltips: it seems natural that they *considered* >using @title before going for @summary. Even today, @title and @alt are >often discussed in context ... Yes, we definitely considered using @title. We wanted @shortdesc and @longdesc on every element for which it would be helpful to AT, including Braille transcription systems. >But it has been pointed out to me that only expert AT users access the >@title information. And @title is also, in general, too semantically >unspecific. With some exceptions, such as <abbr>, that prove that it >sometimes is /possible/ to define specific @title semantics. (In my view, >it ought to have been possible for caption@title - though the right moment >for that idea probably was 10-12 years ago.) Just so. @summary can fade in to the distance after ARIA is deployed and employed. There is no advantage to redesigning @summary in isolation, and ARIA has already done the design work on a replacement. >Conclusion: 1) We need a time machine. 2) @summary doesn't have the same >role to play as it potentially had. 1) Sadly, a time machine alone would not have helped. The politics of that HTML WG was as messy as ever. Design decisions have been foisted upon the HTML WG by one imperial vendor or another imperious editor, at one time or another. It was ever so. It's not as though we didn't try to do a good job, but there were personalities and politics. 2) I don't see how you reach this conclusion. @summary will complete its useful life after ARIA is fully supported, deployed and employed. There is no need to push it onto an ice flow just yet. We can afford to wait until its replacement is actually in place.
Received on Saturday, 8 August 2009 01:39:06 UTC