Re: How did the summary attribute become part of HTML 4.0?

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 
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 
>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 
Dave Raggett didn't like '@shortdesc'; he preferred '@summary'. It simply 

>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 
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']. 
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 
There is no advantage to redesigning @summary in isolation, and ARIA has 
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 
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:38:59 UTC