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

VERIFIED DUPLICATE of bug 38370

Status

()

defect
P3
normal
VERIFIED DUPLICATE of bug 38370
21 years ago
19 years ago

People

(Reporter: ian, Assigned: pierre)

Tracking

({css1, testcase})

Trunk
x86
Windows 95
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

21 years ago
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!

Updated

21 years ago
Assignee: peterl → harishd

Comment 1

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

Comment 2

21 years ago
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

Updated

21 years ago
Status: NEW → ASSIGNED

Comment 3

21 years ago
Setting all current Open/Normal to M4.

Updated

21 years ago
Priority: P2 → P3

Comment 4

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

Comment 5

21 years ago
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

20 years ago
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.

Updated

20 years ago
Assignee: harishd → kipp
Status: ASSIGNED → NEW

Comment 7

20 years ago
Redirecting the bug to kipp@netscape.com

Updated

20 years ago
Status: NEW → ASSIGNED

Updated

20 years ago
Severity: normal → trivial

Updated

20 years ago
Severity: trivial → enhancement
Priority: P3 → P5

Updated

20 years ago
Summary: <HR> and <BR> are unstylable!!! → {feature} <HR> and <BR> are unstylable!!!
(Reporter)

Updated

20 years ago
Hardware: Other → PC
(Reporter)

Comment 8

20 years ago
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

Updated

20 years ago
Assignee: kipp → harishd
Status: ASSIGNED → NEW
Target Milestone: M17 → M20

Comment 9

20 years ago
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?
(Reporter)

Comment 11

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

Updated

20 years ago
Status: NEW → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → REMIND
Target Milestone: M13 → M15

Comment 12

20 years ago
Let's discuss this after beta.
(Reporter)

Updated

20 years ago
Blocks: html4.01
Status: RESOLVED → REOPENED
Summary: {feature} <HR> and <BR> are unstylable!!! → {feature} {css1} <HR> and <BR> are unstylable!!!
(Reporter)

Comment 13

20 years ago
After beta would be LATER, not REMIND...
(Reporter)

Updated

20 years ago
Status: REOPENED → RESOLVED
Last Resolved: 20 years ago20 years ago
Resolution: REMIND → LATER
(Reporter)

Comment 14

20 years ago
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.
Final release is still this version of the product.
(Reporter)

Updated

20 years ago
Status: RESOLVED → REOPENED
(Reporter)

Comment 16

20 years ago
D'OH!
(Reporter)

Updated

20 years ago
Status: REOPENED → RESOLVED
Last Resolved: 20 years ago20 years ago
Resolution: LATER → REMIND
(Reporter)

Comment 17

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

*shoots self*

Updated

20 years ago
Status: RESOLVED → VERIFIED

Comment 18

20 years ago
Verified REMIND
(Reporter)

Updated

20 years ago
Keywords: css1
(Reporter)

Comment 19

20 years ago
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

19 years ago
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.
(Reporter)

Comment 21

19 years ago
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)
(Reporter)

Updated

19 years ago
Blocks: 22181

Comment 22

19 years ago
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.

Comment 24

19 years ago
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"?
Status: VERIFIED → REOPENED
Resolution: REMIND → ---

Comment 25

19 years ago
CSS related...reassigning to pierre.
Assignee: harishd → pierre
Status: REOPENED → NEW

Comment 26

19 years ago
Moving crufty m14-m15 bugs out to m16 for proper triage.
Target Milestone: M15 → M16
(Assignee)

Comment 27

19 years ago
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.
Assignee: pierre → harishd

Comment 28

19 years ago
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

Comment 29

19 years ago
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
(Assignee)

Comment 30

19 years ago
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.
Status: NEW → ASSIGNED
Target Milestone: M16 → M18
(Assignee)

Comment 31

19 years ago
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.
(Reporter)

Comment 32

19 years ago
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)
(Assignee)

Comment 33

19 years ago
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!
(Assignee)

Comment 34

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


*** This bug has been marked as a duplicate of 38370 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 20 years ago19 years ago
Resolution: --- → DUPLICATE

Updated

19 years ago
No longer blocks: 22181

Comment 35

19 years ago
Verified that this is a duplicate of bug 38370 and marking as such.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.