summarization information delivery options: attribute or element

aloha!

i'm sending this to the list because these are the points i made at 
today's HTML A11y TF telecon, but which i didn't minute as i can't 
type and talk and chew gum at the same time (i know, next time, lose
the gum)

when it came to the first question of the details versus summary survey,
i could not select an option because i support replacing the summary 
attribute with a summary element, and i would have liked the first 
question of this survey to have been a choice between summary as an 
attribute and summary as an element;

if authors and developers are used to the concept of using the summary 
attribute for the TABLE element in HTML4, why not simply change summary 
from an attribute to an element (regardless of what that element is 
named)? as an element, summary provides those who have actually used the 
summary attribute, with capabilities which were not possible when summary 
was an attribute; one of the internationalization issues authors have 
faced when using the summary attribute is how to provide multi-lingual 
versions of information which is limited to an attribute value, without 
the possibility of programmatically indicating natural language switches, 
through the use of the lang attribute;

if authors are as ignorant of the HTML4 attribute summary as some have 
claimed, then they won't be confused by an HTML5 element named summary 
which is the child of CAPTION;

bottom line: in order for a summarization of a table's contents to be of 
real utility, the summary's delivery mechanism needs to be able to 
support "rich content" -- that is, markup, such as use of the lang 
attribute to programatically indicate a natural language switch where 
multi-lingual versions of the summarizing information is required); 
ideally, such information should, therefore, be contained in an element, 
to ensure that an author can use standard markup to annotate/describe the 
table (such as ABBR, DFN, etc.), although i would NOT allow anchors or 
other interactive elements to be used in the summary/summarization 
element;

whatever the summary element's name, it should be a child of CAPTION, and 
should be considered a strong "hint" by the author, which is NOT rendered 
by default, thereby making it possible for multiple non-mutually 
exclusive alternative renderings of the summary's contents through user 
agent configuration; any "button" type mechanism could be one option 
offered by a user agent, just as user agents should allow users to flag 
FORM controls without explicit "submit" mechanisms and provide a UA user 
interface control for any FORM control that lacks an explicit "submit" 
mechanism; 

proposed next steps:

the task force needs to:

1. ascertain the position of working group members on summary as an 
   attribute versus summary as an element;

2. if the task force agrees on a summarizing element, then the various 
   proposals for the specific name and mechanics of the summarization 
   element would be the next deliverable of the task force in regards 
   the TF's feedback on the summary 1ssue; 

3. i'm not so opposed to DETAILS as an element name, but wonder if the 
   change in nomenclature is necessary -- what authors and users have 
   been asking for is the ability to use a limited set of markup tags 
   within the summarizing text, so as to indicate natural language 
   switches, the expansion for an abbreviation/abbreviated form, 
   emphasis markers, but NO interactive elements

my 2 cents, american, gregory.
-------------------------------------------------------------
ADVICE, n.  The smallest common coin.
                    -- Ambrose Bierce, The Devil's Dictionary
-------------------------------------------------------------
             Gregory J. Rosmaita, oedipus@hicom.net
  Camera Obscura: http://www.hicom.net/~oedipus/index.html
-------------------------------------------------------------

Received on Thursday, 25 February 2010 17:36:45 UTC