- From: Doug Schepers <schepers@w3.org>
- Date: Mon, 03 Sep 2007 19:30:40 +0900
- 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