Re: [CSS 2.1] cases that do not pass in any browser

On Wednesday 2010-07-21 16:29 +0000, Arron Eicholz wrote:
> The following cases do not pass in any browsers. I have a feeling
> that the test cases are incorrect in most of the scenarios. With
> so many issues it would be great to get some help investigating
> each of these and seeing if the case is valid to the spec, if the
> case is just buggy and needs a simple fix or if the case should
> just be removed all together.

Continuing from my previous message,
http://lists.w3.org/Archives/Public/public-css-testsuite/2010Jul/0044.html

I skipped looking at all the tests whose names begin with
"margin-collapse".  I may attempt to come back to them later, but no
promises.

> http://test.csswg.org/suites/css2.1/20100701/html4/overflow-applies-to-010.htm

I believe this is currently valid, but I'd prefer that it not be.

> http://test.csswg.org/suites/css2.1/20100701/html4/quotes-036.htm

I'm not sure this is valid; it depends on <br> and <hr> not being
implemented as replaced elements and being fully stylable by CSS.
(Compare to quotes-035.)  Even if that is the case, it would be
something required by HTML5 and not by CSS2.1 alone, so I think
probably only quotes-035 (which I believe is the same thing without
the use of <br> and <hr>) should be in the CSS2.1 test suite.

> http://test.csswg.org/suites/css2.1/20100701/html4/run-in-breaking-002.htm
> http://test.csswg.org/suites/css2.1/20100701/html4/run-in-clear-002.htm

I defer to
http://lists.w3.org/Archives/Public/public-css-testsuite/2010Jul/0043.html
which comments on these.

> http://test.csswg.org/suites/css2.1/20100701/html4/tables-width-001.htm

Width calculation in tables is undefined in CSS 2.1, so this test is
not valid.

> http://test.csswg.org/suites/css2.1/20100701/html4/text-transform-bicameral-004.htm
> http://test.csswg.org/suites/css2.1/20100701/html4/text-transform-bicameral-005.htm
> http://test.csswg.org/suites/css2.1/20100701/html4/text-transform-bicameral-006.htm
> http://test.csswg.org/suites/css2.1/20100701/html4/text-transform-bicameral-021.htm
> http://test.csswg.org/suites/css2.1/20100701/html4/text-transform-bicameral-022.htm
> http://test.csswg.org/suites/css2.1/20100701/html4/units-008.htm
> http://test.csswg.org/suites/css2.1/20100701/html4/units-009.htm

Again, I'll defer to bzbarsky's comments on all of these.

> http://test.csswg.org/suites/css2.1/20100701/html4/white-space-mixed-001.htm

https://bugzilla.mozilla.org/show_bug.cgi?id=191699#c17 describes
why I believe this test is invalid:

  # I think substantial parts of Hixie's test are invalid, though.
  # I'll refer in this description to the parts of the test as being
  # lines (1) through (8), where the word PASS appears on lines (4)
  # (top) through (8) (bottom).  I think the test is invalid for the
  # following reasons:
  # 
  #  * It requires that the user-agent break at one point where a
  # break is forbidden.  In particular, this is the break that is
  # supposed to separate lines (4) and (5).  Both Mozilla and Opera
  # do not break here.  I believe this break is forbidden because at
  # this break point (between the "x" before it and the "x" after
  # it) there are two spaces:  the first (in an inner span) has
  # 'white-space: nowrap'; the second (in an outer span that is a
  # descendant of the div) has 'white-space: normal'.  According to
  # CSS2.1, section 16.6.1, first ordered list, item 4.2, this
  # second space (with 'white-space: normal') must be ignored.
  # Therefore there is only a space with 'white-space:nowrap', and
  # that doesn't introduce a break opportunity.
  # 
  #  * Our other problem with the test is that we interpret the
  # spaces with 'white-space:normal' preceding spaces with
  # 'white-space:pre' in line (5) as breaking opportunities.  The
  # latter are supposed to be treated as non-breaking spaces.  I
  # need to have another look at UAX #14 and investigate
  # Web-compatibility issues related to changing our handling of
  # non-breaking spaces, or look into potentially treating these
  # spaces as non-breaking spaces were supposed to be treated and
  # not treating actual non-breaking spaces that way.  In any case,
  # I don't think the behavior here is defined by CSS.

I'm not sure whether the test has been revised at all since the time
I was commenting on it (December 2006), though.  (Or, for that
matter, whether relevant parts of the spec have changed since.)

-David

-- 
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/

Received on Thursday, 29 July 2010 00:41:56 UTC