211114 - non-zero border attr should imply rules=all in strict XHTML too

Status: RESOLVED WORKSFORME

(Core :: Layout: Tables, defect)

Description

[Jeff Jackson]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624

In a strict XHTML 1.0 page, with content type application/xhtml+xml, table rules
are not rendering properly.  If border='1' is specified in the table start tag
and no value is given for the rules attribute, then no table rules are
displayed.  If rules='all' is included in the table start tag then only column
rules are displayed (row rules are missing).

Reproducible: Always

Steps to Reproduce:
1. Load the web page from the URL given.
2.
3.

Actual Results:  
The first table displays only column rules, the second displays none.

Expected Results:  
The two tables shown should both have all internal rules (row and column)
displayed.

Comment 1

[Bill Mason]

The second table, at least, is invalid.  The default value of rules is none, not
all.  http://www.w3.org/TR/html4/struct/tables.html#adef-rules

Comment 2

[Bill Mason]

Whoops, I forgot abut the implied values when border is set that are later in
the HTML spec....

Comment 3

[Bill Mason]

Wondering if this relates to bug 155507.

Comment 4

[Mats Palmgren (inactive)]

This is different from bug 155507 (which is about "rules implying collapse")

This is a valid bug AFAICT.
http://www.w3.org/TR/xhtml1/dtds.html#dtdentry_xhtml1-strict.dtd_TFrame
says that XHTML should behave the same as HTML in this case:

<!--
 The rules attribute defines which rules to draw between cells:

 If rules is absent then assume:
     "none" if border is absent or border="0" otherwise "all"
-->

Comment 5

[Josh Birnbaum]

I think this is a dupe of bug 68061 (or at least it covers some of the problems
here).

Comment 6

[Mats Palmgren (inactive)]

Yes, adding <tbody> fixes the problem, but I would like this to work even if
<tbody> is missing.

Comment 7

[Mats Palmgren (inactive)]

I stuck a few printfs in RowPostResolveCallback, ColPostResolveCallback,
ProcessTableRulesAttribute and it looks like the row have the wrong style
context parent.   MapAttributesIntoRule seems to map the attribute fine,
so this looks like it could be an effect of bug 68061 after all, since
the style system seems to depend on a correct hierarchy.

Comment 8

[Mats Palmgren (inactive)]

Attachment: ad hoc printf log

The row parent context seems to point directly at the table:
row->table(0x826ae3c)->???(0x826ac8c)
col->colgroup?(0x826c7bc)->table(0x826ae3c)

I'm pretty sure 0x826ae3c is the table since it has mRules=all

Comment 9

[Boris Zbarsky [:bzbarsky]]

> The row parent context seems to point directly at the table:

That's what should happen when there is no <tbody> in X(HT)ML...

Comment 10

[Boris Zbarsky [:bzbarsky]]

So... the URL in the URL field times out.  Is there a testcase for this bug?  If
so, could it please be attached to the bug?

Comment 11

[Mats Palmgren (inactive)]

Attachment: Testcase

This testcase reproduces the bug in Mozilla 1.4.
The bug is not present in Mozilla 1.4.1, so it looks like it was fixed
a long time ago...

Comment 12

[Mats Palmgren (inactive)]

-> WORKSFORME