Re: "Outline" algorithm (document length and complexity)

On May 26, 2009, at 11:24 AM, Larry Masinter wrote:

>> I think it would be illogical to have the definition
>> of the vocabulary in a different document than the
>> vocabulary itself.
>
> Yes, that would be a bad editorial decision. The question is
> why "outline" is part of the vocabulary. What features of
> HTML use the "outline" function?

 From my point of view as an implementor, the definition of the  
document outline is pure semantics. Although cast as an algorithm, all  
it does is define the semantic overall structure of the document, that  
is to say, what the sections and headings are, and which heading  
applies to what section. I think a typical UA would not make use of  
these semantics directly.

In general, I think defining semantics is fine, even though it is not  
directly relevant to most HTML-processing software. But the particular  
definition here is quite complex. It would be difficult to assess its  
correctness without implementing and testing it, but it defines  
something that typical UAs won't do, and even if they do, it won't be  
exposed to automated testing. It would only affect portions of the  
user interface that are normally outside the bounds of conformance  
requirements, since they do not affect interoperability.

To turn the outline algorithm into something that can produce testable  
assertions, it would have to be exposed in some way, either as a DOM  
interface or by affecting the rendering. If that were done, we could  
better evaluate it. But I would question the value of a DOM API to  
expose the outline.

And while a styling hook may be useful, the most likely one that has  
been proposed is heading level. But the outline algorithm is a  
terrible way to determine heading level, if implemented literally. It  
would require walking the whole document up to the heading to  
determine its heading level. But a scripting-enabled user agent has to  
dynamically update style, and it can't walk the whole document to  
recompute heading levels every time the DOM is mutated. Thus, what  
would be needed in a real implementation is an algorithm to compute  
heading level from the point of view of an element, and rules to  
determine what kinds of document changes, if any, may change an  
element's heading level. Given an algorithm written that way, it would  
be very hard to prove that it gives the same answers as the whole- 
document-walking outline algorithm. Thus, the current spec is nearly  
unusable for implementations of a hypothetical heading level CSS  
selector.

 From all this I conclude that the current outline section is not a  
useful piece of spec. It does not currently imply any testable  
assertions for implementations, and if it did, it would be exceedingly  
difficult to write and validate a practical implementation.

> If some other application or feature requires an "outline"
> feature in HTML, what are their requirements? Are they all
> the same? How can we judge whether the algorithm specified
> meets the requirements for an outline function if the
> requirements are not stated and cannot be derived from the
> rest of the spec?
>
> If the only uses of "outline" are CSS or external "outline"
> processors, is an HTML interpreter which doesn't support any
> of those still required to implement the "outline" algorithm
> specified? Why?

By "HTML interpreter" do you mean "HTML user agent"?

Regards,
Maciej

Received on Tuesday, 26 May 2009 18:51:13 UTC