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
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
Depends on:
Reported: 2012-06-16 11:08 UTC by Anton P
Modified: 2012-06-17 19:50 UTC (History)
1 user (show)

See Also:


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:
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:
Comment 2 Anton P 2012-06-16 11:15:22 UTC
The wording proposed and added to the errata doc at 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. 

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:
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:
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:
Comment 6 Anton P 2012-06-16 19:29:42 UTC
Proposal []:

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
  |   | 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 []:

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