- 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