Closed Bug 109938 Opened 23 years ago Closed 22 years ago

Default width for <HR> rule is not honored inside a table cell

Categories

(Core :: Layout: Tables, defect)

Product:
Core
Component:
Layout: Tables
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
Future

People

(Reporter: jiang_wq, Unassigned)

References

Details

(Keywords: testcase)

Attachments

(1 file)

HTML snippet that shows functional and non-functional <HR> widths inside cells
623 bytes, text/html
Details 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.5+)
Gecko/20011112
BuildID:    20011112

The following is a very simple html file.  View it by
IE and then by mozilla and you'll see the difference.

<HTML>
<HEAD><TITLE>theTitile</TITLE></HEAD>
<BODY>
  <TABLE BORDER="1">
    <TR>
      <TD>top left</TD>
      <TD>top right</TD>
    </TR>
    <TR><TD COLSPAN="2"><HR SIZE="2" ALIGN="center" COLOR="#ADADAD"></TD></TR>
    <TR>
      <TD>bottom left</TD>
      <TD>bottom right</TD>
    </TR>
  </TABLE>
</BODY>
</HTML>


Reproducible: Always
Steps to Reproduce:
1. put the html content in the description into file a.htm
2. open that a.htm
3. you can see in the middle of the table the line is shortened to a dot.

Actual Results:  a dot in the middle of the table

Expected Results:  a line in the middle of the table
same result as reported.
I have
Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.5+) Gecko/20011112
1) Because the default horizontal rule width is the same as the width of the
content area, the value of the "ALIGN" attribute is not noticeable unless a
different rule width is specified using the "WIDTH" attribute. This is why your
<HR> is not centered. You must add a WIDTH attribute to the <HR> rule. No
problem for Mozilla here.

2) COLOR attribute is not supported by the W3C standard.

3) from WIDTH definition in W3C site
http://www.w3.org/TR/html401/present/graphics.html : "The default width is 100%,
i.e., the rule extends across the entire canvas". So when WIDTH is not present,
100% width must be assumed. This is how IE works for HRs, regardless of their
position. Mozilla assumes 100% default width only out of tables, while inside
them the default width becomes 1 pixel ! 

So this bug should be renamed to "Default width for <HR> rule is not honored
inside a table cell" and belongs to Browser->Layout.
Good call, Dimitrios. Marking NEW and -> Layout.

Old summary:
"table content not rendering correctly"

New summary:
"Default width for <HR> rule is not honored inside a table cell"

Related bugs: bug 81776?

Reporter: Your testcase is appreciated. In future, though, please use the
"Create a New Attachment" link for testcases, as that allows developers to save
the step of saving the testcase to disk :).
Assignee: asa → attinasi
URL: http://(no URL, see the .htm file I p...
Status: UNCONFIRMED → NEW
Component: Browser-General → Layout
Ever confirmed: true
Keywords: testcase
QA Contact: doronr → petersen
Summary: table content not rendering correctly → Default width for <HR> rule is not honored inside a table cell
The <HR> width appears to work within tables most of the time. It defaults to
one pixel when the <HR> contains an ALIGN= option /and/ the </td> is flush
against the <HR ALIGN="left"> tag.

View attachment for examples of things working correctly and incorrectly.
Additional - I see this behavior on Moz. build 2002010308 on Linux. Platform/OS
should probably be changed to "All"
Joe, FYI, all these icky <HR> bugs depend on some other bug to reorganize the code.

Attinasi told me this... I bet this bug is unfixable (without breaking something
else) unless that bug gets fixed.  :-/
If that's the case and the defect number is known, can it be added to the
"blocks" field of this defect?
Target Milestone: --- → Future
*** Bug 125507 has been marked as a duplicate of this bug. ***
.
Assignee: attinasi → table
Component: Layout → Layout: Tables
QA Contact: petersen → amar
This seems to work now. The test case I attached on Jan 3, 2002 displays
correctly with Moz build 20021117.
Yes, the abnormity is gone.  Should I (reporter) mark it fixed?
> Should I (reporter) mark it fixed?

FIXED is reserved for bugs fixed by code patches
this bug is WORKSFORME
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: