W3C home > Mailing lists > Public > www-style@w3.org > January 2005

Concern: identifiers starting with a hyphen '-'

From: Christian Roth <roth@visualclick.de>
Date: Mon, 24 Jan 2005 15:00:37 +0100
To: "www-style Mailing List" <www-style@w3.org>
Message-Id: <20050124140037.4344@mail.visualclick.de>

I'd like to renew my (as of today still unanswered) concern [1] regarding
the pending allowance to have identifiers start with a hyphen.

I fear it does much more bad than good when keeping possible future
developments of CSS in mind, and as of now, even the definition is
incongruent between CSS21 and CSS3 drafts. The issues I have with this are:

1.. The core syntax of CSS21 [2] implements the hyphen at the
tokenization level. The given tokenization for FUNCTION contradicts the
rules in 4.1.3, second bullet, wherefrom one may infer that FUNCTION
tokens may not start with a hyphen.

2.. The core syntax of CSS3 [3] lacks wording similar to CSS21, 4.1.3
altogether, so FUNCTION identifiers here indeed *are* allowed. This leads
to the problem described in my earlier message [2]:

Assuming some CSS version will define the function sum( a , b ), then:

  -sum( 2cm , 4cm )

will not be handled as the negative value of sum( 2cm, 4cm ), but as a
function call to a function named "-sum", as the leading hyphen is
attributed to the {ident} macro used to define the FUNCTION token.

The problem seems solvable by writing it as

 - sum( 2cm ,  4cm )

That, however, is not allowed according to the grammar [4, 'term'
production] (no S between unary_operator and following token). Note that
this grammar is also normative for CSS21 [5].

It seems that allowing {ident} to start with a dash makes it impossible
to add a unary minus to non-vendor specific functions.

3.. There are already solutions to the problem of vendor-specific
extensions, namely:
(a) Use the underscore. It is guaranteed to never be used by the WG as well.
(b) Use \-xyz-... . This does not break any existing CSS parsers, is the
correct serialization of "-xyz-..." and is again ignored by the UA since
it probably does not know it, whereupon the error handling rules apply

The question is exactly why we want to allow a feature that may make
adding new functionality in some later incarnation of CSS much more
difficult, especially when there is no pressing need to do this at all?

My points summarized:

(i) Core syntax as described in CSS21 and CSS3 differ. This is bad, since
then it is no longer a *core* syntax of CSS. Lacking versioning of
stylesheets, a parser may be incapable to decide according to which rules
it should interpret the stylesheet.

(ii) Allowing the hyphen as identifier start character is a bad idea. It
poses a wealth of problems for CSS's future and does not solve any problems.

(iii) If hyphen-starting identifiers must absolutely make it into the
spec, don't do it at the tokenization level and rewrite grammars accordingly.

(iv) (general point) Make the CSS syntax so that conforming parsers can
be written. How difficult it is to write a conforming CSS parser can be
seen best in the fact that there doesn't seem to be one yet.

[1] <http://lists.w3.org/Archives/Public/www-style/2004Oct/0075.html>
[2] <http://www.w3.org/TR/CSS21/syndata.html#tokenization>
[3] <http://www.w3.org/TR/2003/WD-css3-syntax-20030813/#characters>
[4] <http://www.w3.org/TR/2003/WD-css3-syntax-20030813/#detailed-grammar>
[5] <http://www.w3.org/TR/CSS21/grammar.html>

Regards, Christian.
Received on Monday, 24 January 2005 14:01:34 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:16 UTC