W3C home > Mailing lists > Public > www-html@w3.org > July 2005

Re: code and blockcode

From: Jukka K. Korpela <jkorpela@cs.tut.fi>
Date: Tue, 12 Jul 2005 12:17:23 +0300 (EEST)
To: XHTML-Liste <www-html@w3.org>
Message-ID: <Pine.GSO.4.63.0507121133390.5954@korppi.cs.tut.fi>

On Tue, 12 Jul 2005, Simon Siemens wrote:

> I don't expect, that browsers do really implement a reasonable amount of 
> languages (five was the absolute maximum I could think of).

Browsers currently have no support to languages, except in fairly 
technical sense like selecting a font according to language as declared 
(which is really just a matter of mapping language codes to fonts).

But the rendering of language-dependent quotation marks would be fairly 
technical too. The Common Locale Data Repository already contains 
information on the use of quotation marks, in formalized (XML) format, for 
a large number of languages.*) Thus, it would be technically feasible now 
to implement <q> properly. The mainly reason to objecting to it is that 
cannot be introduced "smoothly": when some programs ignore <q> markup 
altogether, some program implement it brutally by introducing ASCII 
quotation marks, there would be little reason to use it on WWW pages even 
if some program started supporting it reasonably.

*) It does not cover the US English convention of putting a comma and a 
full stop inside quotation marks even when it is not part of the quoted 
text. But such things could be handled in an ad hoc manner rather easily, 
I suppose.

If XHTML 2 is intentionally made incompatible with all previous versions 
of HTML and is not meant to be rendered at all on current browsers 
(without enhancements), then <q> might make sense. Semantically, it
would let us distinguish between quotations proper (texts that have 
actually been taken as such from somewhere, indicated using <q>) and other 
uses of quotation marks, such as in
   The plural of &#8220;ox&#8221; is &#8220;oxen.&#8221;
or as irony quotes:
   That was one of his &#8220;brilliant&#8221; ideas.

> Maybe XML, 
> because they have the parser already built in and it's rather simple.

Pardon? Which browser? Recognition of lang attributes is no more difficult 
than xml:lang. (Processing language codes correctly, even when they have 
subtags, seems to have been too challenging to software vendors in the 
past, but it's not really rocket science.)

> The 
> XHTML specification should not force this behavior. Drawing it as preformated 
> text is sufficient in most cases.

Sorry, but I can't see what you are referring to. The message you quoted 
was about quotations and markup for them.

It seems that you are referring to previous discussion on _code_ markup.
Please do not quote such parts of a message that you definitely _don't_ 
comment on.

> On the other hand only a minor amount of sites contains code examples.

HTML has been criticized for containing markup like code and samp, which 
are very specialized in a sense. I think the critics have a point, but
the correct conclusion is not to remove such markup. Rather, to consider
other needs as well. Specialized structures require specialized markup.

Besides, code examples are usually not quotations but an author's own 
code. There is already markup for them: the code element.

> However omitting this attribute doesn't make much sense to me, because we 
> could step back to pre then. There is no advantage for any user agent 
> (compared to pre). And I think adding this attribute is not a huge step for 
> us but a reasonable benefit for some user agents (as pointed out above).

Which attribute?

Regarding markup for computer code, such as (fragments of) source programs 
presented in documents, I don't think that blocks of code differ 
essentially from blocks of plain text embedded for whatever reason.
Thus, <pre><code>...</code></pre> expresses the semantics reasonably well.
Programs that wish to do something special with blocks of code can take it 
from there.

If one wants to remove <pre> completely, and therefore offers <blockcode>
for something that <pre> is currently used, the question arises: if 
embedding plain text into an XHTML document is considered harmful,
why would computer source programs constitute an exception? (Source
code might not be regarded as plain text, though normally there is no 
other registered media type than text/plain that we could use. But 
independently of this, source code is surely plain text as opposite to 
text with markup, which is what <pre> is really about.

-- 
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
Received on Tuesday, 12 July 2005 09:17:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:16:03 GMT