W3C home > Mailing lists > Public > public-css-testsuite@w3.org > May 2013

Re: invalid assertions in opera/submitted/css3-conditional/js/001.html

From: Florian Rivoal <florian@rivoal.net>
Date: Fri, 31 May 2013 14:07:15 +0200
Message-Id: <1370002035.10287.140661238066905.7733C50F@webmail.messagingengine.com>
To: public-css-testsuite@w3.org
On Fri, May 31, 2013, at 11:40, L. David Baron wrote:
> I believe that 4 of the tests in in
> contributors/opera/submitted/css3-conditional/js/001.html
> are not backed up by anything in the specification.
> In particular, Gecko fails the first two tests because of whitespace
> differences (running both the expected and actual results through
> .replace(/\s+/g, " ") makes them pass; don't forget to parenthesize
> the expected results).  I'm not aware that we've defined
> serialization to that level of detail, though maybe I missed
> something.

These tests were written before the specification was nailed down. 
I agree with you that we did not end up specifying to this level of 
details. I believe we discussed specifying these indentation rules
(or something similar) for all nested rules in CSSOM, but that nothing
conclusive came out of this discussion.

I believe we should standardize how white space behaves in
serialization, but as we haven't done so yet, there is no reason
to make fail tests because of this.
> The last two tests assert that implementations, when serializing,
> put an extra pair of parentheses around:
>   @supports (border: black) and (padding: 0) and (width: 0)
> turning it into:
>   @supports ((border: black) and (padding: 0) and (width: 0))
> I don't see any justification for this in the specification, and
> Gecko doesn't do it.

I agree with you this is not justified by the spec. This too
predates the specification about how serialization should
work. I must admit I don't fully remember the details, but I
think that at some point, I though it would be better to
enclose every supports_condition in parentheses.

 - Florian
Received on Friday, 31 May 2013 12:07:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 20 January 2023 19:58:19 UTC