Closed Bug 84887 Opened 19 years ago Closed 16 years ago

<hr> is drawn over float in standards mode

Categories

(Core :: Layout: Floats, defect, major)

defect
Not set
major

Tracking

()

RESOLVED FIXED
Future

People

(Reporter: holgermetzger, Unassigned)

References

Details

(Keywords: compat, testcase)

Attachments

(8 files)

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
Assignee: asa → karnaze
Status: UNCONFIRMED → NEW
Component: Browser-General → Layout
Ever confirmed: true
QA Contact: doronr → petersen
Summary: <hr> is drawn over complete page → [FLOAT] <hr> is drawn over complete page
Attached file testcase
This is standards mode only.
Summary: [FLOAT] <hr> is drawn over complete page → [FLOAT] <hr> is drawn over complete page in standards mode
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.
OS: Windows 98 → All
Hardware: PC → All
We shouldn't be changing standards mode to accomodate broken layout...
Keywords: compat, testcase
Whiteboard: WONTFIX?
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
Assignee: karnaze → attinasi
*** Bug 94320 has been marked as a duplicate of this bug. ***
*** Bug 118375 has been marked as a duplicate of this bug. ***
Target Milestone: --- → Future
*** 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
Attached image test page in mozilla
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
Attached image test page in IE6
The window was narrowed so the image and hr are on different lines
Attached image test page in IE6 (2)
test page in IE6 with window widened so the image and hr are on the same line
Attached image test page in Opera6
The window was narrowed so the image and hr are on different lines
Attached image test page in Opera6 (2)
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?
Keywords: qawanted
*** 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. ***
Severity: normal → major
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.
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
Assignee: attinasi → float
Component: Layout → Layout: Floats
QA Contact: cpetersen0953 → ian
Summary: [FLOAT] <hr> is drawn over complete page in standards mode → <hr> is drawn over complete page in standards mode
*** Bug 205038 has been marked as a duplicate of this bug. ***
*** Bug 208643 has been marked as a duplicate of this bug. ***
Summary: <hr> is drawn over complete page in standards mode → <hr> is drawn over float in standards mode
Whiteboard: WONTFIX?
*** Bug 209438 has been marked as a duplicate of this bug. ***
The patch in bug 38370 fixes this.
Depends on: 38370
*** Bug 218309 has been marked as a duplicate of this bug. ***
Fixed by bug 38370.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
*** Bug 229829 has been marked as a duplicate of this bug. ***
Blocks: 56362
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.