[whatwg] Re: <section> and headings

Fri Nov 12 17:24:44 PST 2004

Ian Hickson wrote:
> Well, <h> wouldn't be backwards compatible at all. At least <h1> would
> look like a heading of sorts.

I give you one abbreviation: CSS.

Specifying a few simple rules in CSS will make this 
backwards-compatible. Few page authors keep the default heading style 
anyway. And as we're talking about using HTC's for compatibility in IE 
anyway elsewhere, this would be a trivial thing to add to one of those.

>>  <h1>Foo</h1>
>>  <section>
>>   <h3>Bar</h3>
>>   <h6>Quuz</h6>
>>  </section>
>>
>>Would be the same as H1, H2, H2, right?
> 
> Yes.

Arbitrary heading elements (1 out of 6) are incredibly verbose to 
express in CSS, and you'd have to place h1|h2|h3|h4|h5|h6 in any XPath 
expression as well. So in practice, I don't think this is a good option.

section h1, section h2, section h3, section h4, section h5, section h6 {
	font-size: xx-large;
}
section section h1, section section h2, section section h3, section 
section h4, section section h5, section section h6 {
	font-size: xx-large;
}

etc.

This should visually be the same as h1, h3, h6 and semantically the same 
as sections with weird headings inside.

> And if we don't redefine <h1> (and <h2> to <h6>), then you end up with
> the weird situation of having six elements which could easily be used
> but end up with meaningless semantics. (And they would be inline
> elements in legacy UAs, which is even worse.)

XHTML 2.0 does this. Probably for well-discussed reasons, amongst others 
a number of concerns you raised (like the search engine thing). I don't 
see why it shouldn't.

> e.g. at the moment, this:
> 
>    <body>
>     <h1>A</h1>
>     <section>
>      <h2>A.1</h2>
>      <section>
>       <h3>A.1.1</h3>
>      </section>
>     </section>
>    </body>
> 
> ...makes sense, but if we say you have to use a new element for
> headers, then the above is now meaningless and trying to make an
> outline from it would not do anything useful.

That's just not true, or I'm missing your point.

Try making a tree view of a document based on h1...h6 headings.
CSS: euh...
XSLT: euh...

Now try making a tree view based on h headings.
CSS: section { padding: 2em; border-left: 2px solid red; }
XSLT:
<template match="/">
   <html><body><apply-templates select="//section|h" /></body></html>
</template>
<template match="section">
   <section><apply-templates select="//section|h" /></section>
</template>
<template match="h">
   <h><apply-templates select="//section|h" /></h>
</template>

I don't think that can become more straightforward.

> Basically I want three things:
> 
>  1. It has to be possible to take existing markup (which correctly
>     uses <h1>-<h6>) and wrap the sections up with <section> (and the
>     other new section elements) and have it be correct markup.
>     Basically, allowing authors to replace <div class="section"> with
>     <section>, <div class="post"> with <article>, etc.

Aside from that I don't see why when you're changing the markup anyway 
you would still want to retain the old headings, the XHTML 2.0 solution 
allows for this just fine.

>  2. It has to be possible to write new documents that use the section
>     elements and have the headers be automatically styled to the right
>     depth (and maybe automatically numbered, with appropriate CSS),
>     and yet still be readable in legacy UAs, without having to think
>     about old UAs. Basically, the header element has to be header-like
>     in old browsers.

Let me just refer to my first (two) paragraph(s) here.

>  3. It shouldn't be too easy to end up with meaningless markup when
>     doing either of the above. So a random <h4> in the middle of an
>     <h2> and an <h3> has to be defined as meaning _something_.

This is no different than the existing spec. This would mean a 4th level 
heading between a second- and a third-level heading. Inside sections one 
could let the section level determine the heading level and treat all 
headings the same, or use the highest level of either the section or the 
heading. I don't see a need to define this more specificly, as h1...h6 
just don't go very well with sections. That's the way it is, and it 
won't really harm anyone.

> At the moment what I'm thinking of doing is this (most of these ideas
> are in the draft at the moment, but mostly in contradictory ways):
[...]

I think this is all needlessly complicated.

Note that for navigation XHTML 2.0 has <nl> Navigation Lists, which 
would correspond to your <navigation> tag. A sidebar (which side? how is 
it different from navigation and why is navigation not a sidebar?) 
usually consists out of links, and on places where it doesn't it is 
conte. And <article> (content) is implied (everything not navigation). 
All in all this set of tags you proposed sounds too specific to me.

> Related to this, we have have <fieldset> which defines a kind of
> specialised section (its header is always <legend>),

Same goes for <nl>.

> and <table>
> (header is given by <caption>); <blockquote> which marks a section as
> being a quotation, but which has no header or footer information,

Because it is a large quote.

> <group> and <switch> which are used to group sections given by
> <section> or <fieldset> (or something); <footer> for the footer of a
> section, <address> for the contact information of a section; three
> elements that mark up areas of the document as being of particular
> types: <ins>, <del>,

Note that XHTML 2.0 has replaced them with an 
edit="inserted|deleted|changed|moved" attribute which you can place on 
any elemen. Yes, I liked <ins> and <del> too :).

> and <form>; and the rest of the block-level
> elements which are for actual content (<p>, <ul>, <ol>, <dl>).

...actually I don't really know what you're trying to say with this 
paragraph :).

> To simplify the CSS rules for <h1>, we could limit the ways in which
> sections can be nested, and say that other nesting combinations do not
> cause the <h1>'s presentation to change by default in CSS-based UAs.
> 
>     Element       Meaningful descendents
>     <body>        <section> <article> <sidebar> <navigation>
>     <section>     <section> <article> <sidebar>
>     <article>     <section> <sidebar>
>     <sidebar>     <section>
>     <navigation>
> 
> Unfortunately the rules still become unmanageable after 3 levels (that
> is to say, the <h5> and <h6> levels have an insane number of rules).
> 
> An alternative would be to ask the CSS working group for an :or()
> selector of sorts, and then have:
> 
>    :or(section, article, sidebar, navigation) h1 { /* h2 */ }
> 
>    :or(section, article, sidebar, navigation) h1
>    :or(section, article, sidebar, navigation) h1 { /* h3 */ }
> 
>    :or(section, article, sidebar, navigation) h1
>    :or(section, article, sidebar, navigation) h1
>    :or(section, article, sidebar, navigation) h1 { /* h4 */ }
> 
> That might work.

Woohoo.

Note the amount of sarcasm in my voice, which can unfortunately not be 
transferred through this medium (well, I guess I could include some 
XVoice markup :)). Just use <section> with <h> headings and <nl> with 
<label> headings.

>>>I don't disagree. But it is backwards compatible.
>>
>>Not really. If search engines don't get upgraded to support this new
>>kind of H1 semantic all kinds of documents can be indexed wrong or
>>they can be marked inappropriate because they mis-use the H1 element
>>in the eyes of the search engine. (The same as with creating a page
>>full of links, but now you are mis-using a heading element.)
> 
> You are assuming that search engines trust authors to use <h1>
> elements correctly in the first place, and, more importantly, that
> they treat them differently to <h2> elements in a way that would be
> noticeable if this became widespread.
> 
> I highly doubt this.
> 
> Also, using <h> would have the same problem in reverse -- content
> would no longer be indexed as a header at all.

That is up to the site author to decide, isn't it. Not all content needs 
a high search rank, and not all content is used on the web. I also think 
it is a slight adjustment for e.g. Google to make to their engine, so 
who knows they will. At least if you don't try, you can be sure they 
never will. In any case h1...h6 would not be deprecated so there is no 
reason not to use them if you want to.

> The other advantage of using the existing <hX> elements is that
> Assistive Technologies will continue working, reporting the section
> headers, instead of saying there are no headers on the page.

Assistive Technologies don't work on pages using headers created with 
font tags or styled divs either. Assistive technologies can be updated. 
For technologies such as those, section tags actually make much more 
sense than headings as they're currently used.

Well, I think I made my point clear about now ;p. I saw you strongly 
suggest SVG 1.2 to make better use of existing other specifications. I'd 
say the same is valid overhere :).

~Grauw

-- 
Ushiko-san! Kimi wa doushite, Ushiko-san!!