- From: Ian Hickson <ian@hixie.ch>
- Date: Sat, 28 Aug 2004 16:04:23 +0000 (UTC)
On Thu, 26 Aug 2004, James Graham wrote:
> > >
> > > <section>
> > > <heading>Header 1</heading>
> > > <p>Content for 1.</p>
> > > <section>
> > > <heading>Header 1a</heading>
> > > <p>Content for 1a.</p>
> > > ...
> >
> > WA1 defines something like this, re-using <h1> for the heading element.
>
> Instinctivley I dislike this proposal but I'm not sure I can easilly
> explain why.
>
> My first objection is that changing the meaning of <h1> isn't backward
> compatible for assistive technologies.
The way it is defined now, _any_ header element can be used, specifically
to allow it to be backwards compatible with existing UAs. The <h1> is
defined as being the only element that automatically gets restyled to
match the <section> nesting, though.
> True, authors can work around this using h2-6 elements but the spec
> states that these do not have the same behavior as h1 when they are the
> children of a section element.
Right.
> This makes it difficult to create documents which use the new features
> and degrade gracefully.
Well, I'm not really sure how else to do it. Do you have any suggesitons?
> I also think that using <h1> as a general purpose heading is really
> really ugly. But that's not much of an objection.
I don't disagree. But it is backwards compatible.
> It's also not clear how a structure like:
>
> <div class="heading">
> <h1>Page title</h1>
> </div>
> <div class="content">
> <h2>Content title</h2>
> </div>
>
> would be represented in the new scheme. Reaplacing the <div>s with
> <section>s and the <h2> with <h1> produces a different structure (page
> title and content title are equally important).
It would be:
<h1>Page title</h1>
<section>
<h1>Content title</h1>
</section>
...or, possibly:
<div class="heading">
<h1>Page title</h1>
</div>
<section>
<h1>Content title</h1>
</section>
...or, maybe (this is just thinking out loud now, the spec doesn't allow
this yet):
<heading>
<h1>Page title</h1>
</heading>
<section>
<h1>Content title</h1>
</section>
(For backwards compatibility, the second <h1> in all the above can be
written as <h2> without changing the WA1-defined semantics.)
> The new scheme makes it very easy to create illogical page structures.
> For example, it's not clear how the following should work:
>
> <section>
> <h1>Title</h1>
> <section>
> <h1>Subheading</h1>
> <section>
> <h2>Second subheading</h2>
> </section>
> </section>
> </section>
What is unclear about it?
It is semantically exactly equivalent to today's:
<h1>Title</h1>
<h2>Subheading</h2>
<h3>Second subheading</h3>
...or to the XHTML2:
<section>
<h>Title</h>
<section>
<h>Subheading</h>
<section>
<h>Second subheading</h>
</section>
</section>
</section>
Admittedly, the styling would look different (and would look wrong). But
that's becaue it uses a mixture of WA1-only markup and WA1-with-graceful-
fallback markup.
> On the other hand, there is some merit to a situation in which <section>
> creates structure and the choice of n in <h{n}> denotes the 'importance'
> of the heading relative to the content of the page (so, for example,
> search bots give lower weight to <h6> elements than <h1> elements
> regardless of the nesting).
I considered this, but making <h1>-<h6> have _different_ semantics than
each other in <section> elements basically makes it impossible to do the
whole backwards-compatibility trick.
> In general, I think that explicit markup for document sections is good
> (although I would like to see more single-purpose elements such as
> <header> or <footer> to provide addiational semantics for UAs - the
> ability to seperate out sitewide elements from page-specific content is,
> in my opinion, particularly important) but I think we need to carefully
> consider the way the old and new heading styles will interact,
> particularly since backward compatibility is important.
Yeah, <header> and <footer> or similar elements are almost certainly going
to be defined at some point, along with <content> (for the main body of
the page), <entry> or <post> or <article> to refer to a unit of text
bigger than a section but smaller than a page, <sidebar> to mean a, well,
side bar, <note> to mean a note... and so forth. Suggestions welcome.
We'll probably keep it to a minimum though. The idea is just to relieve
the most common pseudo-semantic uses of <div>.
> [1] http://jogin.com/weblog/archives/2004/07/19/hierarchy
Interesting article. I'll look at this in more detail at some point.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Saturday, 28 August 2004 09:04:23 UTC