Closed
Bug 2590
Opened 26 years ago
Closed 24 years ago
<HR> and <BR> are unstylable!!!
Categories
(Core :: CSS Parsing and Computation, defect, P3)
Tracking
()
M18
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!
Updated•26 years ago
|
Assignee: peterl → harishd
Comment 1•26 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•26 years ago
|
||
Made HR more stylable. Check Feb 04 build.
Changing priority to P3 ( Since BR will be dealt later )
Reporter | ||
Comment 5•26 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.
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.
Redirecting the bug to kipp@netscape.com
Summary: <HR> and <BR> are unstylable!!! → {feature} <HR> and <BR> are unstylable!!!
Reporter | ||
Updated•26 years ago
|
Hardware: Other → PC
Reporter | ||
Comment 8•26 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•25 years ago
|
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...
Comment 10•25 years ago
|
||
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•25 years ago
|
||
Err, David... check my html->css mapping proposal (from April) again... :-)
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → REMIND
Target Milestone: M13 → M15
Comment 12•25 years ago
|
||
Let's discuss this after beta.
Reporter | ||
Updated•25 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•25 years ago
|
||
After beta would be LATER, not REMIND...
Reporter | ||
Updated•25 years ago
|
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: REMIND → LATER
Reporter | ||
Comment 14•25 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.
Comment 15•25 years ago
|
||
Final release is still this version of the product.
Reporter | ||
Updated•25 years ago
|
Status: RESOLVED → REOPENED
Reporter | ||
Comment 16•25 years ago
|
||
D'OH!
Reporter | ||
Updated•25 years ago
|
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: LATER → REMIND
Reporter | ||
Comment 17•25 years ago
|
||
Sorry Rick, I misread the resoltion descriptions. :-(
*shoots self*
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 18•25 years ago
|
||
Verified REMIND
Reporter | ||
Comment 19•25 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•25 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•25 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)
Comment 22•25 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).
Comment 23•25 years ago
|
||
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•25 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•25 years ago
|
||
CSS related...reassigning to pierre.
Assignee: harishd → pierre
Status: REOPENED → NEW
Comment 26•25 years ago
|
||
Moving crufty m14-m15 bugs out to m16 for proper triage.
Target Milestone: M15 → M16
Assignee | ||
Comment 27•24 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•24 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•24 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•24 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•24 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•24 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•24 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•24 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
Closed: 25 years ago → 24 years ago
Resolution: --- → DUPLICATE
Comment 35•24 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.
Description
•