W3C home > Mailing lists > Public > www-style@w3.org > February 2000

Re: Setting the height of a BR element using CSS

From: Matthew Brealey <thelawnet@yahoo.com>
Date: Sat, 26 Feb 2000 16:49:05 -0500 (EST)
Message-Id: <E12Op6k-0003Zp-00@area51.site5.com>
To: <www-style@w3.org>
NB . cross-posted to www-style and CIWAS.
David Baron <dbaron@is01.fas.harvard.edu> wrote in article
<slrn8bgbsq.p02.dbaron@is01.fas.harvard.edu>...
> > Because it is creating a line break, the <BR> does not have a
height -
> > it is just the same as a natural line break, caused by text
wrapping at
> > the right edge of the element (or left with right-to-left text),
and
> > therefore has no height. 
> 
> Why do you think that?  What makes BR different from any other inline
> element?

By the same argument, what makes a forced line break any different from
a natural one? 

Surely these should be equivalent:

<pre>
This is preformatted with a line break here:
that will not affect the height of the line box.
</pre>

<p>
This is not preformatted with a line break here:<br>
that should not affect the height of the line box.
</p>

> 
> According to the current spec, the 'line-height' property should
> probably influence the height of a BR element,

It isn't as specific as that. It says that empty inline elements are
considered for the purposes of line box height calculation. It doesn't
mention <br>.

> although it is unlikely
> to do so in any current browsers.  One interesting question is
whether
> it should influence the line box only on the line ended by the BR
> element, or on the next line as well.

Yes. I have pointed out the problems of treating <br> as a normal
element (namely confusing distortion of line box heights, disruption of
line box height calculations, the issue of whether it should be treated
as BR:before {content: \A} or BR:after, which lead to different
results, the artificial nature of trying to pigeonhole it into a CSS
concept, the fact that there is no need to allow the full range of CSS
properties on it, and above all the overwhelming sense that a forced
line break should not be any different from the natural one, etc.).
 
> I think it might be better if the BR element were defined as a
special
> class of element that just created a line-break, but CSS doesn't say
> that now.

I agree.

<proposal>
The BR element

The BR element, which creates a forced line break, should be treated in
the same manner as natural line breaks insofar as it should have no
effect on line box heights, and CSS properties have no effect upon it.
</proposal>

Arguably page-break-before and after should apply, but this leads to a
somewhat odd status for BR in that on the one hand it is not being
treated as a normal element, but instead as an instance of \A in
generated content, but on the other hand it is being treated as a
normal element in that (a limited subset of) CSS properties are being
allowed on it.

Note however, that it is not unique that HTML elements cannot be
described merely using a generic element and CSS. Indeed it is being
proposed that this continue into CSS 3 (this from the UI WD):

Since this proposal serves to simulate various user interface and forms
elements in HTML4, it is perhaps useful to call out what specifically
is believed to be outside the scope of CSS, or better suited to
document structure rather than style and therefore not addressed by
this proposal:
.... 
The file INPUT element.
The FIELDSET, LEGEND and ISINDEX elements.

Thus such acceptances (i.e., of the non-equivalence of and HTML and CSS
or indescribability of HTML in CSS) are not unprecedented (indeed
similar suggestions were recently made in respect of bidi by Nir
Dagan).

Incidentally, I'm not sure that LEGEND could be described in CSS.
For example, take this piece of code:
<fieldset>
<legend>
Search this site
</legend>
<input type="text">
</fieldset>

That cannot be described using CSS. It is necessary to insert an
additional element:
FIELDSET {z-index: -2; position: relative; padding-top: .5em; border:
solid 2px; display: block}
OUTERLEGEND {position: absolute; z-index: -1; top: -.5em; line-height:
1; left: 1%}
INNERLEGEND {background: white}

Thus this code recreates the HTML code above in Win IE 4 (with the
exception of the colour, which is a UI colour but doesn't seem to
correspond to any of the CSS on):
<div style="z-index: -2; position: relative; padding-top: .5em; border:
solid 2px>
<span style="position: absolute; z-index: -1; top: -.5em; line-height:
1; left: 1%">
<span style="background: white">
Search this site
</span>
<input type="text">
</div>

Note that it is impossible to do away with the inner SPAN and that the
background cannot be found by normal methods because it corresponds to
the topmost non-transparent background directly 'under' the LEGEND. 

In addition, IE appears to allocate an unsuppressable space above the
FIELDSET in which to place the LEGEND; for example:
<fieldset style="line-height: 0; padding: 0; margin: 0">
<input type="text">
</fieldset>
<fieldset style="line-height: 0; padding: 0; margin: 0">
<input type="text">
</fieldset>, which should (?) result in no space between the fieldsets
does not, because it allocates space for the LEGEND. Perhaps some kind
of standardization should be made.
Received on Monday, 28 February 2000 11:01:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:04 GMT