W3C home > Mailing lists > Public > www-html-editor@w3.org > July to September 2004

[XHTML2] Proposal: block[@kind] element

From: Alexander McCormmach <alexander@tunicate.org>
Date: Wed, 04 Aug 2004 22:30:47 -0700
Message-ID: <4111C607.5020208@tunicate.org>
To: www-html-editor@w3.org, www-html@w3.org

Editors and www-html participants,

The following is a proposal to add to the XHTML 2.0 specification one
new element, block[@kind], to remove two, blockquote and blockcode,
and to change the content models of several structural elements
accordingly. It is essentially derived from remarks made on the
www-html thread titled, "Bottom-up Sections," beginning August 8, 2003
[1], and also on the recent threads, "Display Properties of Elements"
[2], and "proposal for change of Flow.model" [3].

This proposal fills the need for a general and unified method of
applying inline-level semantics to block-level content. The current
approach involves adding a corresponding block-level element for
*each* inline element deemed fit for block treatment, prepending
"block" to the latter's name to produce the former's. That only two
elements, quote and code, receive this treatment seems ad-hoc, without
justification, though perhaps it is the desire to avoid making XHTML
2.0 an over-populated "tag soup" that motivates this choice. As many
have asked, "Why not blockaddress, blocksamp, blockdfn, or even
blockem, and blockcite?" All these elements have legitimate uses, but
the resulting tag soup can and should be avoided.

A better approach is to scrap the plethora of "block*" elements, all
with identical content models, in favor of a single "block" element
and an attribute -- I suggest the name, "kind" -- specifying the kind
of block being marked up. This new approach follows the consolidation
of img, applet, and object into a single element, object, using the
@type attribute to designate the kind of object being embedded. Of
course, the @kind attribute of the block element would not hold a MIME
type, but rather would specify the local-name of the inline-level
element whose semantics were being borrowed.

Thus block[@kind="address"] would be a block-level address, e.g., a
postal address with components marked up using l elements;
block[@kind="cite"] would be a block-level citation, e.g. in a
footnote or works cited list; block[@kind="dfn"] would be a
block-level definition, e.g. as part of formal philosophical,
mathematical, or scientific exposition; block[@kind="em"] would be an
emphasized block, e.g. as a warning or error, or as an especially
stressed part of a legal document; block[@kind="kbd"] would be a block
of input meant for the user to enter; block[@kind="samp"] would be a
block of sample output; and block[@kind="strong"] would be a strongly
emphasized block. The uses of block[@kind="code"] and
block[@kind="quote"] are many and well-known.

A block with no @kind attribute would designate a generic block of
text, with optional user-defined semantics using the @class attribute.
(Of course, @class may be used to further customize blocks *with*
@kind attributes.) An optional caption child element may provide a
caption for any block.

Finally, there is the issue of Flow.model. The points made in [3] need
to be refined, reiterated, and acted upon, not only for the sake of
the proposed block element, but for the many other elements that have
Flow.model as their content. Depending on the context, every such
element groups *either* content at the level of a single paragraph
(i.e., inline text, lists, blocks, and tables, but no paragraphs as
direct children) *or* content at the level of multiple paragraphs
(i.e., blocks, lists, paragraphs, tables, sections, but no inline text
as direct children). If the former, such an element's content model
should be p.model, if the latter, Structural.model. Thus Flow.model
should be changed to a choice between p.model and Structural.model.

Below are technical details outlining the changes to be made to the
Structural Module of the RELAX NG schema for XHTML 2.0 were this
proposal to be followed. They are also provided to clarify any
ambiguity above.

I look forward to continuing debate on these issues and others, and I
plan to offer two additional proposals -- one relating to
parenthetical notes and the other to element referencing by number --
in the near future. I know from observing www-html for quite a long
time that we all have the highest hopes that XHTML 2.0 will reach its
full potential as a semantically rich yet elegant and ultimately
useful markup for tomorrow's digital documents.

Thanks for all your dedication and hard work,

Alexander McCormmach

Founder and President
Tunicate Free Information Foundation


[1] http://lists.w3.org/Archives/Public/www-html/2003Aug/0029.html
[2] http://lists.w3.org/Archives/Public/www-html/2004Jul/0049.html
[3] http://lists.w3.org/Archives/Public/www-html/2004Jul/0005.html


= Technical Details

== Eliminated Grammar Structures

Sections titled "The blockcode element" and "The blockquote element"
should be removed.

== Additional Structures

[ x:h2 [ "The block element" ] ]
div {
    block = element block { block.attlist, block.content }
    block.attlist =
       Common.attrib,
       attribute kind { "address" | "cite" | "code" | "dfn" | "em" |
                  "kbd" | "quote" | "samp" | "strong" }?
    block.content = block.model
}

block.model = caption?, Flow.model

== Changes to Existing Structures

p.model =
    (text
     | Text.class
     | List.class
     | block
     | pre
     | table
     | Misc.class)*
Structural.class =
       address
     | block
     | \div
     | p
     | pre
     | section
     | separator

Flow.model = p.model | Structural.model
Received on Thursday, 5 August 2004 01:32:33 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:14:52 UTC