325074 - [BC] Table edges and corners when border-collapse: collapse should follow specificity

Status: RESOLVED DUPLICATE of bug 1119649

(Core :: Layout: Tables, defect)

Description

[Michael Dayah]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

The standard in my interpretation is inspecific regarding border conflict resolution in the collapsed border model about whether classes applied to specific cells should override a style applied to all table cells. I think we should go by specificity rather than which cell is painted first to determine the border shown at that edge.

For example, <td class=x> should override <td> when TD { style } is set even though they're both technically applied only to the cell. While the spec doesn't mention this, it would make the collapsed border model much more useful and intuative.

Also, corners are resolved highly anomalously even with the current border conflict algorithm. In the test case attached, I would expect the top table to have blue corners rather than the two different splits shown since blue beat red for their competing edges. In the bottom table I would expect the three blue corners in the middle to be red since red won against blue for their edges.

Reproducible: Always

Steps to Reproduce:

Comment 1

[Michael Dayah]

Attachment: Two tables showing border and edge conflicts

Comment 2

[Michael Dayah]

Attachment: Expected rendering

Comment 3

[Michael Dayah]

This is really three separate issues filed as one bug. The first two paragraphs of the initial report are a request for enhancement and really should be directed at the W3C.

The first table in the test case illustrates something deliberately designed into Mozilla: corners are divided diagonally or horizontally among competing edges in a sort of compromise. I believe this is against the spirit of the collapsed border model, which is primarily different from the separate border model in that borders compete for edges. The separate model produces tables with borders that look like a compromise; if a red and orange edge meet, the border between them appears to be half red and half orange. The collapsed model exists in opposition to this, and if edges compete rather than compromise, so should corners.

The second table shows an anomaly of how competing corners are resolved. Since red won two edges and blue only won one in each competing corner along the middle, those three corners should have been red.

Comment 4

[Bernd]

Attachment: simpler testcase from bug 286797

Comment 5

[Bernd]

the yellow should be continuous around the first cell.

Comment 6

[Gérard Talbot]

Hello,

Bug 1119649 is a DUPLICATE of this bug here... but, for practical reasons, I think we should resolve this bug as a DUPLICATE of bug 1119649 .

Comment 7

[Gérard Talbot]

(In reply to Michael Dayah from comment #0)

> The standard in my interpretation is inspecific regarding border conflict
> resolution in the collapsed border model about whether classes applied to
> specific cells should override a style applied to all table cells.

If you carefully read section 6.4.3 Calculating a selector's specificity

http://www.w3.org/TR/CSS21/cascade.html#specificity

, you will see that the class attribute is more specific than element names; therefore class will override a style applied to all table cells.

Eg.

.green {border: green solid 8px;} /* a=0 b=0 c=1 d=0 -> specificity = 0,0,1,0 */

td {border: red solid 8px;} /* a=0 b=0 c=0 d=1 -> specificity = 0,0,0,1 */

<td class="green"> will have its borders green, not red.

> we should go by specificity rather than which cell is painted first to
> determine the border shown at that edge.
> 
> For example, <td class=x> should override <td> when TD { style } is set even
> though they're both technically applied only to the cell. 

<td class=x> should override <td> should override according to § 6.4.3 of spec.

> While the spec
> doesn't mention this, (...)

Read section 6.4.3.

Gérard

Comment 8

[Gérard Talbot]

No reply to comment #6. 

So I am RESOLVING as a DUPLICATE of bug 1119649. Tests (attachment 346002 [details] a good reduction, attachment 209993 [details], attachment 210048 [details]) in this bug are useful and will be added into bug 1119649.

If you strongly disagree with me resolving as such, then explain, elaborate.