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

Hi, Lorenzo-

Lorenzo De Tomasi wrote (on 9/4/2007 5:07 PM):
> 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 ] )?

Well, the primary difference is that <nl> is specified, while <toc> is
just an idea in the rough. :)  Seriously, I'm not overly concerned how
the ToC functionality is defined... it could be its own element, it
could just be an attribute on a <ul>, <ol>, or <nl>.  The key idea is
that it would:

A) be semantically identified as a navigational element; and

B) have the ability to be autogenerated, with child elements
inserted into the DOM.


> 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)
> ?

Yes, nice summary... each of those qualify as a ToC.

The first one is out of scope for the autogeneration part of my
proposal (B), which would be restricted to the scope of a single page; this
is necessary, because that is the only DOM that the UA would be parsing,
so it's the only way to take advantage of that process.  Spidering the
site should not be handled by the browser; it could be handled by the
server or an authoring tool, of course (and I think it would be 
perfectly reasonable for an authoring tool to extend the behavior of 
this functionality to cover that case, if it so chose).  And any ToC 
list marked as such would still carry the semantics (A), just not the 
autogeneration behavior (though it ahould have all the behavior 
associated with the navigational semantics, whatever they are defined as).

I see no conflict in making sectional ToCs (3), but a way to limit the 
scope
would have to be defined.  I can think of various ways to do this, the
best probably being that a <toc> would only operate within the scope of
its sibling elements and their descendants, but I haven't thought
through the various consequences.



>> 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.?

Yes.  My intuition is that it would be better to define the sensitivity
of the autogeneration, with values like @toc:none|simple|deep, where
'none' means that the navigational semantics are applied, but no
autogeneration is done; 'simple' means that only header elements are
indexed; and 'deep' means that all named or IDed elements are included
within the indexed nesting structure.  (Or maybe some other parameterized
value designation would be better.)


>> 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.
> 
> As David, I think that hide/collapse "should be considered a style
> sheet issue".

Like I said, I have no opinion, but I'm happy to have it done in CSS.

Regards-
-Doug Schepers
W3C Staff Contact, SVG, CDF, and WebAPI

Received on Wednesday, 12 September 2007 11:10:47 UTC