This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 17509 - Include sign in NUMBER, PERCENTAGE, and DIMENSION tokens
Summary: Include sign in NUMBER, PERCENTAGE, and DIMENSION tokens
Status: ASSIGNED
Alias: None
Product: CSS
Classification: Unclassified
Component: CSS Level 2 (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Bert Bos
QA Contact: public-css-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-06-16 11:08 UTC by Anton P
Modified: 2012-06-17 19:50 UTC (History)
1 user (show)

See Also:


Attachments

Description Anton P 2012-06-16 11:08:46 UTC
Reported by Tab Atkins Jr. and fantasai

In 4.1 and G.2, the NUMBER, PERCENTAGE, and DIMENSION tokens (amongst others in G.2 such as LENGTH and ANGLE) depend on the {num} macro which is defined as

  # num 	[0-9]+|[0-9]*\.[0-9]+
in 4.2, and as

  # num 	[0-9]+|[0-9]*"."[0-9]+
in G.2.

The optional leading + or - sign that can be used with these tokens is tokenized as a separated DELIM token, and is combined with the following token during parsing.

This implies that you can insert a comment between the sign and the number.  This is undesirable for the following reasons:

1. It's unintuitive and doesn't serve much useful purpose;
2. It's not interoperable, since Gecko and PrinceXML both parse the sign as 3. part of the NUMBER/etc token, whilst other UAs seem to follow the spec;
3. It makes it difficult for spec authors to talk about numbers and such in grammar terms, because they must always remember to also allow an optional + or - DELIM preceding the tokens.

Conversation begins:
Bug report:
http://lists.w3.org/Archives/Public/www-style/2012Apr/0639.html
Comment 1 Anton P 2012-06-16 11:10:01 UTC
The WG resolved to include the sign in the NUMBER, PERCENTAGE, and DIMENSION tokens: http://lists.w3.org/Archives/Public/www-style/2012May/0235.html
Comment 2 Anton P 2012-06-16 11:15:22 UTC
The wording proposed and added to the errata doc at http://www.w3.org/Style/css2-updates/REC-CSS2-20110607-errata.html is to clarify that neither comments nor spaces are allowed after the sign in property values that are defined as <number>, <length> or <percentage>:

In 4.3.1 (Integers and real numbers), insert the word "immediately" as follows:

  | Both integers and real numbers may immediately be preceded by a "-"
  | or "+" to indicate the sign. 


Proposal:
http://lists.w3.org/Archives/Public/www-style/2012May/0727.html
Comment 3 Anton P 2012-06-16 11:18:09 UTC
The proposal and errata item in Comment 2 does not match the resolution made by the WG (see Comment 1).

Objection to proposed change: http://lists.w3.org/Archives/Public/www-style/2012May/0741.html
Comment 4 Anton P 2012-06-16 11:26:39 UTC
Bjoern Hoehrman notes that 4.1.1 (Tokenization) says:

  # COMMENT tokens do not occur in the grammar (to keep it readable),
  # but any number of these tokens may appear anywhere outside other
  # tokens.

and so the proposal to add the word "immediately" is not sufficient to solve the problem in any case; although Kang-Hao (Kenny) Lu notes that 4.1 says:

  # In this specification, the expressions "immediately before" or
  # "immediately after" mean with no intervening white space or
  # comments.

It seems that editorial work is needed to remove the conflict between these two sentences if the proposal to solve the issue by inserting the word "immediately" is adopted.


Conversation begins: http://lists.w3.org/Archives/Public/www-style/2012May/0727.html
Comment 5 Anton P 2012-06-16 11:31:18 UTC
Tab Atkins Jr. notes that to implement the resolution, it is instead necessary to change the {num} macro, and Kang-Hao (Kenny) Lu notes that it is also necessary to change the 'term' production in G.1.

Conversation begins: http://lists.w3.org/Archives/Public/www-style/2012May/0727.html
Comment 6 Anton P 2012-06-16 19:29:42 UTC
Proposal [http://lists.w3.org/Archives/Public/www-style/2012Jun/0410.html]:

1. In 4.1.1, change the "num" macro to:

  | num 	['+'|'-']?([0-9]+|[0-9]*\.[0-9]+)

2. In G.2, change the "num" macro to:

  | num		['+'|'-']?([0-9]+|[0-9]*"."[0-9]+)

3. In G.2, remove the "unary_operator" production entirely.

4. In G.2, change the "term" production to:

  | term
  |   : NUMBER S* | PERCENTAGE S* | LENGTH S* | EMS S* | EXS S*
  |   | ANGLE S* | TIME S* | FREQ S*
  |   | STRING S* | IDENT S* | URI S* | hexcolor | function
  |   ;
Comment 7 Anton P 2012-06-16 19:35:20 UTC
Correction: steps 3 and 4 in the proposal in Comment 6 apply to G.1, not G.2.
Comment 8 Kang-Hao (Kenny) Lu 2012-06-17 19:50:18 UTC
(In reply to comment #0)
> 2. It's not interoperable, since Gecko and PrinceXML both parse the sign as 3.
> part of the NUMBER/etc token, whilst other UAs seem to follow the spec;

To make this data complete, I'd note that IE9 is also Gecko-like from my testing. [1]

(In reply to comment #6)
> Proposal [http://lists.w3.org/Archives/Public/www-style/2012Jun/0410.html]:

I'd hope that this is fixed along with bug 17510 . They were in the same thread.

[1] http://lists.w3.org/Archives/Public/www-style/2012Apr/0082