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 4870 - Comment inside selector, with whitespace before and after
Summary: Comment inside selector, with whitespace before and after
Status: RESOLVED FIXED
Alias: None
Product: CSSValidator
Classification: Unclassified
Component: CSS 2.1 (show other bugs)
Version: CSS Validator
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: This bug has no owner yet - up for the taking
QA Contact: qa-dev tracking
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-07-19 10:40 UTC by CecilWard
Modified: 2009-02-06 16:45 UTC (History)
0 users

See Also:


Attachments

Description CecilWard 2007-07-19 10:40:55 UTC
Following on from my muddled comments wrt 3313

Test case 1:

    a /**/ b { width:0}

is (still) reported as invalid. (Tested using direc input, "no special profile" setting).

FYI, in contrast, compare this with the correct behaviour in each of the following test cases:

Test case 2:
  a /**/>  b { width:0}
(which is correctly? reported as valid).

and

Test case 3:
  a/**/ b { width:0}

Test case 4:
  a /**/b { width:0}

all of which are correctly reported as valid.



This is part of a more general comments==/!=whitespace issue.

[OffTopic]. This issue is arguably related to the quality of the CSS 2.1 (say) spec's appendix containing a rough formal grammar, which really does need to be cleaned up to clarify the rules about the distribution of comments and particularly [comment+whitespace] and [whitespace+comment] sequences.

I suggest that the validator team might like to pass on a comment to the CSS people as a suggestion for inclusion in a (imo much needed) CSS2.11 clarification addendum. probably just need the rules in the appendix to be fixed up a bit (poss, see the discussion wrt bug 3313).

Cecil Ward.
Comment 1 CecilWard 2007-10-24 10:18:07 UTC
Re-tested, 2007-10-24; behaviour remains unchanged. In respect of test case 1, the "correctness" of the validator needs to be reviewed, but the issue is at least as much about what actually is the precise grammar of CSS x?.?

In the light of the actual behaviour of IE versions it is arguable that the current behaviour of the validator (in failing test case 1) is "helpful", whether or not it is correct.

Maybe this is an argument for an "extra-strict" aka "real-world" or ("extra warnings") parsing mode option, one that is more restrictive than the real CSS vx.x published grammars, which would warn against bizarre unrealistic CSS that will fail in one or more known UA.

Comment 2 CecilWard 2008-03-23 07:11:52 UTC
Re-tested 2008-03-20. FIXED. (but not yet made public)

Test case 1 is now fixed in the development build http://qa-dev.w3.org:8001/css-validator/validator [- but the publicly visible build is still currently in error.]

So we can safely mark this as FIXED.

[!! HOWEVER, Test case 2 is NOW BROKEN in the development build - reported separately under new bug 5586 ]

Test case 3 and 4 are (still) fine, as ever.

Recommend adding (at least) all the four test cases, given that there's already been a regression.