Re: [RC2] separated-borders-model-007

> On Wed, 13 Oct 2010 08:44:45 +0200, GĂ©rard Talbot
> <css21testsuite@gtalbot.org> wrote:
>> http://test.csswg.org/suites/css2.1/20101001/html4/separated-borders-model-007.htm
>>> (...) Moreover, this test seems to depend
>>> on
>>> the HTML 'rules' attribute mapping to/interacting with CSS rules in
a
>>> certain unspecified way
>> Ă˜yvind,
>> It seems you added that testcase in the open issues wiki webpage[1],
under the section "Tests relying on non-normative behavior".
> Right. When it comes to interaction between different specs it's
always
> a
> bit tricky, but as mentioned in e.g.
> http://lists.w3.org/Archives/Public/public-css-testsuite/2010Sep/0026.html
it seems to me that it belongs more on the HTML side.

Řyvind,

If I remove the 'border-collapse: separate' declaration from the
testcase, then the table should render borders around all the cells,
each cells: and that is what I notice too [9]. If I explicitly declare
'border-collapse: separate' in the testcase, then the table should
render borders around all the cells, each cells as well: that is the
testcase main goal [8].

'separate' is the initial value for 'border-collapse'.
The testcase pinpoints an implementation issue wrt CSS.

> It has a
> dependency
> on the mapping from HTML attributes to CSS declarations
> , which only HTML5
> attempts to cover (though in an unfinished and non-normative section,
from
> the looks of it).
>  From my impression from the thread it seemed like an issue that was
> still
> open (I don't know what it takes to close it as invalid).
>> I assure
>> that separated-borders-model-007 testcase is sound and correct.
> It assumes that rules="all" on a table maps to CSS specifying border
on
> all four sides of each cell in that table. Which as far as I can tell
isn't normatively specified anywhere (especially not in CSS2).

The mapping of rules attribute to CSS is not specified explicitly in CSS
2.1 spec... but that does not mean that an adequate, best mapping can
not be figured out after careful reading of involved specifications.

There should be no influence, no impact between rules="all" and a
specified 'border-collapse' declaration. There is no contradiction none
whatsoever between rules="all" and a 'border-collapse' declaration. Same
thing with rules="none".

>> "In this [border-collapse: separate] model, each cell has an
>> individual
>> border."
>> http://www.w3.org/TR/CSS21/tables.html#separated-borders
> Sure. Though by default, it's 'none' (width 0) on all sides.
>> "all: Rules will appear between all rows and columns."
>> http://www.w3.org/TR/html4/struct/tables.html#adef-rules
> I think rules are expected to be unbroken lines (by default). Though
the
> HTML4 spec doesn't have much detail.
>> This was discussed before, in many places...
>> At the www-style mailing list [2], in bug 409470 at connect IE beta
feedback, in bug 155507[3] at bugzilla.mozilla.org, in bug 43178[4]
at
>> bugzilla.mozilla.org.
>> There is a consensus to implement rules as
>> table[rules]:not([rules="all"]) {border-collapse:collapse;} ,
> That doesn't make any sense.

It does make sense:

"
In this [border-collapse: separate] model, each cell has an individual
border. The 'border-spacing' property specifies the distance between the
borders of adjoining cells. In this space, the row, column, row group,
and column group backgrounds are invisible, allowing the table
background to show through. Rows, columns, row groups, and column groups
cannot have borders (i.e., user agents must ignore the border properties
for those elements).
"
http://www.w3.org/TR/CSS21/tables.html#separated-borders

Where does it say that each cells, all the cells can not have its own
borders in the 'border-collapse: separate' model? ... because this is
what the testcase I provided is testing: why 'border-collapse: separate'
does not honor rules="all"?

> All the browsers I tried

Browsers have implementation bugs, flaws, regressions, etc. That's why
we are developing a CSS test suite here.

> show rules=all tables in a border-collapse:collapse fashion.

By itself, this does not mean much. Browsers have bugs. I reported that
issue to bugzilla.mozilla.org [3][4], at IE beta feedback (bug 409470),
webkit.bugs.org [6], etc. The fact that bug reports were confirmed as
valid and reproducible ones does not mean that those bugs were
[partially or completely] fixed for good or that browsers now fully
honor the specs.

Anyone can see and verify that Ian Hickson, David Baron and Boris
Zbarsky approved
table[rules]:not([rules="all"]) {border-collapse:collapse;}
in bug 155507 [3]


> For Fx 3.6.10, Firebug shows
> table[rules]:not([rules="none"]) { border-collapse:collapse; }

Well, then that's a implementation bug as far as I can say. Each cell
can have a border thanks to rules="all" in the 'border-collapse:
separate' model. Nothing prevents or hampers each cells from having a
border thanks to rules="all" in the 'border-collapse: separate' model.

> That's only a small part of it though. To actually get lines in the right
> places, more declarations are needed. These could be setting border on
the
> relevant side(s) of each td and th. But they could just as easily be
setting borders on col and tr elements as appropriate.

Possibly
> overriding
> the outer border with border:hidden on the table element (unless of
course
> there are frame/border attributes saying otherwise)...
>> assuming that border-collapse: separate is the initial value.
>> There is no contradication between rules="all" and 'border-collapse:
separate'.
> The rules attribute is a presentational attribute. When specifying it
along with CSS, the result generally depends on how exactly the
relevant
> presentational hints are formulated in CSS terms.
>>> (Opera currently applies the horizontal rules to
>>> the <tr>s for instance
>> I even filed a bug on rules="none" [5] at Opera, years ago (bug
214944
>> in Opera BTS) and it's still happening in Opera 10.63.
> That seems to have to do with the interaction between the rules
> attribute
> and the border attribute. Doesn't seem directly related. Thanks for
reporting, though.


I reported the same bug at WebKit [7] at the same time (or possibly
earlier in Opera BTS or in opera.beta newsgroup) I did to WebKit. After
7 months, WebKit fixed that bug (fixed in Safari 3.1); after 3 years,
Opera did not (not fixed in Opera 10.63).


[1]
http://wiki.csswg.org/test/css2.1/issues#tests-that-are-wrong-or-have-parse-errors
[2] http://lists.w3.org/Archives/Public/www-style/2009May/0006.html
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=155507
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=43178
[5]
http://www.gtalbot.org/BrowserBugsSection/Opera10Bugs/Opera7RulesNoneIgnored.html
[6] Bug 3240 -  Support the frame and rules attributes on HTML tables
https://bugs.webkit.org/show_bug.cgi?id=3240#c2
[7] Bug 14341 -  rules="none" ignored in certain cases
https://bugs.webkit.org/show_bug.cgi?id=14341
[8]
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/separated-borders-model-007.html
[9]
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/separated-borders-model-007-without.html

regards, Gérard
-- 
Contributions to the CSS 2.1 test suite:
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/

CSS 2.1 test suite (RC2; October 1st 2010):
http://test.csswg.org/suites/css2.1/20101001/html4/toc.html

CSS 2.1 test suite contributors:
http://test.csswg.org/source/contributors/

Received on Wednesday, 13 October 2010 18:42:56 UTC