Re: <blocksamp> and <blockkbd> (was Re: kelvSYC's Thoughts on the new XHTML Draft)

Tantek Çelik wrote:

Date forwarded: 	Mon, 12 May 2003 17:22:09 -0400 (EDT)
Date sent:      	Mon, 12 May 2003 14:23:50 -0700
From:           	Tantek Çelik <tantek@cs.stanford.edu>
To:             	<www-html@w3.org>
Subject:        	<blocksamp> and <blockkbd> (was Re: kelvSYC's Thoughts on the new 	XHTML Draft)
Forwarded by:   	www-html@w3.org

> 
> On 5/12/03 10:01 AM, "Ernest Cline" <ernestcline@mindspring.com> wrote:
> 
> > The code, kbd, var and samp
> > elements are too narrow in scope for a general purpose hypertext markup
> > language. Adding blockcode was step backwards in my opinion because as
> > Christoph pointed out, adding blockcode only makes sense if blocksamp
> > (and blockkbd) are added as well.
> 
> I believe <blocksamp> was agreed to (but just not the name until recently),
> and so will likely show up in the next draft.

<snip>

> I'm not sure <blockkbd> makes any sense though, since <kbd> is defined as
>  "Indicates text to be entered by the user."
> and it makes much less sense to expect there to be text to be entered by the
> user with block-level markup.

I can easily see a document author wishing to place the text to be 
entered by the user in a separate block of its own, even if it is only 
a single line. (I can't see any such desire for a variable which is why 
I did not mention <blockvar>

> > They are useful elements, but they
> > belong in a separate CompML (similar to MathML) not as part of XHTML2.
> 
> You're half right.  They belong in a separate module yes, which I believe is
> the plan.  They still belong in XHTML2 however, by including that module.
> Having a separate module rather than a whole separate language makes much
> more sense for something that small/lightweight that integrates well with
> the content model.

A separate module is a step in the right direction, but I can easily 
see without engaging in too much effort a need for additional tags in 
order to make a full fledged CompML, Tags such as:
 <const>       Indicates an identifier having a constant value.
 <token>       Indicates an identifier having an enumerated value.
 <function>    Indicates a subroutine that returns a value.
 <procedure>   Indicates a subroutine that
                does not return a value.
 <declaration> Indicates a section of code that declares types
                or classes, initializes and/or declares variables
                or constants, and/or declares subroutines.
 <main>        Indicates the main routine of a program.
 <type>        Indicates an identifier referring to the type of
                a variable or object.

That's seven more tags and with more thought I am sure can come up with 
additional tags that make just as much sense as any of the existing 
computing markup elements. Is XHTML2 going to add these tags as well?
I think not.

What about other fields that would like to have their markup included 
that would be as small/lighweight and yet integerate well with the 
content model, such as taxonomy markup? The very fact that the 
computing markup elements can be replaced in so far as structure is 
concerned with appropriately classed <div> and <span> elements is yet 
another reason to be wary of including them in XHTML2.

Received on Monday, 12 May 2003 20:53:11 UTC