W3C home > Mailing lists > Public > www-html@w3.org > September 2007

Proposed Feature for Future Work: <toc> Element

From: Doug Schepers <schepers@w3.org>
Date: Mon, 03 Sep 2007 19:30:40 +0900
Message-ID: <46DBE250.80703@w3.org>
To: www-html@w3.org

Hi-

This is a proposal for a future feature of HTML.  (I'm specifically not 
sending it to public-html, so as not to distract from the more important 
work of standardizing existing features.  I thought I'd send it in just 
to have it in the back of people's heads, and to get it out of mine. 
It's not a complete proposal, but just some thoughts, and I haven't 
researched if there's anything like this out there.)

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.

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.

Manual creation is simply too much of a pain, subject to errors of 
omission when the content is updated, though it does allow the author 
the most control.

Autogeneration is the most effective method, even though it often 
doesn't reflect how the author would have categorize the content 
themselves.  Mashup content usually isn't covered well by server-side or 
creation-time autogen.  Clientside script depends on the author 
including a robust lib, and is interpreted (normally not a problem, but 
cumbersome for larger documents that most benefit from a ToC).

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.

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.

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.

Note that this could be done with XBL2, but that would effectively be 
the same as a script lib solution, and would not have the semantics of a 
specified element.

Regards-
-Doug Schepers
W3C Staff Contact, SVG, CDF, and WebAPI
Received on Monday, 3 September 2007 10:30:44 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 10 December 2014 20:01:24 UTC