Re: [XHTML2] Proposal: block[@kind] element (PR#7665)

Dear Mr. Pemberton,

Thanks for the response, although I'm having trouble understanding why
you say that my premise "seems to be that 'block' is about
presentation." I tried to foreclose such a reading at the start of the
second paragraph, as follows:

  This proposal fills the need for a general and unified method of
  applying inline-level *semantics* to block-level content. (emphasis
  added)

The current XHTML2 draft allows for certain semantics to be applied only
to inline-level content -- semantics for addresses, sample output,
definitions, emphasis, and citations -- while only two kinds of
semantics (those for computer code and quotations) are chosen to be
applicable to block-level content as well. I and many others have
wondered what the motivation is for this choice: Why can't I apply
emphasis semantics, for example, to several paragraphs or even an entire
section? Why can't I indicate in markup that an ordered list and a
table, for example, are together to be taken as some sample output? Or
that two paragraphs with an intervening image object together form a
definition?

The premise is not presentational because the distinction between block
and inline content is not presentational. Inline content cannot contain
block content as immediate descendants, whereas block content can. That
isn't presentational, but is rather a matter of restrictions placed on
the content model. My main purpose is to suggest that there should be a
mechanism in XHTML2 allowing, where it makes sense, semantics currently
applicable only to inline content to be applied to block content as
well. There is nothing about the notion of emphasis, for example, that
precludes content at the level of, say, multiple paragraphs from being
emphasized. (I gave the example of a legal document [such as a warranty
or software license] which often requires that several paragraphs
together be emphasized.) Similarly for addresses, sample outputs,
definitions, and (perhaps) citations.

My reason for proposing a single "block" element, with the semantics
provided in a "kind" attribute, was simply that a plethora of "block*"
elements with identical content models (viz., blockcode's and
blockquote's identical content models) would be messy and would cry out
for refactoring. There may be an objection that important semantics
should not be conveyed in an attribute, but if so, then the "object"
element, with its semantically important "type" attribute, should be
abolished in favor of the old "img" and "applet" elements. The lesson of
"object" seems to be that it's okay to refactor to a single element
(leaving semantics to a value-constrained attribute) in the name of
simplicity and unification.

I hope I have now been sufficiently clear in motivating my proposal, and
I look forward to hearing your further thoughts on the matter.

Yours truly,

Alexander

Steven Pemberton wrote:
> Thanks for your comment, and thanks for your hard work on this proposal. 
> Unfortuntately, your premise seems to be that "block" is about presentation, and
> it is not.  It is really about the content model of the elements.  We need
> different types of elements (code, blockcode) so that we can have a richer
> content model for one than the other.
> 
> Best wishes,
> 
> Steven Pemberton
> For the HTML WG
> 
> 
>> From: Alexander McCormmach <alexander@tunicate.org>
>> To: www-html-editor@w3.org, www-html@w3.org
>> Subject: [XHTML2] Proposal: block[@kind] element
>> Date: Wed, 04 Aug 2004 22:30:47 -0700
>> Message-ID: <4111C607.5020208@tunicate.org>
>> X-Archived-At: http://www.w3.org/mid/4111C607.5020208@tunicate.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 Tuesday, 24 January 2006 20:35:55 UTC