- From: Leif Halvard Silli <lhs@malform.no>
- Date: Tue, 09 Jun 2009 04:23:34 +0200
- To: Ian Hickson <ian@hixie.ch>
- CC: Laura Carlson <laura.lee.carlson@gmail.com>, John Foliot <jfoliot@stanford.edu>, David Singer <singer@apple.com>, public-html@w3.org
Ian Hickson On 09-06-08 08.14:
> On Sat, 6 Jun 2009, Laura Carlson wrote:
>>> http://esw.w3.org/topic/HTML/SummaryForTABLE#head-847d2ebafa6828471a3d2777ad3676944007c35d
>>>
>>>
>> What do you think of the Long Term Solution Possibilities
>> listed in the Wiki, in particular a new <summary> element or
>> equivalent?
> I would really appreciate coherent e-mails for each proposal.
> [...] -- what does the element do? What are the proposed
> conformance criteria for authors? For browser vendors? For
> accessibility tools? How does it solve the problems that have
> been raised? What new problems can it introduce? [...]
The <summary> element proposal:
(1) <summary> demo:
http://malform.no/html5/figure-with-figcaption-and-figsummary
(2) Demo page shows 3 variants:
Demo 1: Figure>figcaption with table>summary
Demo 2: Figure>figcaption and figure>summary.
(No caption or summary inside table)
Demo 3: table>caption + table>summary (No <figure>)
(3) All the 3 variants are meant to be conforming variants. The
reason for testing all 3 variants is to see what currently works best:
Demo 2 is most compatible: Works in IE6, IE7, IE8, Firefox 2,
Firefox 3, Opera (tested version 10), Webkit (Safari 4).
(Firefox 2 support is limited.)
Demo 1 and 3 currently falls through in IE8 but otherwise
work reasonably well. However, demo 2 generally most
compatible (strangely enough, as it only uses new elements.)
Definitions of "works": Style-able, DOM is OK. Cross browser
support.
(4) Ideas behind the <summary> proposal:
a) <summary> as new child of <table> and of <figure>
b) The draft says that when a table is the sole content of a
figure element, then the <caption> element of the table
should /not/ be used - instead the captioning element of
of <figure> becomes captions the table. This proposal
extends this idea to also cover <summary>.
Thus, when the <table> is the sole content of
<figure>, the <summary> SHOULD be placed directly
in <figure>. (As a matter of fact, currently, in the
DOM, the <summary> will be placed as child of the
<figure>, no matter what - except in Opera and
in IE before version 8.)
(5) Advantages of the <summary> element proposal:
a) same name as @summary
b) <summary> is also proposed for XHTML 2
c) an element solution has more display options than
attributes and are, in some ways, more compatible.
(UAs must enable support for attributes. Whereas
the content of elements generally are available
without much problems. The problem is rather to
hide the content.)
Example of the wider compatibility: iCab is said
to support the @summary attribute. However, this is
only the case until iCab switched to using the
WebKit engine. Currently, therefore, iCab is
unable to read the content of @summary aloud.
However, iCab _is_ able to read aloud the text
inside <summary> on the demo page.
(6) Disadvantages:
a) Until a default CSS agreed upon and until UAs with
such default CSS are deployed, authors will need
to take care to do the styling properly.
b) Until <summary> as child of <table> is fully supported
cross browser, authors must place the summary as
child of <figure>. This is a fully workable solution
though.
There are certainly other disadvantages and possibly
other advantages as well. Please help me to dig it out.
(7) PS: The demo uses <figcaption> instead of <legend>. I support
Henri's bug report/proposal that one should mint another caption
element for <figure>, due to compatibility issue for <legend>
(especially in Firefox).
(8) Other issues:
* When <summary> is present, any eventual @summary must be
ignored.
* It would help if @media reader{} was deployed:
(The screen reader media type)
http://www.w3.org/TR/css3-reader/
* Content of <summary> is supposed to be the same as for
@summary.
--
leif halvard silli
Received on Tuesday, 9 June 2009 02:24:14 UTC