Closed
Bug 101368
Opened 23 years ago
Closed 21 years ago
[quirks] 'clear: both/right/left' css property applied to HR tag doesn't work
Categories
(Core :: Layout, defect, P4)
Tracking
()
RESOLVED
WORKSFORME
Future
People
(Reporter: mikiso, Assigned: attinasi)
References
Details
(Keywords: compat, testcase)
Attachments
(1 file)
290 bytes,
text/html
|
Details |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20010913 BuildID: 2001091303 I want to use <hr> tag with 'clear: both' style applied by CSS, but it has no effect. I think this may be related to bug 83592. Reproducible: Always Steps to Reproduce: 1. Just see the attached html file. Actual Results: The horizontal line and the text should be below the pink box in the right. Expected Results: The horizontal line and the text is displayed only on the left of the pink box. Mozilla caused the same result when * Property 'clear: both' was 'clear: all' or 'clear: right' * I used external .css file to set 'clear' property to HR * I used images instead of 'DIV' boxes But 'clear' property seems to work fine if applied to <h1> or <h2><h3>. IE5.5 & 6 displayed all of this well. (though support for 'clear: all' is unnecessary, I think; which is not W3C CSS specs) And this is the related spec: http://www.w3.org/TR/REC-CSS1#clear
Reporter | ||
Comment 1•23 years ago
|
||
Comment 2•23 years ago
|
||
You are in quirks mode. Add a DOCTYPE to your HTML, such as <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> or <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> Everything works fine once you do that. Please make sure that you follow the standards before filing bugs about standards compliance. Every HTML document must have a Document Type Declaration.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
Comment 3•23 years ago
|
||
On second thought, since we apply the standards to other elements even without the doctype, this should be re-opened. Is there currently a quirk that gets applied and needs to be removed?
Severity: major → normal
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Summary: 'clear: both/right/left' css property applied to HR tag doesn't work → [quirks] 'clear: both/right/left' css property applied to HR tag doesn't work
Assignee | ||
Comment 4•23 years ago
|
||
HR in quirks mode is a bastardization from hell. I doubt that clear on HR in quirks mode is that important anyway. Please reopen if you disagree, and attach a testcase (or URL) showing that Nav or IE do something meaningful with that css property. Thanks.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WONTFIX
Comment 5•23 years ago
|
||
Re-opening because IE 5.5 and 6 do the right thing here. The test case given in
attachment 50543 [details] works as expected per W3C standard in IE, yet fail in Moz.
On a side note: if <HR> in quirks mode is so bad, what would be the effects of
removing the quirks? Are there many sites that rely on its behaviours?
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
Assignee | ||
Comment 6•23 years ago
|
||
I think buster (previous layout engineer) changed to the current HR behavior because of a quirk, heavily relied upon, where an HR between two floated images, for example, will resize to fit between them. In standard mode this does not happen, as HR is a block, but lots of sites want this kind of look: XXXXXXXXX XXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXX XXXXXXXXX XXXXXXXXXXXX XXXXXXXXX XXXXXXXXXXXX XXXXXXXXX --------------------- XXXXXXXXXXXX XXXXXXXXX XXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXX XXXXXXXXX XXXXXXXXXXXX where the images are the XXXX blocks and the HR is the --- line. That is what I recall about the current HR hack - we are really treating it as an inline and getting the 'blockish' behaviour using :before and :after rules to insert carriage-returns (ach) - see quirk.css. All that said, if there are some real sites that need this, then we can prioritize the work. If it is just some testcases then the priority will remain low, but I will leave it opened anyway.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Priority: -- → P4
Target Milestone: --- → Future
Updated•23 years ago
|
Comment 7•22 years ago
|
||
Checked with Mozilla/5.0 (Windows; U; Win95; en-US; rv:0.9.9+) Gecko/20020320 Marc's illustration in additional comment '6' echoes the browser's behaviour regarding the 'HR' tag deployed alongside images/tables. Other browsers seem to avoid what Mozilla does here: Mozilla placing the horizontal rule the full width of the browser window, and *overlaying* a right or left-aligned table or image that gets in the way in the process. Removing the doctype declaration drops the HR so it clears the image ... Opera, IE, place the rule after the paragraph and stop it before the boundary of the image, which may well be the intention of the page originators. Apologies if this is old ground/wrong bug etc. This is a link to a simplified test case. http://www.users.zetnet.co.uk/leopold/mark/mozilla_test/hrsimplify3.html
Comment 9•21 years ago
|
||
WFM, both the testcase here and in duped bug 76132, 2003-10-31-05 trunk Linux. (I also verified clear:left and clear:right) I believe this was fixed by bug 38370. -> WORKSFORME
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 21 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•