From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.1+) Gecko/20010608 BuildID: 2001060804 <hr> is drawn over the complete page. It looks fine in Opera 5.11 and IE 5.01 SP2. Reproducible: Always Steps to Reproduce: 1. Go to http://piology.org/IR/ 2. 3.

The table is a float. There are some similar bugs with floats. Confirming. -> Layout

This is standards mode only.

This looks like bug 18754. The fix for that was applied only to quirks mode and not (as you have found) in standards mode. This is the reasoning from buster@netscape.com: "This is a mess. HR is a block element. In Nav4 and IE5, however, it acts like an inline element when it is positioned next to a float. That is, it is sized and positioned taking full account of the floater geometry. This is in direct contradition to the CSS2 spec, which says block elements are laid out as if floaters did not exist. (someone could quote the spec here for me!) But, a ton of pages make use of this behavior." I don't know what a fix for this would be other than changing the spec (assuming buster@netscape.com's quote is correct) or using <hr style="display: inline"> to get pages to render as intended in standards mode. Perhaps this bug is invalid?

*** Bug 92030 has been marked as a duplicate of this bug. ***

*** Bug 94320 has been marked as a duplicate of this bug. ***

Is there any reason why the <hr> is not below the float rather than on top? To fix this "bug" <hr> needs to become something like <div><img style="width:99.7%;border:1px solid grey;padding-top:1px;"></div> width:99.7% should be width:100% but for some reason 100% causes the img to behave like a block box not a replaced inline box.

Not platform specific.

We shouldn't be changing standards mode to accomodate broken layout...

Christopher, what do you mean by broken? It is valid HTML. BTW: The original URL from the report changed and hence does no longer show the problem. The testcase still does, though. pi

*** Bug 110810 has been marked as a duplicate of this bug. ***

-->attinasi

*** Bug 94320 has been marked as a duplicate of this bug. ***

*** Bug 118375 has been marked as a duplicate of this bug. ***

*** Bug 114924 has been marked as a duplicate of this bug. ***

let me add some screen grabs so Marc can see what the issues are

The window was narrowed so the image and hr are on different lines

test page displayed in a widened window, causing the image and hr to render on the same line

The window was narrowed so the image and hr are on different lines

test page in IE6 with window widened so the image and hr are on the same line

The window was narrowed so the image and hr are on different lines

test page displayed in a widened window so the image and hr are on the same line

*** Bug 127400 has been marked as a duplicate of this bug. ***

Ian, what's the correct rendering here?

*** Bug 139455 has been marked as a duplicate of this bug. ***

*** Bug 142227 has been marked as a duplicate of this bug. ***

I think the optimistic/best solution would be to make web-designers care about HTML-Standards. Here especially how <hr> works. I saw this "rendering-error" on my own page. I did not know the reason of this problem and just found out a solution for it on this bug-tracking page by using <hr style="display: inline">. I guess that many web-designer are just not aware of the problem and what's the bigger problem don't know a solution. So maybe we could use a search-engine to find affected sites and inform webmasters of this problem automatically. At least we could write emails to webmasters of sites, where we (so manually) see this problem. Perhaps W3C could also do something about it, because they should encourage HTML-Standards.

Also validator.w3.org doesn't report this usage of <hr> as an error.

*** Bug 145089 has been marked as a duplicate of this bug. ***

Still happening (no crash, just double open) in Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0+) Gecko/20020530. Removing URL which uses the workaround. pi

*** Bug 152159 has been marked as a duplicate of this bug. ***

During the discusion on bug #142433 it has become clear that the claim made by buster@netscape.com is correct but not complete. It is correct that the HR elemnt is a block level element. However there is a difference between the box of a element, its rendering box, and the size (and position) of the rendered contents. From bug #142433: >><!ELEMENT HR - O EMPTY -- horizontal rule --> >><!ATTLIST HR %attrs; -- %coreattrs, %i18n, %events --> >>Start tag: required, End tag: forbidden >>Attribute definitions >>align = left|center|right [CI] >> Deprecated. This attribute specifies the horizontal alignment of the rule >>with respect to the surrounding context. Possible values: >> * left: the rule is rendered flush left. >> * center: the rule is centered. >> * right: the rule is rendered flush right. >> The default is align=center. > >As described in the HTML specs the rendered content should be >handled the same as i.e. the H1 element. Both HR and H1 are describable using >CSS2. But both need extra layout processing within their CSS boxes. Just as like >a H1 has a left and a width the HR has. A little ascii art: > >****************-----------------+ >* * Heading text | >+--------------*-----------------+ >* Floating obj * Paragraph text | >* * | >* * | >* * | >+--------------*-----------------+ >* * =============== | >+--------------*-----------------+ >* * Paragraph text | >**************** | >| Paragraph continues here | >+--------------------------------+ > >The _box_ surrounded by the *s is of the floating div element >The _box_es surrounded by the -s are of the headings the paragraphs >and the rule. With the ===== as the rule it two lines following >the definetion of the HTML specification for the rendering and >the CSS specs for layout. Therefore both in stands mode and quirks mode the rendering of the HR element should be corrected. 1. The HR element is block level 2. The box around the equals the whole width of the page 3. The rendered contents equals the whole page width (because of border, padding and margin are 0) 4. The rendered lines of the HR should (read must) take surrounding elements in respect by flowing around them. i.e. the left and width of the lines needs more processing then just taking them from the rendered contents area as described in the CSS2 specs section 8 'the box model' Just as done with paragraph text and for instance the H1 element.

Re comment 32: " However there is a difference between the box of a element, its rendering box, and the size (and position) of the rendered contents." This is quite true, except it begs the question: what is an 'hr' element? I mean, really? Here's one way to get the default 'hr' appearance from Mosaic 1.0 and other browsers of that era: hr {display: block; height: 0; border: 1px inset silver;} In that case, what Mozilla is doing with regards to floats is exactly correct, because the 'hr' is nothing but borders on a block-level element, and those borders should "slide under" the float. If you dig into Mozilla's 'html.css', you find the following rule: hr { display: block; border: 1px -moz-bg-inset; margin: 0 auto 0 auto; } ...so what Mozilla is doing is correct, provided that this is the correct way to create 'hr' elements. So I turned to CSS2, appendix A, and found the following two rules: HR, MENU, PRE { display: block } HR { border: 1px inset } So according to the sample stylesheet the W3C published, Mozilla's rendering of 'hr' elements is correct-- at the very least, consistent with the suggestoin made by the CSS2 specification. If you feel that the visible portions of an 'hr' should instead be rendered content within the block, then how do you propose it be described in CSS? If there is a way to do so, then the Mozilla team could consider describing it that way, even if just in quirks mode, and thus resolve the problem you're seeing. This can be done without fear of "violating standards," as the sample stylesheet I quote isn't normative, and so does not have to be obeyed. But to do so, we need a way to describe 'hr' elements the way you want, where the visible portions are rendered content and not borders on the element box. I wan't able to think of one, but that doesn't mean such a method doesn't exist. Ideas?

Apendix A is indeed informative and should not be leading. CSS 1/2 doesn't provide the means to describe the needed rendering, its beyond its scope. See if you can find the reason why the text in a paragraph, or a H1 element is not aligned with the left margin of its box. Both for the paragraph text, the heading elements and the horizontal rule elements the HTML specs tells to respect the elements around it. By the way nothing says that the HR element cannot be defined by using the borders as long as the border is hidden for the parts obscuring the aurrounding elements. Other browsers like IE and Opera do it this way. and it does not conflict with either HTML or CSS specs. The added testcase also reveals a problem with the margin property causing a even more incorrect rendering. I don't know about the 6 pixel wide borders not being drawn. But I think they should be drawn.

CSS3 will handle <hr>s using the float-displace property (or whatever we ended up calling it, I forget).

The "fact" that the compatibile rendering of HR can't be described in CSS is: 1. a deficiency of CSS, and 2. a silly reason to break pages in a way that makes little sense to authors and has no benefits (who *wants* HR to cross floats?). I called it a "fact" rather than a fact because our quirks mode rendering of HR is also described in CSS: hr { display: inline; -moz-box-sizing: border-box; border: 1px -moz-bg-inset; margin: 0 0.1% 0 0.1%; /* Mmm! Hack-on-a-hack for bug 81776 */ font-size: -moz-initial !important; } hr:before { white-space: pre; content: "\A"; } hr:after { white-space: pre; content: "\A"; }

>I called it a "fact" rather than a fact because our quirks mode >rendering of HR is also described in CSS: Better call it "because in quirks mode the HR element is described using a self defined non-sandard extention to CSS." The "hr:before" and "hr:after" can pose a problem when a author chooses to use these attributes for some reason. Better use a "-moz" in front of the properties to prevent this.

:before and :after aren't properties, and they aren't non-standard extensions. It may be that other browsers don't support them yet, but they're still standard.

>:before and :after aren't properties, and they aren't non-standard >extensions. I ment the properties within the :before and :after.

http://www.w3.org/TR/REC-CSS1#white-space http://www.w3.org/TR/REC-CSS2/text.html#white-space-prop http://www.w3.org/TR/REC-CSS2/generate.html#content

To be even more clear: I ment: Better call it "because in quirks mode the HR element is described using the following self defined non-sandard extention to CSS." -moz-box-sizing: border-box; border: 1px -moz-bg-inset; font-size: -moz-initial !important; The follwing can/could pose a problem when a author chooses to use these attributes for some reason. Better use a "-moz" in front of the properties to prevent this. (But only if it is completly nescesary for the correct rendering.) hr:before { white-space: pre; content: "\A"; } hr:after { white-space: pre; content: "\A"; } Declaring a HR element inline is not correct following HTML specs and following the example in apendix A of CSS2. display: inline;

It has nothing to do with HTML (%block and %inline are basically unrelated) and Appendix A of CSS2 is just wrong.

>It has nothing to do with HTML (%block and %inline are basically >unrelated) and Appendix A of CSS2 is just wrong. Better read section HTML specs 7.5.3 again: |Style sheets provide the means to specify the rendering of arbitrary |elements, including whether an element is rendered as block or inline. |In some cases, such as an inline style for list elements, this may be | appropriate, but generally speaking, authors are discouraged from |overriding the conventional interpretation of HTML elements in this way. And from section 21 html specs: |<!--================== HTML content models ===============================--> |<!-- | HTML has two basic content models: | %inline; character level elements and text strings | %block; block-like elements e.g. paragraphs and lists |--> |<!ENTITY % block | "P | %heading; | %list; | %preformatted; | DL | DIV | NOSCRIPT | | BLOCKQUOTE | FORM | HR | TABLE | FIELDSET | ADDRESS"> |<!ENTITY % flow "%block; | %inline;"> If you find this incorrect -- wrong is definetly a word choosen badly in context of standards, norms, and recommendation -- please contact Dave Raggett and Bert Bos about the matter to have an errata added to the html and css specs. Their email addresses are: dsr@w3.org and bert@w3.org But you've probably already lookup their email addresses to report this.

HR is between inline and block. HTML classifies it as %block;, since the parts that are more relevant to that classification are more block-like. However, it's not fully block-like with regard to floats.

>HR is between inline and block. HTML classifies it as %block;, >since the parts that are more relevant to that classification are more >block-like. However, it's not fully block-like with regard to floats. I 100$ agree with that hence the mention of that a HR should respect its surrounding contents for its horizontal alignment in section 15.3. And not to forget section 15.1.3 to exist. Which tells us that for a lot of elements a float alters its behaviour in the sence that they flow around floats. Just as its done with the P, H1, H2, etc elements.

*** Bug 169225 has been marked as a duplicate of this bug. ***

*** Bug 174430 has been marked as a duplicate of this bug. ***

*** Bug 183674 has been marked as a duplicate of this bug. ***

*** Bug 136416 has been marked as a duplicate of this bug. ***

*** Bug 96293 has been marked as a duplicate of this bug. ***

-> Layout: Floats

*** Bug 205038 has been marked as a duplicate of this bug. ***

*** Bug 208643 has been marked as a duplicate of this bug. ***

*** Bug 209438 has been marked as a duplicate of this bug. ***

The patch in bug 38370 fixes this.

*** Bug 218309 has been marked as a duplicate of this bug. ***

Fixed by bug 38370.

*** Bug 229829 has been marked as a duplicate of this bug. ***