Re: Setting the height of a BR element

For the sake of completeness and in the hope that it might make some
difference, I forward the collected correspondance on this subject.

BEGIN FORWARD:

Arjun Ray wrote:
In <ob1hbs0oeh9o6mpoab7dt81201cu4qc18q@4ax.com>,  
Jan Roland Eriksson <jrexon@newsguy.com> wrote:
| (David Baron) wrote:

| > What makes BR different from any other inline element?
| 
| Because it's a _line-break_command_ to a renderer. [...]  In fact BR
| does not even fit as a child element to anything, its not an element
| in its own right.

I agree.  BR should never have been specified as an element: look at
the absurdities of trying to *style* the thing just because it happens
to be in the element hierarchy!  

Rather, it should have been an entity reference, &br;.  Actually, the
specs could do that right now, by defining

  <!ENTITY  br  STARTTAG "br" >

But the point of the entity reference would be to encapsulate either
of two other definitions, much closer to the "true meaning":

(a) A processing instruction:  

  <!ENTITY br  PI  "system-specific line-break command" >

(b) A specific character data entity:

  <!ENTITY br  SDATA "[line-break]" >

These are just technical details; all that would matter is that the
user-agent grok &br; as "that which represents a line-break, either as
a signal or as a data sequence".  

Too late for that, though.  More kludgery.  -sigh-

--------------
I wrote:
David Baron <dbaron@is03.fas.harvard.edu> wrote in article
<slrn8bgt7c.1ek.dbaron@is03.fas.harvard.edu>...
> > David Baron <dbaron@is01.fas.harvard.edu> wrote in article
> > <slrn8bgbsq.p02.dbaron@is01.fas.harvard.edu>...
> > By the same argument, what makes a forced line break any different
from
> > a natural one? 
> 
> The line break is forced by the presence of an *element* that was not
> there in the case of a natural line break.

I understand the reasoning, but I feel that it is necessary to imply
(as it is necessary to imply other things into CSS) the <BR> as not
affecting the line box height argument (a view that was suggested in
CSS 1; whether the omission from CSS 2 was deliberate or not, I don't
know).

> > 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>
> 
> Those particular examples should appear the same, assuming the br
> element has the same font and line-height as the p element (and both
> the same as the pre, of course).

Yes. I omitted that. Sorry. 
> 
> > > 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>.
> 
> BR is an empty inline element.  If it's not listed as an exception,
> it's not an exception.  Otherwise anything could be CSS-compliant
> without following the specs.

That's not so. There _are_ exceptions to CSS that are made because they
are necessary. These do not make the browser incompliant. 

If the browser is simply gratuitously or negligently different, as with
table inheritance, it is incompliant.
 
> > 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
> 
> One can't really propose special treatment for the BR element, 
> since
> the CSS formatting model does not consider element names, 
> but only the
> properties given to elements through the cascade.  (CSS1 admitted
that
> the BR element was *outside* the CSS formatting model, but that's
> different.)  Possibilities include:
>   content: line-break;
>   display: line-break;
>   etc...
> One could then define which properties applied to elements with those
> values.

Display is a good idea, content is not, because different display types
can behave differently, whereas BR {display: inline; content:
line-break} is no different from BR {display: inline; content: "\A"},
BR {display: line-break} could behave differently from BR {display:
inline}.
---------------------------

This illustrates the danger of trying to map every HTML element to CSS. If
caution is not exercised the results tend to be highly artificial - in
CSS2 it is suggested that a line break be treated as BR:Before or :after;
in CSS3 it will doubtless be BR {content: "\A"}; in CSS1 it was stated
that it was outside CSS. Can it be said that CSS3 is a progression from
CSS1 in this respect? - I think not - just because something approacing
the behaviour of BR can be described using the available CSS properties,
it does not make it sensible to do so.

=====
----------------------------------------------------------
From Matthew Brealey (http://members.tripod.co.uk/lawnet (for law)or http://members.tripod.co.uk/lawnet/WEBFRAME.HTM (for CSS))
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

Received on Monday, 28 February 2000 12:04:15 UTC