21076 - Problem with TABLE frame="border" rules="all"

Status: RESOLVED FIXED

(Core :: Layout: Tables, defect, P3)

Description

[Christine Hoffman]

Using the following builds:
Win:1999120608
Mac: 1999120608
Linux: 1999120608

Behavior is across platform

Steps to reproduce:
Open attached file in 5.0

Expected result: There should be rules between rows and columns in the second
table (both tables should render identically)

Actual result: There are no rules between rows and columns in the second table

HTML 4.0 spec reference at:
http://www.w3.org/TR/REC-html40/struct/tables.html#h-11.3.1
states that <TABLE border> is equivalent to <TABLE frame="border" rules="all">

Comment 1

[Christine Hoffman]

Attachment: Testcase to demonstrate problem

Comment 2

[Hixie (not reading bugmail)]

David, here is another problem with the table attribute mapping which we
discussed in bug 15799, but occuring in straight HTML (no XML).

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Looks like a bug in the mapping of the 'rules' attribute...

Comment 4

[Mats Palmgren (inactive)]

Attachment: proposed patch to nsHTMLTableElement.cpp

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Does that handle values for rules other than all and none?

Comment 6

[Mats Palmgren (inactive)]

Yes, the patch works for all values: rules=none,groups,all,rows,cols.
None of them worked before the patch without using an explicit border attribute.

Comment 7

[Kevin Berkheiser]

Attachment: Frame and Rules not working correctly in this example either.

Comment 8

[Kevin Berkheiser]

I attached the 3rd file above thinking there was a problem with rules.  However,
the problem was mine.  I misinterpreted the DTD thinking that if you put rules
for a border you imply automatically that there is a border.  This is apparently
wrong.  So, if you put a border attribute at the start of the table, then the
rules work correctly.

Frame is a problem though.  I will do some check for a frame bug tomorrow, if
there is nothing filed I will create one.  Sorry for the SPAM.

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I think your original interpretation is correct and your new one is wrong.  See
http://www.w3.org/TR/html4/struct/tables.html#borders .  What says the rules
attribute won't work without a border attribute?

Comment 10

[karnaze (gone)]

mass move to m14.

Comment 11

[Karl Ove Hufthammer]

Frame and rules are not working properly in this example either:
<URL:http://home.no.net/huftis/artiklar/tabell.html#kantlinjer> (the page is in
Norwegian, sorry for this, but you should be able to understand the frame/rules
examples).

Comment 12

[karnaze (gone)]

Moving to M15.

Comment 13

[karnaze (gone)]

mass move to m16

Comment 14

[karnaze (gone)]

Moving to M17.

Comment 15

[karnaze (gone)]

*** This bug has been marked as a duplicate of 41262 ***

Comment 16

[karnaze (gone)]

I should have made a dependency instead of a dup. 

Comment 17

[fantasai]

Using "rules" in Mozilla requires that the table cells have a border assigned. 
The rules functionality then restricts these borders to where they need to be. 
(see bug 41411). This is why <TABLE border rules=cols> appears to work while 
<TABLE rules=cols> does not. Thus adding 
  table[rules] td, table[rules] th {border: thin inset}
can be used as a temporary fix.

Rules functionality should be addressed through html.css instead of the internal 
table code.

Comment 18

[fantasai]

Attachment: Demonstration of how "rules" functions in Mozilla

Comment 19

[Bernd Mielke]

Adding testcase keyword so this doesn't show up on the bugathon search page.

Comment 20

[Robin Lionheart]

Adding "html4" keyword, since these are HTML 4.0 attributes.

Comment 21

[Gervase Markham [:gerv]]

fantasai: You seem the best person to un-stall this bug. What's going on here? 
Is this patch still valid?

Gerv

Comment 22

[fantasai]

> What's going on here? 

Waiting until bug 43178 (and bug 41262) are fixed.

>Is this patch still valid?

I don't know for sure, but judging from the difference in testcase results 
between then and now and the fact that the rules code has been mostly disabled 
(bug 49490), I'm guessing no.

In any case, it's not what we should ultimately be using; this is just a symptom 
of the underlying problem bug 43178 describes.


I think the target milestone's just a tad off, though. ;)

Comment 23

[karnaze (gone)]

Moving to m1.0

Comment 24

[Amarendra Hanumanula]

QA contact update

Comment 25

[Amarendra Hanumanula]

Nominating this bug for the next netscape release because this is needed for the 
feature complete..

Comment 26

[karnaze (gone)]

collapsing border bugs moved to m098

Comment 27

[karnaze (gone)]

->m099

Comment 28

[karnaze (gone)]

Attachment: Revised 1st attachment (the tables are only identical with border-collapse:collapse)

Comment 29

[Kevin McCluskey (gone)]

Marking nsbeta1+

Comment 30

[karnaze (gone)]

Fixed by meta bug 41262.

Comment 31

[Amarendra Hanumanula]

   All the testcases Works fine. Build ID : 2002030403
Marking verified.

Comment 32

[Mats Palmgren (inactive)]

REOPEN, the original problem reported is not fixed, from the description:

   HTML 4.0 spec reference at:
   http://www.w3.org/TR/REC-html40/struct/tables.html#h-11.3.1
   states that <TABLE border> is equivalent to <TABLE frame="border" rules="all">

The bug is demonstrated by the first testcase, attachment 3298 [details] - 
the tables should be rendered identically per the HTML4 spec.

Comment 33

[Gérard Talbot]

What you're describing here fits, meets exactly bug 155507 and attachment 90028 [details]. 

http://www.w3.org/TR/html4/sgml/dtd.html#TFrame says:
"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'."

And CSS2.1 says
http://www.w3.org/TR/CSS21/changes.html#s-17-6
"Section 17.6 Borders
Several popular browsers assume an initial value for 'border-collapse' of
'separate' rather than 'collapse' or exhibit behavior that is close to that
value, even if they do not actually implement the CSS table model. 'Separate' is
now the initial value." 

Comment 34

[Gérard Talbot]

Bug 155507 and bug 172213 are closely related to this bug. I just wish these 3
bugs could be solved together.

Comment 35

[karnaze (gone)]

The html4.01 spec says:

rules = none|groups|rows|cols|all [CI]
    This attribute specifies which rules will appear between cells within a
table. The rendering of rules is user agent dependent. 

Mozilla forces "border-collapse:collapse" when "rules" is present (which is ok
according to the spec). It really doesn't make sense to have two rules between
cells, does it? So, I think this bug really is fixed considering that no rules
where showing up between rows and columns previously. 

Comment 36

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

But see comment 32.

Comment 37

[karnaze (gone)]

Yes, I saw that, but I also saw support for the way it is currently implemented.
I guess the spec should change one or the other.

Comment 38

[Gérard Talbot]

The way HTML 4.01 spec explains matters is that an implicit form is equivalent
to another one which is more explicit. But when trying, testing both forms, the
border-collapse property changes values. That's where the problem is. If the
default value of border-collapse is or should be collapse in Gecko, then it
should still be collapse regardless of the short or long form.

Idem est:
The HTML 4.01 spec 
http://www.w3.org/TR/REC-html40/struct/tables.html#h-11.3.1
says word for word:
"
For example, the following definitions are equivalent:

<TABLE border="2">
<TABLE border="2" frame="border" rules="all">
"

Now, if you view these 2 tables (in the upcoming attachment), the borders will
be separate in the first table while it will be collapsed in the second one.
It's incoherent.
I think the spec gives anyway less and less leeway regarding default value of
border-collapse (see CSS2.1).

A test case demonstrating these 2 tables is coming.

Comment 39

[Gérard Talbot]

Attachment: Example in HTML 4.01, section 11.3.1

The HTML 4 specs says:

For example, the following definitions are equivalent:
<TABLE border="2">
<TABLE border="2" frame="border" rules="all">

Respective table implement a different css border-collapse property value.

Comment 40

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(Should this issue be handled in bug 155507?)

Comment 41

[fantasai]

Yes, I think so. This bug was originally written because rules=all didn't work
at all--and that's been fixed. 155507 is more focused on the "identical
rendering" problem.

Comment 42

[Gérard Talbot]

See comment #34.
I think the default value of border-collapse should be separate as stated by
CSS2.1. 
I don't understand why the default value of the border-collapse property of a
table should change because rules="whatever" is/is not declared: there should be
no impact.