- 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>
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 “ox” is “oxen.” or as irony quotes: That was one of his “brilliant” 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 UTC