W3C home > Mailing lists > Public > public-html@w3.org > March 2009

Re: summary="" in HTML5 ISSUE-32

From: Steve Axthelm <steveax@pobox.com>
Date: Sun, 1 Mar 2009 14:16:08 -0800
To: Robert J Burns <rob@robburns.com>
cc: Simon Pieters <simonp@opera.com>, Ian Hickson <ian@hixie.ch>, Leif Halvard Silli <lhs@malform.no>, HTMLWG <public-html@w3.org>
Message-ID: <r267ps-1056i-0E129D7B3844429AA8BF27BB8E900A29@MBP.local>
On 2009-02-27 Robert J Burns <rob@robburns.com> wrote:

>The reason it is not good enough is the same reason that summary
>should not be displayed by default in the normal flow of the document
>(as opposed to in the chrome or in the flow of the document in a
>special authoring mode). The 'summary' attribute provides a place for
>authors to include content directed at cognitively and visually
>disabled users to assist them in consuming the table. It should be
>left to the author and user whether they want that exposed in the flow
>of the document. Usually it will not be the case that authors and
>users want such information exposed in the flow of the document. This
>means that the two things – caption and summary – need two separate
>mechanisms or authors and users will not have that level of control
>over presentation.
>In conclusion, we do not want the 'summary' attribute value exposed by
>UAs by default in the flow of a document. We need to leave that up to
>authors and users. However, authoring modes and in the chrome exposure
>of the 'summary' attribute helps ensure proper use of the attribute.

Well put. Let me describe what I think is not an uncommon 
situation for web authors...

As a front-end web author, I get my style direction from a 
graphic designer/art director and copy from the 
marketing/content folks. Inserting visible extra copy (table 
summary information)  into a web document, whether that is 
@summary exposed in the normal flow of the document, or stuffing 
@summary information into caption, will almost certainly raise 
objections from the sources of style and content direction. Yes, 
in theory, I might be able to convince those parties that the 
visible @summary information is valuable and should be retained, 
but I can assure you that I will lose that argument in the vast 
majority of cases.

@summary, as it currently stands, allows me as a front-end 
author, to add this valuable information without in a manner 
that will not be overruled.

Keeping @summary and @caption separate and retaining the the 
rendering differences gives me the flexibility to add valuable 
metadata in places where I would _not_, given all other 
considerations, otherwise be able to add it.



Steve Axthelm
Received on Sunday, 1 March 2009 22:16:55 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:43 UTC