- From: James Graham <jg307@cam.ac.uk>
- Date: Thu, 18 Nov 2004 12:50:39 +0000
Matthew Raymond wrote: > James Graham wrote: > > The idea is that outliners should structure outlines according to > the structure established by the <section> elements first. Within that > structure, they can establish further structure based on importance, > but it cannot break the structure established by the <section> elements. Right. That sounds roughly like my proposal for a heading model. > > Take this example: > > | <section> > | <h1>heading 1</h1> > | <section> > | <h2>heading 2</h2> > | <h3>heading 3</h3> > | </section> > | </section> > > The structure in an outline would be like this: > > heading 1 > +- heading 2 > +- heading 3 There is a second possibility here which is that we use a model in which, as a child of a <section> the value of n is ignored so the tree becomes: heading 1 +-heading 2 +-heading 3 This is nice in that it's conceptually simpler (except that <body> has to be special cased for backward compatibility) and allows one to do things like: <h1>MyNews</h1> <section id="currentStories"> <h2>Main Story</h2> <h3>Lesser story</h3> </section> I haven't entirely thought through the advantages and disadvantages of each approach. >>> I'd also like to see an optional attribute for <section> called >>> |level|, which would indicate the level of importance for all the >>> child <h> elements in the <section>. The idea would be that... >> >> >> Is there a reason for this? I mean what does the new attribute give >> that is a) useful and b) not already possible with <hn> + <section>. > > > The idea is that a child section will have the default |level| of > its parent plus one. Look at this example: > > | <section level="2"> > | <h>Level 2 Heading</h> > | <section> > | <h>Level 3 Heading</h> > | <section> > | </section> > > In this example, the second <h> element is equivalent to an <h3> > heading because the |level| of its containing <section> is related to > the level of its parent <section>. This establishes a recursive tree > that changes the importance of all <h> headers automatically. If you > use <h1>-<h6> elements, you are forced to change every header tag in > order to accomplish the same effect, which is really bad if you have a > lot of headers inside that section (unlike the example above, which is > deliberately simple for the purpose of understanding the concept). Right but how useful is "importance" likely to be in the real world? It seems to be a concept to which the people who write pages seem to be attached (hence including it is a nice feature because they are more likely to use the headings as structure correctly if they can do what they think of as important within the model) but I can't really imagine a UA making enough use of it to make this kind of attribute useful. > > >> I remain unconvined that <h> is at-all compatible with the goal of >> backward-compatibility or even particularly useful given that we have >> to retain <h1> through <h6> so little conceptual simplifcation of the >> language is obtained though <h>. > > > I'm not sure what you mean. In this scheme, and <h> header with a > section level of one is exactly the same as <h1>, and so forth. The > <h> header is a way of auto-assigning the numerical importance of an > <h#> element. In theory, if you had enough structure, <h> could be > equivalent to a theoretical <h25> element. This is one reason I sort-of prefer the model in which, inside a <section> the value of n in <hn> doesn't make a difference. We don't have backward-compatibility issues and we don't have artificial limits on the depth of nesting.
Received on Thursday, 18 November 2004 04:50:39 UTC