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

On 5/12/03 5:53 PM, "Ernest Cline" <ernestcline@mindspring.com> wrote:

> 
> Tantek Çelik wrote:
> 
>> 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.

This "separate block of its own" sounds purely presentational, that is,
there isn't expectation of using any block-level (in the content sense)
markup inside it.

Thus <kbd style="display:block"> should suffice to:
 "place the text to be entered by the user in a separate block of its own"
as you said.

I know we are perhaps splitting hairs, but these are important hairs to
split.


> (I can't see any such desire for a variable which is why
> I did not mention <blockvar>

I agree.  


>>> 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,

<snip/>

I can see the _need_ for additional _tags_ in order to make such a
theoretical full fledged CompML.

Yet I can see no _need_ for a full fledged _CompML_.  Thus the need chain is
broken and there is no need.

Actually, I suppose I can see one need for a CompML: it would be the ideal
punishment for the hardcore "use XML for everything" crowd (AKA XML
fascists), that is, create CompML just to compel that crowd to then rewrite
all their XML processing software using CompML in order to be fully
compliant with their religion, thus forcing them to either abandon their
religion, or to be so distracted and overwhelmed by the task as to reduce
the amount of noise in discussions - either outcome is a win.  Or perhaps
we'll end up with some equivalent to the Lisp interpreter written in Lisp.
In which case we might as well just skip the step of using XML and just use
Lisp.

So please, by all means, develop CompML and drop it on the "XML community".


> 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?

I'm glad you asked

That's *precisely* why XHTML Modularization (M18N) was developed.

 http://www.w3.org/TR/xhtml-modularization/

E.g. for skiing enthusiasts:

 http://www.w3.org/TR/xhtml-modularization/abstraction.html#sec_4.4.1.

*Anyone* can develop their own XHTML module.

Some might even argue that some of W3C's other content/document format
languages/namespaces would have been much smaller, easier for humans to
read/write (e.g.: less namespaces markupJunk), and integrate better if they
had been developed as XHTML M18N modules.

Tantek

Received on Monday, 12 May 2003 22:13:20 UTC