Re: element.createOutline vs <outline> or <toc> [was: adding a note to 4.3.10.1 Creating an outline]

On 28/02/2014 02:38 , Silvia Pfeiffer wrote:
> On Fri, Feb 28, 2014 at 12:00 PM, Michael[tm] Smith <mike@w3.org> wrote:
>> It's not clear to me exactly what the generated content of such an element
>> would end up being. An <ol>? Or a <ul>? Or what? How would Web authors be
>> able to style it? (Would the contents be a shadow DOM or.. what?)
>
> It's no different to other composite elements with a shadow DOM. All
> the <ol>, <ul> etc would be inside the control. It would be stylable
> like other shadow dom objects (once we've figured that out).

"Once we've figured that out" might be one of the most important parts 
of that paragraph :)

Seriously, such an element would be quite complex. For instance, if a 
given section does not have an anchor, how would the link point to it? 
Do you get something that when clicked scrolls to the section but 
without navigating to the anchor? Or do you generate an anchor and 
navigate to it? If the latter, what happens when you share the link? We 
then need to have a predictable anchor-generating algorithm.

That's not impossible, both ReSpec and Anolis have that. But it would 
have to rely on live content. So what happens if, say, the section 
heading is editable and you edit it. Does the generated anchor change? 
Does the URL change if that's where you happened to be?

Sounds complicated? I'm not done :)

Presumably, the titles in the generated ToC would come from the section 
titles. However, while it's fine to have:

     <h2 id='x'>Using the <a href='#dfn-dahut'>Dahut</a> algorithm</h2>

you can't well convert that to:

     <li><a href='#x'>Using the <a href='#dfn-dahut'>Dahut</a> 
algorithm</a></li>

So, you could take the textContent. But that falls on its face for cases 
like:

     <h2>The <code>video</code> element</h2>

At this point, you now need a content transformation step as part of 
your ToC generation. It's not just links, other things like IDs or <dfn> 
need to be replaced.

What if the content is using CSS counters so that for instance the 
sections with class "appendix" get a counter reset (before the first 
one) and a switch to an alphabetic counter style. Do you carry over the 
generated counter content into the ToC? If not, how do you have the ToC 
contain enough contextual information from the tree to be able to 
reproduce the same effect?

Then you have performance. Imagine a document the size of 
single-page.html where some content can be dynamic (e.g. toggling the 
author view). You need to keep the ToC in sync, live. That's likely to 
have an impact.

And wouldn't this introduce a Flash of UnToCed Content? While the 
document is being parsed, do you update the <toc> every time a new 
section is found, or do you generate it only at the end when the full 
DOM has loaded? In both cases I think you'll get pretty unnatural effects.

>> And what precedents do we have for an element like <outline> or <toc>?
>> (that is, one that would inject some text content into one part of a
>> document by constructing it from some other parts of the  document)
>
> Wikipedia (in fact: mediawiki more generally) is a cow path IMO. See
> e.g. http://en.wikipedia.org/wiki/2014_Winter_Olympics .
> The "Contents" section is not a section created by the Web page
> developer, but auto-created (in this case: by the CMS).
> __TOC__ is the markup used in mediawiki.

But it's not *live* and it's not *automatic* in the browser. Some code 
generated it out of band and using its own conventions.

That's a common use case. Tools like ReSpec and Anolis do it all the 
time. But having something live and fully generic is another issue 
altogether. I actually think that the best implementation of your idea 
might be a revival of the notion of DOM Views, placed inside something 
akin to a seamless iframe. But I don't think we're likely to head there.

> I think, though, that we have plenty of examples of sites using this
> feature. And seeing that we already have the content for it from the
> outline algorithm, it should be fairly logical how to build it
> (including hyperlinks to page offsets to the outline elements if they
> have an id tag).

I agree that it's useful and there is a lot of usage, I just disagree 
that using an element is the right way to go about it. We should start 
with a method and after a few years of that if we do notice some 
specific usage patterns that justify an element, then we can pave that 
cow path.

I'd be really happy to use a method for this in ReSpec.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Friday, 28 February 2014 10:58:33 UTC