Closed
Bug 165261
Opened 23 years ago
Closed 22 years ago
<hr style="width : auto"> not working if <hr> is block
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
RESOLVED
FIXED
People
(Reporter: halcanary, Unassigned)
References
()
Details
(Keywords: testcase)
Attachments
(1 file, 1 obsolete file)
|
598 bytes,
text/html
|
Details |
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html><head><title>Boog!</title></head><body>
<hr style="width : auto; margin : 3ex;">
<hr style="width : auto; margin : 3ex; display : inline;">
</body></html>
I've run across this bug in mozilla 1.1 and 1.0, on both win2k and linux. I'm
guessing it's a gecko problem, but I could be wrong.
The <hr>'s width is by default 100%. This can be changed to any percentage or
fixed length. But I can't seem to change it to "width:auto".
This only happens under strict compliance mode.
Workaround: use "display:inline;"
|
||
Comment 1•23 years ago
|
||
So, HR is treated like a replaced block element, adding 100% of the containing
block to the 6ex margins.
Setting margin:auto "cures" the problem.
Confirming on Mac OS X, 1.1 release, although it is a style issue.
|
||
Comment 2•23 years ago
|
||
attached above HTML as testcase
|
|
||
Comment 3•23 years ago
|
||
confirming on trunk 20021015
Assignee: asa → attinasi
Status: UNCONFIRMED → NEW
Component: Browser-General → Layout
Ever confirmed: true
QA Contact: asa → petersen
|
||
Updated•23 years ago
|
Priority: -- → P3
Target Milestone: --- → Future
|
||
Comment 4•22 years ago
|
||
OK, well this is "easy" to fix. Just subtract the margins off the available
width when computing the desired width. Except that's not the right way to do
it if the <hr> is display:inline, since the available width for inlines already
subtracts off their margins...
So we could work on some consistency in the availableWidth values we pass
around. Or we could just stop doing the HRuleFrame thing in standards mode and
use a block with some CSS on it. I looked over HRuleFrame::Reflow and
HRuleFrame::Paint, and this should be doable (even including noshade support)
except for all the selection voodoo that HRuleFrame does (in Paint() and in
GetContentAndOffsetsFromPoint()).
mjudge, is there a reasonable way of moving those out into CSS so that we can
use a regular block/inline/whatever frame for <hr>?
Assignee: attinasi → other
QA Contact: cpetersen0953 → ian
|
|
||
Comment 5•22 years ago
|
||
Attachment #103031 -
Attachment is obsolete: true
|
|
||
Comment 6•22 years ago
|
||
This happens in quirks mode too if you style the <hr> as "display: block".
OS: Windows 2000 → All
Priority: P3 → --
Hardware: PC → All
Summary: <hr style="width : auto"> not working under strict mode. → <hr style="width : auto"> not working if <hr> is block
Target Milestone: Future → ---
|
||
Comment 7•22 years ago
|
||
> Or we could just stop doing the HRuleFrame thing
You mean like my (heavily bitrotted) patch does in bug 38370? I think that's
what we should do in general. Someone just needs to take that patch and bring it
up to date (which means rewriting it to work in a rule-tree world, since that
patch was written in a pre-rule-tree environment).
|
|
||
Comment 8•22 years ago
|
||
Hey, if we can resolve the selection issues, I'd be happy to do that.
|
||
Comment 9•22 years ago
|
||
The original problem reported is WFM, 2003-08-14-22 trunk Linux.
Keywords: testcase
|
|
||
Comment 10•22 years ago
|
||
This has been fixed by the patch in bug 38370 which got checked in.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•