Re: Bottom-up Sections

"Toby A Inkster" <tobyink@goddamn.co.uk> wrote:

> I agree that this is a problem -- for example, in a pure <section>, <h>
> worls a boxed case study in Chapter 2 would be an equal sibling with
> sub-chapter 2.1 and would be 'superior' to a boxed case study in
> sub-chapter 2.1.
>
> However, I think your solution is rather complicated. I'm sure a better
> solution could be found.

I agree:  The problem is real, but the proposed solutions are all quite
unsatisfactory.

We already have <blockcode> and <blockquote>; it seems what we need is
additional <blockxxx> elements: <blocknote>, <blockremark>, <blockwarning>
(or <blockcomment> for all three?), <blockabstract>, <blockproof>,
<blockbackground>, <blockexample>, <blockexcercise>, etc., etc.

Obviously, which of these elements are "useful enough to be included" would
be a difficult decision to make.  Thus, I propose a single new element:
<block>.  This element is similar to <div>; but, as opposed to <div>, it has
some semantic implications. While <div> is completely transparent and can
only be used for grouping elements for common styling and/or scripting,
<block> actually denotes an isolated -block- embedded in the normal content
flow, in the spirit of <blockcode> and <blockquote>.

Accepting this as a hypothetical solution, we come to the problem with
headings.  It makes no sense to put a heading for an enclosing section
inside a block, so one possible solution is to allow <h> inside <block>, and
extend its usage to apply to the nearest enclosing <section> -or- <block>.
Thus, a named theorem might look like this:

    <block>
        <h>Fermat's Last Theorem</h>
        <p>The equation
            <math xmlns="http://www.w3.org/1998/Math/MathML">
                <mrow>
                    <msup><mi>a</mi><mi>n</mi></msup><mo>+</mo>
                    <msup><mi>b</mi><mi>n</mi></msup><mo>=</mo>
                    <msup><mi>c</mi><mi>n</mi></msup>
                </mrow>
            </math>
            has no integer solutions for
            <math xmlns="http://www.w3.org/1998/Math/MathML">
                <mrow><mi>n</mi><mo>&gt;</mo><mn>2</mn></mrow>
            </math>.
        </p>
    </block>

The problem with this is that it overloads <h>, making the process of
determining the level of a header significantly more difficult.  Another
possibility is to use the @title attribute.

    <block title="Fermat's Last Theorem">
        <p>The equation [...] has no integer solutions for [...].</p>
    </block>

Unfortunately, this violates the principle that primary content should never
be put in attributes.  In this case, the @title attribute is inappropriate
because it does not attach -additional- information to an element; on the
contrary, the information is an essential part of the content.  So what
about introducing a new <title> element?

    <block>
        <title>Fermat's Last Theorem</title>
        <p>The equation [...] has no integer solutions for [...].</p>
    </block>

This approach is pretty good:  It avoids the problems with the previous
ones, and the cost of it seems quite low -- it's just one extra element.  It
does, however, overload the meaning of "title" a little bit; it would be
nice if there was a better name for it.  This leads us to consider the
<caption> element.

    <block>
        <caption>Fermat's Last Theorem</caption>
        <p>The equation [...] has no integer solutions for [...].</p>
    </block>

This is more appropriate, as the <caption> element already exists and has
the desired semantics.  It plays this role for tables and objects already,
so why not for blocks?  It seems like another use for the <caption> element
would only reinforce its position, not blur or overload it.  In fact, I
can't see any direct drawbacks to this approach.

As for the content model, <block> should allow/be allowed whatever/wherever
<blockcode> and <blockquote> are.  Note that this allows nested <block>s, as
it should.

The default rendering for <block> should be similar to <blockquote>.  To put
 it explicitly, I believe the best default visual rendering would be no more
than left and right margins.

Actually, I see one minor drawback.  The term "block" is already in use one
level above the HTML vocabulary to describe a certain kind of content.
Perhaps the name "box" could do as well; but this term is in fact equally
overloaded in CSS.  In reality, however, I don't think that this is a
problem.

--
Daniel Brockman
daniel@brockman.nu

Received on Sunday, 10 August 2003 12:18:01 UTC