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

RESOLVED FIXED

Status

()

P3
normal
RESOLVED FIXED
19 years ago
17 years ago

People

(Reporter: christinehoff4, Assigned: karnaze)

Tracking

({html4, testcase})

Trunk
html4, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [awd:tbl])

Attachments

(5 attachments, 1 obsolete attachment)

(Reporter)

Description

19 years ago
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">
(Reporter)

Comment 1

19 years ago
Created attachment 3298 [details]
Testcase to demonstrate problem
Blocks: 7954
David, here is another problem with the table attribute mapping which we
discussed in bug 15799, but occuring in straight HTML (no XML).
Whiteboard: [PATCH]
Created attachment 3603 [details] [diff] [review]
proposed patch to nsHTMLTableElement.cpp
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.
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M13

Comment 7

19 years ago
Created attachment 4030 [details]
Frame and Rules not working correctly in this example either.

Comment 8

19 years ago
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.
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?
(Assignee)

Updated

19 years ago
Target Milestone: M13 → M14
(Assignee)

Comment 10

19 years ago
mass move to m14.
Keywords: patch
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).
(Assignee)

Comment 12

19 years ago
Moving to M15.
Target Milestone: M14 → M15
(Assignee)

Comment 13

19 years ago
mass move to m16
Target Milestone: M15 → M16
(Assignee)

Comment 14

19 years ago
Moving to M17.
Target Milestone: M16 → M17
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE
(Assignee)

Comment 15

19 years ago

*** This bug has been marked as a duplicate of 41262 ***
(Assignee)

Comment 16

19 years ago
I should have made a dependency instead of a dup. 
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
(Assignee)

Updated

19 years ago
Status: REOPENED → ASSIGNED
(Assignee)

Updated

19 years ago
Depends on: 41262

Comment 17

19 years ago
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

19 years ago
Created attachment 9574 [details]
Demonstration of how "rules" functions in Mozilla

Comment 19

19 years ago
Adding testcase keyword so this doesn't show up on the bugathon search page.
Keywords: testcase

Updated

19 years ago
Depends on: 43178

Comment 20

19 years ago
Adding "html4" keyword, since these are HTML 4.0 attributes.
Keywords: html4
fantasai: You seem the best person to un-stall this bug. What's going on here? 
Is this patch still valid?

Gerv

Comment 22

18 years ago
> 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. ;)

Updated

18 years ago
Target Milestone: M17 → ---
(Assignee)

Comment 23

18 years ago
Moving to m1.0
Target Milestone: --- → mozilla1.0
QA contact update
QA Contact: chrisd → amar
Nominating this bug for the next netscape release because this is needed for the 
feature complete..
Keywords: mozilla0.9.1, nsbeta1

Updated

18 years ago
Blocks: 104166

Updated

18 years ago
Whiteboard: [PATCH] → [awd:tbl] [PATCH]
(Assignee)

Updated

18 years ago
Target Milestone: mozilla1.0 → mozilla0.9.7

Updated

18 years ago
Blocks: 55623
(Assignee)

Comment 26

17 years ago
collapsing border bugs moved to m098
Target Milestone: mozilla0.9.7 → mozilla0.9.8
(Assignee)

Comment 27

17 years ago
->m099
Target Milestone: mozilla0.9.8 → mozilla0.9.9
(Assignee)

Updated

17 years ago
Attachment #3603 - Attachment is obsolete: true
(Assignee)

Comment 28

17 years ago
Created attachment 67804 [details]
Revised 1st attachment (the tables are only identical with border-collapse:collapse)
(Assignee)

Updated

17 years ago
Attachment #3298 - Attachment is obsolete: true
Marking nsbeta1+
Keywords: nsbeta1+
(Assignee)

Comment 30

17 years ago
Fixed by meta bug 41262.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago17 years ago
Resolution: --- → FIXED
   All the testcases Works fine. Build ID : 2002030403
Marking verified.
Status: RESOLVED → VERIFIED
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.
Status: VERIFIED → REOPENED
Keywords: nsbeta1+, patch
Resolution: FIXED → ---
Summary: When TABLE frame="border" rules="all", no rules are displayed → Problem with TABLE frame="border" rules="all"
Whiteboard: [awd:tbl] [PATCH] → [awd:tbl]
Target Milestone: mozilla0.9.9 → ---
Attachment #3298 - Attachment is obsolete: false

Comment 33

17 years ago
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

17 years ago
Bug 155507 and bug 172213 are closely related to this bug. I just wish these 3
bugs could be solved together.
(Assignee)

Comment 35

17 years ago
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. 

Status: REOPENED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED
(Assignee)

Comment 37

17 years ago
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

17 years ago
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

17 years ago
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 41

17 years ago
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

17 years ago
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. 
You need to log in before you can comment on or make changes to this bug.