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

The <summary> proposal

From: Leif Halvard Silli <lhs@malform.no>
Date: Tue, 09 Jun 2009 04:23:34 +0200
Message-ID: <4A2DC7A6.206@malform.no>
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:

(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

(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

     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
     * It would help if @media reader{} was deployed:
       (The screen reader media type)
     * Content of <summary> is supposed to be the same as for
leif halvard silli
Received on Tuesday, 9 June 2009 02:24:14 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:49 UTC