Re: Preparing to launch the Forms Task Force ...

>  Laurens Holst wrote:
> > <section>
> >    <h>Heading</h>
> >    <p>Blabla.</p>
> >    <section>
> >       <h>Subsection</h>
> >       <p>…</p>
> >    </section>
> >    <p>So, to conclude, blabla.</p>
> > </section>
> >
> > In HTML4, that would be:
> >
> > <h1>Heading</h1>
> > <p>Blabla.</p>
> > <h2>Subsection</h2>
> > <p>…</p>
> > <p>So, to conclude, blabla.</p>

On 23/03/07, Matthew Raymond <mattraymond@earthlink.net> wrote:
>    Yes and not. It could be marked up like this, for example:
>
> | <div>
> |   <h1>Heading</h1>
> |   <p>Blabla.</p>
> |   <div>
> |     <h2>Subsection</h2>
> |     <p>…</p>
> |   </div>
> |   <p>So, to conclude, blabla.</p>
> | </div>
>
>    In fact, thats probably how I'd mark it up.
>
> > Does the last <p> belong to the subsection? It does not, and the HTML4
> > doesn't claim that it does.

Real world content on many sites use divs wrapping headers to bundle
for example datetime mark, permalink and the header of a blog post
with the actual content that is contained in a higher level div.
Making the assumption that only the paragraphs that are ancestors of
the div closest wrapping the header belong to that header doesn't
work. A header in practice has to be treated as if all content below
it and not preceded by another header of the same or higher level
belongs to that header.

 >    Anyone reading your HTML4 example _only_ would assume that the second
> paragraph is part of the second level subsection, and there's no obvious
> way to remedy that with CSS. Furthermore, real markup structure is
> needed if you want to style the section and subsection boundaries.
> Marking up the subsection is unavoidable in this situation.

What I feel is that the conclusion should have a "Conclusion" header
in this particular case.


However, any algorithm that doesn't work for:

<div class="blogentry">
    <div class="title">
        <h2>Middle ages</h2>
        <div class="posted"><a
href="http://example.com/1230/11/04/middle_ages">#</a> <span
class="datetime">1230-11-04 12:43 CET</span> <a href="..."
class="author">timetraveller</a></div>
     </div>
    <div class="body">
        <p>Help! The time machine is broken and I'm stuck here!</p>
    </div>
    <ul class="feedback">
        <li><a href="...">trackback</a></li>
        <li><a href="...">read comments</a></li>
    </ul>
</div>

... is broken with regards to actual real world content. (That is, any
algorithm that doesn't associate the .blogentry>.body>p with the
leading .blogentry>.title>h2.)

>    If <section> were a failure, that would not prove that <div
> role="section"> would be a success. Quite the contrary, it would
> indicate that <div role="section"> would be as monumental a failure as
> <section> and therefore isn't spec-worthy.

Agreed.

>    (There are those that argue that some classes are purely
> presentational, but one could just as easily say that all class names
> are semantic because the presentation is motivated by the reasoning of
> the designer, even if he or she is not aware of it. Perhaps people are
> resistant to the idea of making all their classes semantic because they
> don't want to consciously analyze their unconscious decisions.)

There is always some level of semantics behind the decision to use
classes, it's just not a level of semantics HTML provides tools for
representing. Except of course for structure purely added to be able
to achieve a style effect requiring nested structure, such as having
an underline of a different colour than the text it underlines.

> > Additionally, I would think that if <div> were really to be meant as
> > <section>, they should have written a better description of <div> itself
> > [1]. I think the example is merely some kind statement that 'they don't
> > really miss a sectioning element, truly not', to point to if someone
> > complains about it.
> >
> > [1] http://www.w3.org/TR/html4/struct/global.html#h-7.5.4
>
>    The HTML 4.01 spec is so vague and underdefined at times that I would
> not assume a failure to define something can lead people to any sort of
> conclusion as to the original working group's intentions.

Well, it doesn't lend itself to making assumptions that the element
has certain implied-but-not-stated-out semantics either.

> >>    However, the semantics of <h1>-<h6> are clear about the fact that
> >> these elements begin sections.I would suggest that one way to process
> >> them is that they should be tied to their parent elements. The first
> >> <div> in the example above has a heading, then the child <div> has a
> >> heading, therefore the child <div> is a subsection of the parent.
> >> Associate elements accordingly. If there are two heading elements on the
> >> same level, then the second one begins a new section.
> >
> > Well, what I'm saying is, just don't define it. It's rather useless.
> > Outlines will work without it, and other than that I don't really see a
> > need for it.
>
>    Even for outlines, you need some means of determining how sections
> relate to each other. Heading either start a new sibling section or a
> subsection, so the beginnings and endings of sections will be clear in
> all but the literal edge cases if you determine those relationships.

The problem is that the grouping and sectioning semantics are
orthogonal. You may want to group elements on a lower level than
sectioning, like my example above.

> > Add to that that just because the sectioning is not done
> > explicitly, it's really not possible to derive the sectioning while
> > guaranteeing it's correct. (And no, you can not depend on <div>s to
> > properly indicate that, because both you and I know they're not used for
> > that purpose.) And last but not least, it would also save a huge bunch
> > of text in the specification.
>
>    While I agree <div> elements may be less useful than I previously
> argued, I don't feel that it is nearly as impossible as you say to
> create an algorithm for consistent document outlining across user agents.

As long as the algorithm doesn't tie a heading to the closest
surrounding div, it shouldn't be impossible. If it does, then it
wouldn't work on the web. But certain outline structures that are
wanted by content producers become unrepresentable.

> > Oh, I don't want to abandon it. <h1>…<h6> should stay exactly the way
> > they are. For an outline, that is good enough and always has been good
> > enough.
>
>    I disagree. There is no clear way to generate outlines, so user agent
> outlining algorithms will not necessarily produce identical or even
> similar results.

Yeah. The h1-h6 semantics and div semantics makes the structure of
many real world documents ambiguous. A similar problem exists with the
definition list semantics, though that one is somewhat better defined.
-- 
David "liorean" Andersson

Received on Friday, 23 March 2007 15:12:45 UTC