- From: Maciej Stachowiak <mjs@apple.com>
- Date: Tue, 26 May 2009 11:50:29 -0700
- To: Larry Masinter <masinter@adobe.com>
- Cc: Ian Hickson <ian@hixie.ch>, HTML WG <public-html@w3.org>
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