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

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

From: Øyvind Stenhaug <oyvinds@opera.com>
Date: Tue, 19 Oct 2010 15:48:38 +0200
To: Gérard Talbot <css21testsuite@gtalbot.org>
Cc: "public-css-testsuite@w3.org" <public-css-testsuite@w3.org>
Message-ID: <op.vktsnceibunlto@oyvinds-desktop>
On Mon, 18 Oct 2010 23:11:18 +0200, Gérard Talbot  
<css21testsuite@gtalbot.org> wrote:

>> On Wed, 13 Oct 2010 20:42:15 +0200, Gérard Talbot
>> <css21testsuite@gtalbot.org> wrote:

>>> 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?

Yes. Somehow didn't catch this mistake when skimming through the mail...

>> 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:
>
> http://www.gtalbot.org/BrowserBugsSection/css21testsuite/separated-borders-model-007-without.html

No. First of all, Opera only adds internal borders (HTML4 says rules  
appear "between" rows/columns), as can be seen by removing the "border:  
outset 1px;" from the CSS in that page. (Same in Firefox 3.6.10 and IE8.)

Second, note that if "tr { border-color: lime; }" is added, the horizontal  
rule changes color (same in Firefox). With "td" instead of "tr", it  
affects the vertical rule (not in Firefox for some reason).

> 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.

It does prevent row borders from having an effect, as mentioned in one of  
the bug reports you linked to ([3] comment 8).

http://www.w3.org/TR/CSS21/tables.html#separated-borders
"Rows, columns, row groups, and column groups cannot have borders (i.e.,  
user agents must ignore the border properties for those elements)."  
(Implied: ...in the separated borders model.)

>>> 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?

Yes, sorry.

> 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.

See above, the horizontal ones should disappear if they are set on the  
rows.

>>> 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.

As a CSS2 conformance test, yes.

> 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:
>
> http://www.gtalbot.org/BrowserBugsSection/css21testsuite/separated-borders-model-007-without.html
>
> http://www.gtalbot.org/BrowserBugsSection/css21testsuite/separated-borders-model-007-without-2.html

Well, in IE8 the internal borders are some sort of light gray, as opposed  
to black in e.g. Opera and Firefox, but sure. I'm not sure what your point  
is, though.

>> 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.

OK, maybe the reference further up (regarding row borders in the separated  
borders model) will clarify things.

>> 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:
>
> http://www.gtalbot.org/BrowserBugsSection/css21testsuite/separated-borders-model-007-without.html

Of course there should, you're setting it in the CSS (and author CSS  
overrides presentational hints).

> 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?

I was referring to the rendering of contiguous lines across the entire  
width/height of the table i.e. collapsed borders model, vs individual  
rectangles around each cell, i.e. separate borders model.

>> 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,
> ideas.

The "unbroken lines" rendering which all my desktop browsers seem to have  
picked for rendering table rules.

>>> 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:
>
> http://www.gtalbot.org/BrowserBugsSection/css21testsuite/separated-borders-model-007-without-2.html
>
> and try to reconciliate it with its 'border-collapse: separate'
> corresponding equivalent:
>
> http://www.gtalbot.org/BrowserBugsSection/css21testsuite/separated-borders-model-007.html

I'm not sure what you mean by "reconciliate" in this context.

If you mean reconcile the renderings with each other/the specs, then in  
Opera's case the presentational hint given by "rules" seems to get  
translated to border-collapse:collapse and a hidden border on the <table>,  
a top border on the <tr>s and a left border on the <td>s (deduced from  
playing around with border colors etc, not code inspection). The <style>  
elements then override the table's border and the border-collapse.

In the first case (border-collapse:collapse) border-spacing is ignored (as  
per the CSS spec), and all solid borders mentioned earlier are shown. In  
the second case (border-collapse:separate) border-spacing is applied and  
all <table> borders plus the left <td> borders are shown. Top <tr> borders  
are ignored (as required by the CSS spec).

Now, one might argue whether this particular mapping makes the most sense  
or not, but there it is.

>>>> 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.

I was referring to the general case of a table with rules="all" and no  
CSS. E.g. IE 8.0.6001.18702, Firefox 3.6.10, Chrome 6.0.472.63 and Opera  
10.63 on Windows XP, all use collapsed borders.

>> 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:
>
> http://www.gtalbot.org/BrowserBugsSection/css21testsuite/separated-borders-model-007-without-2.html

I don't; that page specifies "border-collapse: collapse;".

By referring to the border-collapse:collapse rule as an implementation  
bug, you seemed to me to want rules="all" to render using the separated  
borders model, giving e.g. two separate lines between row 1 cell 1 and row  
2 cell 1. Which none of the browsers I have here seems to do (and more  
importantly, isn't mandated by any of the specs I've seen).

> [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

-- 
Øyvind Stenhaug
Core Norway, Opera Software ASA
Received on Tuesday, 19 October 2010 13:47:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 October 2010 13:47:51 GMT