Persona is no longer an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 21076 - Problem with TABLE frame="border" rules="all"
: Problem with TABLE frame="border" rules="all"
: html4, testcase
Product: Core
Classification: Components
Component: Layout: Tables (show other bugs)
: Trunk
: All All
: P3 normal with 1 vote (vote)
: ---
Assigned To: karnaze (gone)
: Amarendra Hanumanula
Depends on: 41262 43178
Blocks: html4.01 55623 104166
  Show dependency treegraph
Reported: 1999-12-07 14:40 PST by Christine Hoffman
Modified: 2002-10-03 00:48 PDT (History)
11 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Testcase to demonstrate problem (1.29 KB, text/html)
1999-12-07 14:41 PST, Christine Hoffman
no flags Details
proposed patch to nsHTMLTableElement.cpp (1019 bytes, patch)
1999-12-17 19:16 PST, Mats Palmgren (:mats)
no flags Details | Diff | Splinter Review
Frame and Rules not working correctly in this example either. (7.67 KB, text/html)
2000-01-06 21:31 PST, Kevin Berkheiser
no flags Details
Demonstration of how "rules" functions in Mozilla (2.33 KB, text/html)
2000-06-03 14:55 PDT, fantasai
no flags Details
Revised 1st attachment (the tables are only identical with border-collapse:collapse) (1.32 KB, text/html)
2002-02-04 15:43 PST, karnaze (gone)
no flags Details
Example in HTML 4.01, section 11.3.1 (2.00 KB, text/html)
2002-10-02 20:02 PDT, Gérard Talbot
no flags Details

Description Christine Hoffman 1999-12-07 14:40:37 PST
Using the following builds:
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:
states that <TABLE border> is equivalent to <TABLE frame="border" rules="all">
Comment 1 Christine Hoffman 1999-12-07 14:41:59 PST
Created attachment 3298 [details]
Testcase to demonstrate problem
Comment 2 Hixie (not reading bugmail) 1999-12-09 19:16:59 PST
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+9 (busy until November 7) 1999-12-09 19:35:59 PST
Looks like a bug in the mapping of the 'rules' attribute...
Comment 4 Mats Palmgren (:mats) 1999-12-17 19:16:59 PST
Created attachment 3603 [details] [diff] [review]
proposed patch to nsHTMLTableElement.cpp
Comment 5 David Baron :dbaron: ⌚️UTC+9 (busy until November 7) 1999-12-17 19:34:59 PST
Does that handle values for rules other than all and none?
Comment 6 Mats Palmgren (:mats) 1999-12-17 20:53:59 PST
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 2000-01-06 21:31:59 PST
Created attachment 4030 [details]
Frame and Rules not working correctly in this example either.
Comment 8 Kevin Berkheiser 2000-01-06 21:56:59 PST
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+9 (busy until November 7) 2000-01-07 06:45:59 PST
I think your original interpretation is correct and your new one is wrong.  See .  What says the rules
attribute won't work without a border attribute?
Comment 10 karnaze (gone) 2000-01-11 07:59:59 PST
mass move to m14.
Comment 11 Karl Ove Hufthammer 2000-01-30 10:29:18 PST
Frame and rules are not working properly in this example either:
<URL:> (the page is in
Norwegian, sorry for this, but you should be able to understand the frame/rules
Comment 12 karnaze (gone) 2000-02-13 22:24:56 PST
Moving to M15.
Comment 13 karnaze (gone) 2000-04-07 16:42:08 PDT
mass move to m16
Comment 14 karnaze (gone) 2000-05-07 15:57:36 PDT
Moving to M17.
Comment 15 karnaze (gone) 2000-06-01 17:22:23 PDT

*** This bug has been marked as a duplicate of 41262 ***
Comment 16 karnaze (gone) 2000-06-01 19:30:58 PDT
I should have made a dependency instead of a dup. 
Comment 17 fantasai 2000-06-03 14:53:29 PDT
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 2000-06-03 14:55:44 PDT
Created attachment 9574 [details]
Demonstration of how "rules" functions in Mozilla
Comment 19 Bernd Mielke 2000-06-12 06:10:54 PDT
Adding testcase keyword so this doesn't show up on the bugathon search page.
Comment 20 Robin Lionheart 2000-10-01 16:41:21 PDT
Adding "html4" keyword, since these are HTML 4.0 attributes.
Comment 21 Gervase Markham [:gerv] 2001-03-02 16:27:51 PST
fantasai: You seem the best person to un-stall this bug. What's going on here? 
Is this patch still valid?

Comment 22 fantasai 2001-03-02 18:37:52 PST
> 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) 2001-03-14 17:56:31 PST
Moving to m1.0
Comment 24 Amarendra Hanumanula 2001-03-22 13:19:37 PST
QA contact update
Comment 25 Amarendra Hanumanula 2001-04-30 18:22:15 PDT
Nominating this bug for the next netscape release because this is needed for the 
feature complete..
Comment 26 karnaze (gone) 2001-12-07 10:51:38 PST
collapsing border bugs moved to m098
Comment 27 karnaze (gone) 2002-01-15 09:19:13 PST
Comment 28 karnaze (gone) 2002-02-04 15:43:10 PST
Created attachment 67804 [details]
Revised 1st attachment (the tables are only identical with border-collapse:collapse)
Comment 29 Kevin McCluskey (gone) 2002-02-13 09:58:26 PST
Marking nsbeta1+
Comment 30 karnaze (gone) 2002-02-19 18:44:05 PST
Fixed by meta bug 41262.
Comment 31 Amarendra Hanumanula 2002-03-13 11:43:19 PST
   All the testcases Works fine. Build ID : 2002030403
Marking verified.
Comment 32 Mats Palmgren (:mats) 2002-09-29 17:41:34 PDT
REOPEN, the original problem reported is not fixed, from the description:

   HTML 4.0 spec reference at:
   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 2002-10-02 02:41:32 PDT
What you're describing here fits, meets exactly bug 155507 and attachment 90028 [details]. 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
"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 2002-10-02 15:16:42 PDT
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) 2002-10-02 18:40:55 PDT
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+9 (busy until November 7) 2002-10-02 18:42:12 PDT
But see comment 32.
Comment 37 karnaze (gone) 2002-10-02 19:11:54 PDT
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 2002-10-02 19:57:50 PDT
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
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 2002-10-02 20:02:16 PDT
Created attachment 101497 [details]
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+9 (busy until November 7) 2002-10-02 22:55:39 PDT
(Should this issue be handled in bug 155507?)
Comment 41 fantasai 2002-10-03 00:46:38 PDT
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 2002-10-03 00:48:48 PDT
See comment #34.
I think the default value of border-collapse should be separate as stated by
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. 

Note You need to log in before you can comment on or make changes to this bug.