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

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

From: Gérard Talbot <css21testsuite@gtalbot.org>
Date: Mon, 18 Oct 2010 14:11:18 -0700
Message-ID: <f3f8eae5d9d134e375318d12bbb62a53.squirrel@cp3.shieldhost.com>
To: "Řyvind Stenhaug" <oyvinds@opera.com>
Cc: "public-css-testsuite@w3.org" <public-css-testsuite@w3.org>

> On Wed, 13 Oct 2010 20:42:15 +0200, GĂ©rard Talbot
> <css21testsuite@gtalbot.org> wrote:
>> 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].
> Well, there is no way to tell visually whether the horizontal borders
> are
> set on the rows
> or the cells.


It would have been ok to leave the links at the bottom in your reply.
You see, it helps restauring context, follow a discussion, etc.

[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
[6] Bug 3240 -  Support the frame and rules attributes on HTML tables
[7] Bug 14341 -  rules="none" ignored in certain cases

>> 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].
> That's only valid if frames="all"

frames="all"? You must mean rules="all", right?

> made the UA add borders on the cells.

But that is the case too; rules="all" add borders around cells, each
cells in a majority of visual UAs too, including Opera 10.63:


Why some of those visual UAs stop doing so as soon as 'border-collapse:
collapse' is set (at the user agent stylesheet level or at the author
style sheet level)?

> It
> could just as well be setting horizontal borders on rows and vertical
> ones
> on the cells, CSS doesn't specify one or the other.

If rules="all" was only setting horizontal borders on rows and vertical
ones on the cells, then I should expect the same in both border-collapse
models. But we are not even at this point.

'border-collapse: separate' does not prevent only setting horizontal
borders on rows and vertical ones on the cells. I have quoted the spec
on both rules="all" and border-collapse: separate several times so far.

>> 'separate' is the initial value for 'border-collapse'.
> Initial values may be superseded by UA styles and by presentational
> attributes translated to CSS.

>> The testcase pinpoints an implementation issue wrt CSS.
> No, it pinpoints a difference in the way the frames attribute is
> translated to CSS rules.

frames attribute? You must mean rules attribute here, right?

Anyway, those rules="all" borders, regardless of where they are or where
you or I think they should be, should not disappear just because
'border-collapse: separate' is declared. And when they do disappear
because 'border-collapse: separate' is declared, then it becomes a
testable, testcase-able CSS issue about how 'border-collapse: separate'
is implemented.

>> 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.
> Nevertheless it's one out of several possible options.

After carefully reading the CSS 2.1 spec and the HTML 4 spec, I come up
with one option which fits, meets both specs. You seem to suggest that
there could be another one and because of such lenient
latitude/flexibility in HTML4, then it is sufficient reason/grounds to
invalidate my tescase.

rules="all" with 'border-collapse: collapse' show not diverging layout
among current (IE8, Firefox 3.6, Chrome 6, Opera 10.63, Konqueror 4.5.1)
browsers, at least in these testcases:



> I assume the CSS
> 2.1 conformance test suite is supposed to test CSS 2.1 conformance

I always have agreed to this.

> , not
> that the implementations do whatever we think makes the most sense.

I have read your sentence many times and I do not agree with it. The
reading of the involved specifications is required; arbitrary preference
or thinking is not what I suggested or said or recommended.

> I think it would be better to test this in the HTML5 testsuite, since
> HTML5 does attempt to specify the mapping explicitly.
>> 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.
> For the "user agent dependent" rendering of rules "between all rows and
> columns", there seems to be interoperability insofar as unbroken lines
> are
> drawn from one end of the table to the other. Not rectangles around each
> cell.

So, according to you, there should not be any border around the table
box in this testcase either:


According to you, there should be only 2 borders creating the "+" shape
inside that table and no rectangles around each cell. Did I understand
you correctly here?

> Translating this

Translating this? Translating what exactly? I'm just trying to follow
your argument here and it seems your referring to 2 different layouts,

> to CSS requires border-collapse:collapse.
>>>> 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
> I'm saying that it doesn't make any sense to exclude "all", since I
> would
> expect "all" to look like "rows" and "cols" combined. And it does in all
> the major current browsers, including Firefox.
>> Where does it say that each cells, all the cells can not have its own
>> borders in the 'border-collapse: separate' model?
> They can. But CSS doesn't say anywhere that "rules" sets borders on the
> cells.

Please examine this testcase then:


and try to reconciliate it with its 'border-collapse: separate'
corresponding equivalent:


>>> 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.
> So you're saying IE, Firefox, Chrome/Safari and Opera all show
> rules="all"
> in the wrong way?

If you are referring to very specific testcase(s) and if you define
browser versions, then yes, maybe. In the abstract or in general, I can
not say.

> Which specs are not fully honored in this respect?
>>> 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.
> But why expect rules "between all rows and columns" to show as
> rectangles
> around each cell?

I wanted to ask you that same question (why expect rules "between all
rows and columns" to show as rectangles around each cell?) regarding
this testcase:


regards, Gérard
Contributions to the CSS 2.1 test suite:

CSS 2.1 test suite (RC2; October 1st 2010):

CSS 2.1 test suite contributors:
Received on Monday, 18 October 2010 21:11:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:13:21 UTC