Closed Bug 21076 Opened 21 years ago Closed 18 years ago

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

Categories

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

defect

Tracking

()

RESOLVED FIXED

People

(Reporter: christinehoff4, Assigned: karnaze)

References

Details

(Keywords: html4, testcase, Whiteboard: [awd:tbl])

Attachments

(5 files, 1 obsolete file)

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">
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]
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.
Status: NEW → ASSIGNED
Target Milestone: M13
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?
Target Milestone: M13 → M14
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).
Moving to M15.
Target Milestone: M14 → M15
mass move to m16
Target Milestone: M15 → M16
Moving to M17.
Target Milestone: M16 → M17
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE

*** This bug has been marked as a duplicate of 41262 ***
I should have made a dependency instead of a dup. 
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Status: REOPENED → ASSIGNED
Depends on: 41262
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.
Adding testcase keyword so this doesn't show up on the bugathon search page.
Keywords: testcase
Depends on: 43178
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
> 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. ;)
Target Milestone: M17 → ---
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..
Blocks: 104166
Whiteboard: [PATCH] → [awd:tbl] [PATCH]
Target Milestone: mozilla1.0 → mozilla0.9.7
Blocks: 55623
collapsing border bugs moved to m098
Target Milestone: mozilla0.9.7 → mozilla0.9.8
->m099
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Attachment #3603 - Attachment is obsolete: true
Attachment #3298 - Attachment is obsolete: true
Marking nsbeta1+
Keywords: nsbeta1+
Fixed by meta bug 41262.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago19 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
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." 
Bug 155507 and bug 172213 are closely related to this bug. I just wish these 3
bugs could be solved together.
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
Closed: 19 years ago18 years ago
Resolution: --- → FIXED
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.
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.
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?)
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.
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.