Note: There are a few cases of duplicates in user autocompletion which are being worked on.

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

RESOLVED FIXED

Status

()

Core
Layout: Tables
P3
normal
RESOLVED FIXED
18 years ago
15 years ago

People

(Reporter: Christine Hoffman, Assigned: karnaze (gone))

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

18 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

18 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).
Looks like a bug in the mapping of the 'rules' attribute...
Whiteboard: [PATCH]
Created attachment 3603 [details] [diff] [review]
proposed patch to nsHTMLTableElement.cpp
Does that handle values for rules other than all and none?
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

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

Comment 7

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

Comment 8

18 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

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

Comment 10

18 years ago
mass move to m14.
Keywords: patch

Comment 11

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

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

Comment 13

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

Comment 14

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

Updated

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

Comment 15

17 years ago

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

Comment 16

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

Updated

17 years ago
Status: REOPENED → ASSIGNED
(Assignee)

Updated

17 years ago
Depends on: 41262

Comment 17

17 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

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

Comment 19

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

Updated

17 years ago
Depends on: 43178

Comment 20

17 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

17 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

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

Comment 23

17 years ago
Moving to m1.0
Target Milestone: --- → mozilla1.0

Comment 24

17 years ago
QA contact update
QA Contact: chrisd → amar

Comment 25

17 years ago
Nominating this bug for the next netscape release because this is needed for the 
feature complete..
Keywords: mozilla0.9.1, nsbeta1

Updated

16 years ago
Blocks: 104166

Updated

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

Updated

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

Updated

16 years ago
Blocks: 55623
(Assignee)

Comment 26

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

Comment 27

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

Updated

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

Comment 28

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

Updated

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

Comment 30

16 years ago
Fixed by meta bug 41262.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago16 years ago
Resolution: --- → FIXED

Comment 31

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

15 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

15 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

15 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: 16 years ago15 years ago
Resolution: --- → FIXED
But see comment 32.
(Assignee)

Comment 37

15 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

15 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

15 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.
(Should this issue be handled in bug 155507?)

Comment 41

15 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

15 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.