190655 - render <hr> in prevailing text foreground color

Status: REOPENED

(Core :: Layout, defect, P5)

Description

[Jamie Zawinski]

I've always thought it was bogus that, in a block of text with non-default
foreground and background colors, <HR> always draws in gray.  If the background
isn't white, or close to white, this invariably looks like ass.  In fact, I've
totally gotten out of the habit of using <HR> for this reason and instead always do

    <P ALIGN=CENTER>_________________________</P>

which is pretty lame.

You ought to render HR in the prevailing text foreground color.  You already do
this for other items, e.g., the dots in a UL.


Also, MSIE apparently supports <HR COLOR="...">.  Mozilla does not.

Comment 1

[Ruslan Ismailov]

According to HTML 4.01 rules
(http://www.w3.org/TR/REC-html40/present/graphics.html#h-15.3) <hr> does not
have color attribute. Instead, you should use style="color: somevalue".

Comment 2

[Bernd]

Attachment: testcase

Comment 3

[Andrew Schultz]

Jamie: what build are you using?  the testcase works fine with linux trunk
20030125, and seems to have been fixed by Bernd's patch from bug 189723, which
this seems to be a dupe of.

Comment 4

[Jamie Zawinski]

I'm using Mozilla 1.2
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021203
on Red Hat 7.2.

Comment 5

[Bernd]

Jamie, while the build is pretty old, I believe you should be able to see the
changes at http://bugzilla.mozilla.org/attachment.cgi?id=111302&action=view .
You can also change the color of the hr to a uniform color by coloring the
border with border-color and change the style style away from inset ( which  is
the required default by html4.0) to solid. 

While I certainly see the point of using the text-color as the hr border-color I
fail to see how this could fit into a CSS2 compatible framework.
If you could provide any insight on this, it would be very helpfull. The main
disadvantage I see that it will break cross-browser compatibility. 
The main bug for the coloring of hr is bug 38370

Comment 6

[Andrew Schultz]

that's the bug I meant... I don't know how it came out 'bug 189723', which is a
completely irrelevant bug.

Comment 7

[Jamie Zawinski]

Attachment: gray HRs in green-on-black documents look bad

If I understand what the file at
http://bugzilla.mozilla.org/attachment.cgi?id=111302&action=view
is showing, it seems that HRs are rendered by drawing gradients
between the prevailing *background* color and "50% gray"?
Or something like that?

What I'm saying is that the color of an HR should be based on
the foreground color, not the background color.  Like letters,
HRs are foreground elements.  The current behavior seems to
be something along the lines of, "HR is always a gray translucent
block".  Or something.	It shouldn't be gray, it should be the
prevailing text color.

Comment 8

[Daniel Wang]

HR should inherit border color, not text color (not even msie does this)
-> wontfix

(see also bug 38370)

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Making it use 'border-color' would do this, since the default value of
'border-color' is to use the foreground text color.

I'd rather have this bug open and dependent on bug 38370, since it should be one
of the goals of bug 38370.

Comment 10

[Boris Zbarsky [:bzbarsky]]

So now bug 38370 is fixed... unfortunately, we still have a special border style
for <hr>s.  Should we eliminate this and just use the text color?  That should
be pretty simple -- just remove the "border: 1px -moz-bg-inset;" in html.css and
replace it with "border: 1px inset"...

Is that what we want to do, though?

Comment 11

[Hixie (not reading bugmail)]

I'm fine with doing this -- it would save us some code in nsCSSRendering since 
we could drop all our horrible MOZ_BG border styles (yay) (and yes, they are 
styles, not colours, go figure).

However, this would break parity with WinIE, Opera, and NS4.x, so it's not to be 
done lightly. Would it break any sites?

Comment 12

[Mats Palmgren (inactive)]

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

Comment 13

[Bill Mason]

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

Comment 14

[Brian Harvey]

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

Comment 15

[Hixie (not reading bugmail)]

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

Comment 16

[Michael O.]

Attachment: HR display testcase

Attaching a testcase to show that using "-moz-bg-inset" as the border-style for
HR elements causes breakage when attempting to change only the border-color of
the element.

Which means bug 38370 isn't really fixed for HR.

The only issue with changing "-moz-bg-inset" to "inset" is that the former uses
a shade of grey as the border-color and the latter uses black as the
border-color. This could be easily fixed by defining a shade of grey for the
border-color in html.css.

Comment 17

[Boris Zbarsky [:bzbarsky]]

It's not a shade of gray; it's a color dependent on the current background color
(hence the "bg" part).  We have a bug to scrap the bg-inset style and replace it
with a bg-something color and an inset border.

Comment 18

[Boris Zbarsky [:bzbarsky]]

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

Comment 19

[Bill Mason]

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

Comment 20

[Josh Birnbaum]

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

Comment 21

[j.j.]

Bug 253651, Bug 265924 and Bug 312772 are not duplicates of this, but where is the real one?

The other bugs are about styling like 
<hr style="color:red">, which does not work IE-like.

This is about matching the color of <hr> to the text color (when no other color styles are set to <hr>). 

Comment 22

[Anne (:annevk)]

Perhaps using 'border:1px inset currentColor' instead of what is defined now in <http://lxr.mozilla.org/seamonkey/source/layout/style/html.css#378>?

Comment 23

[Boris Zbarsky [:bzbarsky]]

The point is, if <hr> used the current color for the border, then setting the color on <hr> would make the border that color as well, "fixing" all the bugs in comment 21.  And that's the only way they're getting "fixed".  Hence them being marked duplicate.

Anne, the issue is compat.  If you want to make that change and then do some extensive testing to find out how many pages you break visually, please do so.

Comment 24

[Boris Zbarsky [:bzbarsky]]

And j.j., for future reference if I remove myself from the CC list of a bug that generally means I don't want to be on that cc list, mmmkay?

Comment 25

[j.j.]

Attachment: testcase hr { border: 1px inset }

hr { border: 1px inset } looks nice and useful, see testcase.

<hr style="color:..."> styles the border color, as a result <hr>s with size/height of 1 or 2px (or no size set) have the expected color (and this may be the most cases). 
Other than in IE there is a shade, but we need not copy all of IE. The noshade attribute should set border-style to solid. 

<hr> with size/height of 3px or more have a colorless background, but authors now may set background-color intuitively if they see the result.

Note: HTML attributes noshade, size and color don't work as before.

Comment 26

[j.j.]

(In reply to comment #25)
> Note: HTML attributes noshade, size and color don't work as before.

To be precise, 
<hr style="border:1px inset" color="red" size="5"> 
has a wrong height (size ignored when set together with color?) 

Comment 27

[dolphinling]

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

Comment 28

[fantasai]

The patch in bug 84307 should fix this.

Comment 30

[Gérard Talbot]

> the color of an HR should be based on
> the foreground color, not the background color.  Like letters,
> HRs are foreground elements.

<hr> is a block-level element (with no content, with empty content), not an inline-element:
http://www.w3.org/TR/2006/WD-CSS21-20061106/sample.html
Also stated in bug 38370 comment #c5
"Essentially, IE treats them [horizontal lines] as inline elements"
http://www.saila.com/usage/tips/defn.shtml?hr

Opera 9.10, Safari 2.0.4 and Konqueror 3.5.5 will colorize HRs according to background-color and/or according to border-color.

As soon as 1998, using CSS color as a way to colorize an <hr> was considered as a bug in IE5.x: see bug 4 in section M at

http://www.richinstyle.com/bugs/ie5demo.html

<hr> should behave just like an empty <div> which can have a distinct background-color (even background-image; IE supports background-image for <hr>) and (4) distinct border colors. Tests show this is how Mozilla, Safari, Konqueror and Opera already implements styling of <hr>.

If the hr element has to be an empty element and therefore can not have text, then it should ignore color except for cases when borders are defined without a border-color. E.g.
<hr style="color: red; padding: 10px; width: 400px; background-color: green; border: solid medium;">
will create a thick green <hr> with a surrounding solid red medium border.

I suggest resolving as INVALID

Comment 31

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The sample style sheet in CSS2.1 is just a sample, and is wrong in many ways.  Whatever Matthew Brealey thinks is a bug is irrelevant (and he wrote richinstyle.com considerably later than 1998, probably more like 2000 or 2001, IIRC).  Using border-color is actually quite reasonable, though, since the default value of border-color is the value of color, and it would mean setting either property should work.

Comment 32

[j.j.]

Opera 9.5 Alpha has changed the behaviour and fixed this.

Comment 33

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 8 duplicates.
:dholbert, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 34

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.