- From: Christian Roth <roth@visualclick.de>
- Date: Mon, 24 Jan 2005 15:00:37 +0100
- To: "www-style Mailing List" <www-style@w3.org>
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 normally. 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