Re: Proposed Feature for Future Work: <toc> Element

Only some questions to better understand… :-)

On 9/3/07, Doug Schepers <schepers@w3.org> wrote:

> I think a ToC (table of contents) element would be a very nice feature.
>   ToCs are very common in a wide variety of documents, notably Wikipedia
> and technical documentation.

What is the difference between a table of contents (<toc>) and a
navigation list (xhtml 2 <nl> [
http://www.w3.org/TR/xhtml2/mod-list.html#edef_list_nl ] )?

Mainly, a toc can be both
1. a sort of website summary: a page contains the list of contents, in
wich each elements links to a page with the content;
2. a sort of page summary: a page contains both the list of contents
and contents, linked by internal anchors (#), typical of Wikipedia
pages.
3. a sort of section summary: a page contains more <section>s and each
section has its list of contents (rare, but possible)
?

> This can currently be done by manual or automatic generation at the time
> of content creation, or autogeneration server-side, or using client-side
> script.
[…]
> I propose a <toc> element, which would be an (optionally) empty
> list-type element (stylable with CSS just as a list).  There would be an
> attribute that specifies whether it should be autogenerated, or whether
> the author provided the content; if it's autogenerated, browsers would
> create and insert links as child elements (and nested elements) of the
> <toc> at parse-time, which I suspect would be the most efficient way to
> do it clientside.  Content inserted after document load (using script,
> etc.) would be added to the ToC as it is added to the DOM (dunno how
> replacement element content would work yet).  If the @auto is set to
> "manual" (or whatever), that means the author (or another
> content-creation mechanism) provided the content, but the semantics and
> navigation behavior would be the same.

You mean that  a <toc> element (or <nl> element) can have an attribute
like autogeneration="true" that enables autogeneration and, in this
case, gets each section title and puts it in the list?
It should get h1, h2 etc. or section > h1, section > section > h1 etc.?

> I don't have an opinion about a @hide/show (or @expand/collapse)
> attribute, which could be done with CSS.  There's probably other options
> that would be handy, but we should keep it simple at first.

@hide/show can be simply obtained with css nl { display: none; },
expand/collapse can be useful, but it shoul be:
1. collapse_all
2. expand_all
3. expand_single_items, collapsed by default, with buttons that
expand/collapse each list item, also hierarchically:

[+] item1
[-] item2
    item2.1
    item2.2
[-] item3
    [+] item3.1
    [-] item3.2
        item3.2.1
        item3.2.2
…

As David, I think that hide/collapse "should be considered a style
sheet issue".

> This would make it easier for authors when then are creating their
> content, and would give positive feedback for creating well-designed
> documents.  The effectiveness of this kind of immediate feedback is
> already evident in how relatively well Wikipedia content does ToC autogen.

I fully agree :-)

Best regards

-- 
Lorenzo De Tomasi
Designer multimodale
http://www.ipernico.it
http://www.isotype.org (in costruzione)

Received on Tuesday, 4 September 2007 08:07:41 UTC