Closed Bug 2590 Opened 22 years ago Closed 21 years ago

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


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

Windows 95





(Reporter: ian, Assigned: pierre)




(Keywords: css1, testcase)

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!
Assignee: peterl → harishd
Please fix HR rendering like we discussed before.
We can't do BR now since we don't (yet) support :before or 'content'.
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
Setting all current Open/Normal to M4.
Priority: P2 → P3
Made HR more stylable.  Check Feb 04 build.
Changing priority to P3 ( Since BR will be dealt later )
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.
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.
Assignee: harishd → kipp
Redirecting the bug to
Severity: normal → trivial
Severity: trivial → enhancement
Priority: P3 → P5
Summary: <HR> and <BR> are unstylable!!! → {feature} <HR> and <BR> are unstylable!!!
Hardware: Other → PC
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:


...renders as:

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

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



...renders as

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

Related pages:
 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:
Whiteboard: [TESTCASE]
Assignee: kipp → harishd
Target Milestone: M17 → M20
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...
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?
Err, David... check my html->css mapping proposal (from April) again... :-)
Closed: 21 years ago
Resolution: --- → REMIND
Target Milestone: M13 → M15
Let's discuss this after beta.
Blocks: html4.01
Summary: {feature} <HR> and <BR> are unstylable!!! → {feature} {css1} <HR> and <BR> are unstylable!!!
After beta would be LATER, not REMIND...
Closed: 21 years ago21 years ago
Resolution: REMIND → LATER
From :
:    The problem described is a bug which will not be fixed in this version of
:    the product.
:    The problem described is a bug which will probably not be fixed in this
:    version of the product, but might still be.
Final release is still this version of the product.
Closed: 21 years ago21 years ago
Resolution: LATER → REMIND
Sorry Rick, I misread the resoltion descriptions. :-(

*shoots self*
Verified REMIND
Keywords: css1
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...
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.

   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.
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.
Summary: {feature} {css1} <HR> and <BR> are unstylable!!! → <HR> and <BR> are unstylable!!!
Whiteboard: [TESTCASE] → [TESTCASE] (will reopen after beta1)
Blocks: 22181
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).
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.
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"?
Resolution: REMIND → ---
CSS related...reassigning to pierre.
Assignee: harishd → pierre
Moving crufty m14-m15 bugs out to m16 for proper triage.
Target Milestone: M15 → M16
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 
Assignee: pierre → harishd
Rick, I'm not sure to whom this bug should go to. Could you please dispatch it 
to the right owner?  Thanx
Assignee: harishd → 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.
Assignee: rickg → pierre
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.
Target Milestone: M16 → M18
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.
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.
Keywords: testcase
Whiteboard: [TESTCASE] (will reopen after beta1)
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!
Well, I won't satisfy my curiosity this time. Closed as dup of 38370.

*** This bug has been marked as a duplicate of 38370 ***
Closed: 21 years ago21 years ago
Resolution: --- → DUPLICATE
No longer blocks: 22181
Verified that this is a duplicate of bug 38370 and marking as such.
You need to log in before you can comment on or make changes to this bug.