Closed Bug 2590 Opened 26 years ago Closed 24 years ago

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

Categories

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

x86
Windows 95
defect

Tracking

()

VERIFIED DUPLICATE of bug 38370

People

(Reporter: ian, Assigned: pierre)

References

()

Details

(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
Status: NEW → ASSIGNED
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
Status: ASSIGNED → NEW
Redirecting the bug to kipp@netscape.com
Status: NEW → ASSIGNED
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: 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
Whiteboard: [TESTCASE]
Assignee: kipp → harishd
Status: ASSIGNED → NEW
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... :-)
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → REMIND
Target Milestone: M13 → M15
Let's discuss this after beta.
Blocks: html4.01
Status: RESOLVED → REOPENED
Summary: {feature} <HR> and <BR> are unstylable!!! → {feature} {css1} <HR> and <BR> are unstylable!!!
After beta would be LATER, not REMIND...
Status: REOPENED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: REMIND → LATER
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.
Status: RESOLVED → REOPENED
D'OH!
Status: REOPENED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: LATER → REMIND
Sorry Rick, I misread the resoltion descriptions. :-( *shoots self*
Status: RESOLVED → VERIFIED
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. 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.
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"?
Status: VERIFIED → REOPENED
Resolution: REMIND → ---
CSS related...reassigning to pierre.
Assignee: harishd → pierre
Status: REOPENED → NEW
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 harishd.
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.
Status: NEW → ASSIGNED
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 ***
Status: ASSIGNED → RESOLVED
Closed: 25 years ago24 years ago
Resolution: --- → DUPLICATE
No longer blocks: 22181
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.