Hi,
I don't know whether this is the correct list for this question, so
please forgive me if it isn't.
My question concerns the CSS2.1 Candidate Recommendation
(http://www.w3.org/TR/CSS21/) and specifically Conventions
(#q4).
Why does it say "Document language element names are in uppercase
letters." ?
Surely for XHTML the document language element names /must/ be in
lowercase. Elsewhere in the document, lowercase is used for both HTML
and XHTML (e.g. #q1) In the
section on case (#q6), it says
"Note in particular that element names are case-insensitive in HTML, but
case-sensitive in XML."
This suggests to me that the Conventions section is misleading and
should be changed, especially because XHTML and SVG use lowercase
element names. Do you agree?
Rick

Wed, 27 Apr 2005, Beton, Richard wrote:

I don't know whether this is the correct list for this question, so
please forgive me if it isn't.

My question concerns the CSS2.1 Candidate Recommendation
(http://www.w3.org/TR/CSS21/) and specifically Conventions
(#q4).

Why does it say "Document language element names are in uppercase
letters." ?

It is merely a typographical convention, it does not affect
implementations or authoring requirements.

Surely for XHTML the document language element names /must/ be in
lowercase. Elsewhere in the document, lowercase is used for both HTML
and XHTML (e.g. #q1)

The document language element names in that section appear in uppercase to
me. Am I missing something? If you are referring to the "h1" in the
stylesheet, that is not part of a document, it is part of a stylesheet,
and hence has different typographical conventions.

In the section on case (#q6), it
says "Note in particular that element names are case-insensitive in
HTML, but case-sensitive in XML."

This is correct.

This suggests to me that the Conventions section is misleading and
should be changed, especially because XHTML and SVG use lowercase
element names. Do you agree?

I believe that currently none of the examples are XHTML or SVG, thus
sidestepping the issue.

Wed, 27 Apr 2005, Philip TAYLR wrote:

The document language element names in that section appear in
uppercase to me. Am I missing something? If you are referring to the
"h1" in the stylesheet, that is not part of a document, it is part of
a stylesheet, and hence has different typographical conventions.

And here ?

<table>
<tr><td>1 </td><td rowspan="2">2 </td><td>3 </td><td>4 </td></tr>
<tr><td colspan="2">5 </td></tr>
</table>

This is a part of an XHTML document, included at

#q7

Good catch. We'll update the spec to correct this. Thanks!

Wed, 27 Apr 2005, Philip TAYLR wrote:
K, but /how/ will you update it?
It depends on what the working group agrees to, but my proposal would be
to update 1.4.1 so that it says "except for XHTML examples" or something
along those lines.

Philip TAYLR wrote:
>K, but /how/ will you update it ? Follow the
>original poster's suggestion, to use lower-case
>for document element names, or present a document
>fragment that purports to be XHTML yet uses
>upper-case element names ?

The convention appears to also be violated here:
<#first-letter(first
example, as well as further down). In both cases, these are
fragments with unidentified document languages.

And here: <#q7(Anonymous
inline box example). Note this example is identified in the text as
HTML.

And here: <#floats(noted as
the Example). Unidentified document language.

I'll stop looking now, but Philip's example is not isolated.
Frankly, I don't see the need for this convention at all. There is
no ambiguity in any of these fragments. While it may be a good
convention for the authors to adhere to as part of an internal style
guide, perhaps, I don't see any need for that convention to be
expressed in the spec itself. Anyone who would be confused by any of
these "problem" examples probably shouldn't be reading the spec at
all.

Wed, 27 Apr 2005, Adam Kuehn wrote:
I'll stop looking now, but Philip's example is not isolated. Frankly, I
don't see the need for this convention at all. There is no ambiguity in
any of these fragments.
Fair enough. Maybe we should indeed just remove it.