W3C home > Mailing lists > Public > public-html@w3.org > August 2010

RE: providing a long description using the summary and details elements.

From: John Foliot <jfoliot@stanford.edu>
Date: Wed, 25 Aug 2010 09:30:29 -0700 (PDT)
To: "'Steven Faulkner'" <faulkner.steve@gmail.com>, "'Leif Halvard Silli'" <xn--mlform-iua@xn--mlform-iua.no>
Cc: "'HTMLWG WG'" <public-html@w3.org>, "'HTML Accessibility Task Force'" <public-html-a11y@w3.org>, "James Craig" <jcraig@apple.com>
Message-ID: <012301cb4472$d1624530$7426cf90$@edu>
Steven Faulkner wrote:
>
> The idea of the longdesc as a flag is to provide user agents with
> way to distinguish between the specific case of the details/summary
> being used for an image/long description so they can provide the user
> with specific instructions for use, which may be different than for the
> default interaction behaviour for details/summary (expected default
> behaviour is as disclosure widget
> http://en.wikipedia.org/wiki/Disclosure_widget)
>
>> Perhaps, what you suggest, is that we shall have two categories of
>> <details/> elements: those which are used for "normal" interaction. And
>> those where the content contains a long description of the <summary/>?
>> What kind of benefits would such a division in two categories provide?

James Craig (@cookiecrook) via twitter indirectly suggested that link[rel]
might play a role here: while we currently do not have a defined link type
of {rel="longdesc"}, I believe Leif already alluded to something along
those lines earlier (??). Then we could have a 'second category' <details>
element that is further defined with the rel attribute: <details
rel="longdesc">. Or am I off in the weeds?

 
>> Coming back to your proposal to use <iframe> as the conten of a
>> <details> element: I doubt that it will become generally acceptable, if
>> the the purpose is to provide a long description of of something
>> summarized in <summary/>, if the iframe  content is provided primarliy
>> for AT users, as I belive many developers will consider it quite
>> "expensive" to load an external page  - to all users - for that
>> purpose. A (longdesc) link would then be considered cheaper.
> 
> it is not necessary to load the page unless details is expanded,
> also we are not talking many bytes...

I have pondered on using xmlHTTPRequest as one method of 'expanding'
extended description text when required (pulling back the expanded
description 'in page' into either an expandable <div> or as a 'pop-up'
(liveregion) box), but I'm stumped on how that would be specced as a
default behaviour in the browsers. However, as a technique it suggests (to
me) some potentially interesting possibilities...

JF
Received on Wednesday, 25 August 2010 16:31:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 25 August 2010 16:31:08 GMT