W3C home > Mailing lists > Public > public-css-testsuite@w3.org > July 2010

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

From: L. David Baron <dbaron@dbaron.org>
Date: Wed, 21 Jul 2010 14:20:13 -0700
To: Arron Eicholz <Arron.Eicholz@microsoft.com>
Cc: "public-css-testsuite@w3.org" <public-css-testsuite@w3.org>
Message-ID: <20100721212013.GA27035@pickering.dbaron.org>
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.
> http://test.csswg.org/suites/css2.1/20100701/html4/abspos-005.htm

I agree with bz's comments here.

> http://test.csswg.org/suites/css2.1/20100701/html4/abspos-024.htm

I also agree with bz here (note comment about changing the title.)
<p class="test" dir="rtl"></p> should probably be changed to
<div dir="rtl"><p class="test" dir="ltr"></p></div>

Even with that, it doesn't pass in Firefox, due to margin issues.
I'm not sure what the correct behavior there is.  (But p { margin:
0 } in addition makes it pass.)

> http://test.csswg.org/suites/css2.1/20100701/html4/active-selector-003.htm
> http://test.csswg.org/suites/css2.1/20100701/html4/at-charset-utf16-be-002.htm
> http://test.csswg.org/suites/css2.1/20100701/html4/at-charset-utf16-le-002.htm

I agree with bz's comments here.

> http://test.csswg.org/suites/css2.1/20100701/html4/bidi-004.htm

I'm reasonably confident there are white-space bugs in the bottom
line of this test.  Somebody should probably go through it while
considering http://www.w3.org/TR/CSS21/text.html#white-space-model
(and also the example in the next section) to figure out where
spaces need to be removed.

It *might* be correct otherwise.

> http://test.csswg.org/suites/css2.1/20100701/html4/bidi-009.htm

This test would be a good bit more readable if p had a margin.

While I didn't check the whole test (I only looked at "a b", to be
honest), I think this is showing that at least Gecko and WebKit
interoperably disagree with
http://www.w3.org/TR/CSS21/box.html#bidi-box-model , and put the
left (right) padding, border, and margin of an inline with
direction: ltr (rtl) on the first of its generated boxes, and put
the right (left) padding of such an inline on the last.

> http://test.csswg.org/suites/css2.1/20100701/html4/blocks-023.htm
> http://test.csswg.org/suites/css2.1/20100701/html4/blocks-024.htm

Shrink-wrapping is undefined in CSS 2.1, and percentage margins and
padding are also explicitly undefined:
8.3 says:
  # If the containing block's width depends on this element, then
  # the resulting layout is undefined in CSS 2.1. 
8.4 says:
  # If the containing block's width depends on this element, then
  # the resulting layout is undefined in CSS 2.1.

> http://test.csswg.org/suites/css2.1/20100701/html4/c414-flt-ln-000.htm
> http://test.csswg.org/suites/css2.1/20100701/html4/c414-flt-ln-001.htm
> http://test.csswg.org/suites/css2.1/20100701/html4/c414-flt-ln-002.htm
> http://test.csswg.org/suites/css2.1/20100701/html4/c414-flt-ln-003.htm

Firefox 3.6 and trunk pass all four of these; these tests do all
require a reasonably large window width.

> http://test.csswg.org/suites/css2.1/20100701/html4/containing-block-032.htm

I believe this test is correct according to the current spec (in
particular, the prose in point 4.1 of section 10.1:
http://www.w3.org/TR/CSS21/visudet.html#containing-block-details ).
I believe it's a known Gecko bug (making absolutely positioned
elements in a relatively positioned inline as though only the first
line of the inline establishes the containing block), although I
can't find the bug number.

> http://test.csswg.org/suites/css2.1/20100701/html4/direction-unicode-bidi-013.htm
> http://test.csswg.org/suites/css2.1/20100701/html4/direction-unicode-bidi-014.htm
> http://test.csswg.org/suites/css2.1/20100701/html4/direction-unicode-bidi-016.htm
> http://test.csswg.org/suites/css2.1/20100701/html4/direction-unicode-bidi-017.htm
> http://test.csswg.org/suites/css2.1/20100701/html4/direction-unicode-bidi-022.htm
> http://test.csswg.org/suites/css2.1/20100701/html4/direction-unicode-bidi-026.htm

I believe Gecko passes these, though I'm not sure since the font I
get is substantially different from the one in the screenshot.

> http://test.csswg.org/suites/css2.1/20100701/html4/first-letter-quote-002.htm
> http://test.csswg.org/suites/css2.1/20100701/html4/first-letter-quote-005.htm

I'll trust bz on these, since he looked at them.

> http://test.csswg.org/suites/css2.1/20100701/html4/floats-wrap-top-below-bfc-001l.htm
> http://test.csswg.org/suites/css2.1/20100701/html4/floats-wrap-top-below-bfc-001r.htm

I don't see where the references are for these.  In any case, these
are derived from the 25888-*-block tests that I contributed, which I
did contribute knowing Gecko didn't pass them.  I believe IE6/7 was
the only engine correctly implementing that part of the spec so far,
though I hope to fix Gecko at some point.  It wouldn't surprise me
if IE6/7 failed the test for other reasons, though.

> http://test.csswg.org/suites/css2.1/20100701/html4/font-family-name-013.htm
> http://test.csswg.org/suites/css2.1/20100701/html4/font-family-name-022.htm
> http://test.csswg.org/suites/css2.1/20100701/html4/font-family-name-023.htm
> http://test.csswg.org/suites/css2.1/20100701/html4/font-weight-bolder-001.htm
> http://test.csswg.org/suites/css2.1/20100701/html4/font-weight-lighter-001.htm
> http://test.csswg.org/suites/css2.1/20100701/html4/font-weight-normal-001.htm

I'm not qualified to comment on these.

I think I'll leave the rest (starting at margin-collapse-144) for


L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/
Received on Wednesday, 21 July 2010 21:20:44 UTC

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