2590 - <HR> and <BR> are unstylable!!!

Status: VERIFIED DUPLICATE of bug 38370

(Core :: CSS Parsing and Computation, defect, P3)

Description

[Hixie (not reading bugmail)]

The <HR> and <BR> elements are currently being treated as special cases.
The should not be. They are normal elements, just like any other.

The test case quoted attempts to give style to these two elements, but
NGLayout generally fails to render the styles.

I suggest you turn HR and BR into normal elements, just like DIV or EM, and
then add the following styles to ua.css:

   HR { height: 1px; width: 100%; border-style: inset; border-width: 1px; }
   BR:before { content: "\A"; }

This will result in HR elements that look identical to the current HRs, but
that in addition *use the colour of the parent element*. This is because the
border-color property, since it is not set, would use the inherited value
of the color property.

Also, BR elements would act just like now (assuming you support the CSS2
:before pseudo-element and the CSS2 content property).

All this should make your life a lot easier, as well as making us CSS authors
happy and cheerful!

Comment 1

[Peter Linss]

Please fix HR rendering like we discussed before.
We can't do BR now since we don't (yet) support :before or 'content'.

Comment 2

[Hixie (not reading bugmail)]

Note: The following would also be completely or partially fixed with
support for :before, :after and content:

 Bug #1061 - the Q element's quotes
 Bug #1233 - BR margins (closely related to this one)
 Comment in #2742 - displaying LINK element's attributes

Comment 3

[leger]

Setting all current Open/Normal to M4.

Comment 4

[harishd]

Made HR more stylable.  Check Feb 04 build.
Changing priority to P3 ( Since BR will be dealt later )

Comment 5

[Hixie (not reading bugmail)]

You still almost totally fail this test. (Tested with feb05 build.)

Note that fixing this should be extremely easy as it merely means making
the HR element equivalent to the DIV element w.r.t. styling! There is no
reason to special-case the HR element.

Comment 6

[kipp]

i did some work today to make HR mostly styleable. It now honors margins and
height (it already did width). The font-size determines the "height" of the hr
while the "height" property determines the height of the rendered portion (ain't
compatability great). And we now take up space for borders/paddings.

I didn't do a thing for BR though.

Comment 7

[harishd]

Redirecting the bug to [e-mail]

Comment 8

[Hixie (not reading bugmail)]

Generated content is arriving, so BR can soon be fixed 'properly'. Also,
with Peter's new '-moz-border-radius' property, you will even be able to do
nav4-compatible HRs in an almost spec-compliant way.

Here is a summary of possible ways of implementing these two elements in a
spec compliant way, while keeping full backwards compatibility:

  == BR ==
Simply define BR as...

   BR:before { display: inline; content: "\A"; }

...and then treat BRs the same way as empty DIVs. Kipp and I discussed how
BRs affect the lines they are in, and I drew some diagrams which I will insert
here too:

   abc<br><br><br>def

...renders as:

   +---------------------------------------+
   | +-------+ +                           |
   | | a b c | |                           |
   | +-------+ +                           |
   | +                                     |
   | |                                     |
   | +                                     |
   | +                                     |
   | |                                     |
   | +                                     |
   | +-------+                             |
   | | d e f |                             |
   | +-------+                             |
   +---------------------------------------+

(where the lines are construction lines, only designed to show where
the boxes are.)

Also:

   <img><br>def

...renders as

   +---------------------------------------+
   | +------------+                        |
   | | IMG with   |                        |
   | | v-align    |                        |
   | | bottom     |                        |
   | | and inline | +                      |
   | | display    | |                      |
   | +------------+ +                      |
   | +-------+                             |
   | | d e f |                             |
   | +-------+                             |
   +---------------------------------------+


Related pages:
 http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/br.html
 http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/hrbrstyles.html
 bug #4247
 bug #4248


  == HR ==
This is more complicated, because the attributes do not map directly onto
the CSS model. Again, the HR can be treated as an empty primitive element,
except that some attribute mapping must be performed. For each attribute, here
is the mapping I would recommend:

   /* default ua.css */
   hr { border-style: 1px -moz-bg-inset; margin: auto; display: block; }

   /* noshade */
   #thishr { -moz-border-radius: 100%; border: none;
             background: -moz-shade-bg; }

   /* align=left */
   #thishr { margin-left: 0; margin-right: auto; }

   /* align=right */
   #thishr { margin-left: auto; margin-right: 0; }

   /* align=center */
   #thishr { margin-left: auto; margin-right: auto; }

   /* size */
   #thishr { height: <value of size attribute>; }

   /* width */
   #thishr { width: <value of width attribute>; }

   /* color */
   #thishr { color: <value of color attribute>;
             background: <value of color attribute>; }

The following mozilla specific keywords apply:

-moz-bg-inset (<border-style> keyword)
   Already implemented. Emulates nav4's 3D border style for HRs (whatever
   that is).

-moz-border-radius (new property)
   Nearly implemented. Should cause background and borders to be rounded
   (ask Peter Linss for more details).

-moz-shade-bg (suggested <color> value for 'background' property)
   Should emulate the nav4 colour selection code for noshade style HRs,
   whatever that is.

Note that since HR is a block-level element, the font-size will not have
any effect on rendering.

Related pages:
 http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/hr.html
 http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/hrbrstyles.html

Comment 9

[kipp]

Harish - can you make sure HR's act as described in here in terms of supporting
the obvious css properties and once you have that working reassign the bug back
to me for the BR problems. No hurry...

Comment 10

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

There have been requests (for 4.x Parity) to support the COLOR attribute of the
HR element.  Should this map to color or border-color?

Comment 11

[Hixie (not reading bugmail)]

Err, David... check my html->css mapping proposal (from April) again... :-)

Comment 12

[rickg]

Let's discuss this after beta.

Comment 13

[Hixie (not reading bugmail)]

After beta would be LATER, not REMIND...

Comment 14

[Hixie (not reading bugmail)]

From http://bugzilla.mozilla.org/bug_status.html :
: LATER
:    The problem described is a bug which will not be fixed in this version of
:    the product.
: REMIND
:    The problem described is a bug which will probably not be fixed in this
:    version of the product, but might still be.

Comment 15

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

Final release is still this version of the product.

Comment 16

[Hixie (not reading bugmail)]

D'OH!

Comment 17

[Hixie (not reading bugmail)]

Sorry Rick, I misread the resoltion descriptions. :-(

*shoots self*

Comment 18

[Christine Hoffman]

Verified REMIND

Comment 19

[Hixie (not reading bugmail)]

Migrating from {css1} to css1 keyword. The {css1}, {css2}, {css3} and {css-moz}
radars should now be considered deprecated in favour of keywords.
I am *really* sorry about the spam...

Comment 20

[Matthew Brealey]

The BR suggestion is totally invalid (clear doesn't apply to inline elements, 
which the proposal suggests that they are; it screws up line box heights, etc.), 
and the HR suggestion is slightly dubious.

BR needs to be treated as a 'display: line-break' type, and treated in the same 
way as an ordinary line break.

Also   
   hr { border-style: 1px -moz-bg-inset; margin: auto; display: block; }
is invalid CSS - should be border: 1px -moz-bg-inset.

There is, however, a bug - Mozilla should use UI colours to set the colour of 
HR; if Mozilla peristss, as at present, with describing HR as a border, it 
should support it correctly.

Comment 21

[Hixie (not reading bugmail)]

The above comments by Matthew Brealey are (apart from the mention of the border-
style typo) misguided at best and wildly incorrect at worst. My comments dated
1999-04-06 stand.

Comment 22

[Charles Manske]

Note that we need to use generated content (a character as an "after" value)
to show paragraph marks for Composer. Unfortunately, we must use <br> for
paragraph delimiter for Mail Composer (and maybe even for regular Composer
for 6.0), so we need CSS support for at least "after" (see bug 22181).

Comment 23

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

I'm not sure that :after is really what you want (although it would probably
work).  :before and :after are really somewhat misnamed - they create generated
first/last children of an element, not siblings.

Comment 24

[Charles Manske]

Now that I think more about it, I guess "before" is what we need.
If you have a line of text, then <br>, we want the paragraph symbol "\160"
to appear at the end of that line.
Either way, we need this bug fixed, so why is it "VERIFIED REMIND"?

Comment 25

[harishd]

CSS related...reassigning to pierre.

Comment 26

[rickg]

Moving crufty m14-m15 bugs out to m16 for proper triage.

Comment 27

[Pierre Saslawsky]

Sorry, Harish. If I'm correct this is a problem with the rendering of these 
elements in Layout, not a problem with the style attached to them. Reassigned to 
harishd.

Comment 28

[harishd]

Rick, I'm not sure to whom this bug should go to. Could you please dispatch it 
to the right owner?  Thanx

Comment 29

[rickg]

Hold on pierre; this sounds like a perfect use for :before or :after. Why are 
you claiming that this is not a style issue? Charles wants to place this content 
in the model himself (using style). It's not data that layout would generate.

In case I'm missing something -- please explain.

Comment 30

[Pierre Saslawsky]

The bug was originally about giving any kind of style to HR and BR (not just the 
:before and :after pseudo-elements) and the rendering belongs to Layout. Now, if 
we want the pseudo-elements first, I agree that it needs to be done in Style.

Comment 31

[Pierre Saslawsky]

Bug 38370 has been filed on the same topic so I'm going to keep the present bug 
to look into the pseudo-elements and reassign the new one to buster to cover the 
rendering in Layout.

Comment 32

[Hixie (not reading bugmail)]

Pierre: You shouldn't have to do anything. Once buster fixes bug 38370, HR and 
BR should be straightforward elements like DIV (except that HR will have to be
DIV with some slight extensions), and so they should already get :before and
:after elements automatically.

See my last comment on bug 38370 to see what I mean.

Comment 33

[Pierre Saslawsky]

Ian- I suspected I didn't have anything to do in Style but I still wanted to 
understand what made HR special and why the content wasn't created for :before/
:after. I agree with your proposal: if we want HRs to be fully stylable, they 
have to be considered as empty DIVs.

Since you moved your comments to 38370, I guess I can take my time to satisfy my 
curiosity and close this bug as dup when I'm done. Thanks!

Comment 34

[Pierre Saslawsky]

Well, I won't satisfy my curiosity this time. Closed as dup of 38370.


*** This bug has been marked as a duplicate of 38370 ***

Comment 35

[Katcha Da]

Verified that this is a duplicate of bug 38370 and marking as such.