Re: Inline h*ll

--- "L. David Baron" <dbaron@fas.harvard.edu> wrote:
> On Fri, 14 Jan 2000 02:40:59 -0800 (PST),
> =?iso-8859-1?q?Matthew=20Brealey?= (thelawnet@yahoo.com) wrote:
> > 
> > --- Ian Hickson <py8ieh@bath.ac.uk> wrote:
> 
> > > However, previous
> > > proposals from both David Baron and myself have suggested that to
> make
> > > line-height work well for blocks, an anonymous inline should wrap
> all
> > > blocks' contents. This would result in the same effect as with the
> > > empty inline BR in the previous example, and is what both Opera 4
> and
> > > Mozilla 5 have implemented.
> >  
> > If you are wanting to browsers to diverge from the published
> > specification, far better would be to encourage them to follow a
> sensible
> > line box proposal in the first place.
> > 
> > As I see it, there is nothing that is useful in the current float
> > specification, and a whole lot that is very bad. It is illogical,
> > confusing and almost without any merit whatsoever.
> 
> The best reason to do anonymous inline boxes the way I suggest is
> that it prevents non-presentational markup from having side-effects
> in unexpected ways.  

A very good reason _not_ to do it in the way that you suggest (well not
the way you suggest in particular, but any line box implementation that
follows the spec) is that is impossible to predict the size of the line
box.

For example,
P {line-height: 10px; font-size: 100px}
SPAN {font-size: 10px; line-height: 14px}

<p>
The <span>text</span>
</p>
   ----|--- 
       |    | 
       |    |     
-------|----|-----|---|      
|      |    |---| |   |      
-------|----|---| |---|
       |    |   | |   |------|
       |    |   | |---| text |
                      -------|

The theoretical bottom of the outer text is (10-100)/2
= 45px below the bottom of its box. It baseline is 
therefore 45px - Bp below.
The SPAN's baseline is aligned with its baseline.
Therefore the bottom
of its box is 45px - Bp + SPAN's half-leading + Bspan
I.e., the bottom of the SPAN box is 45px+(14-10)/2 + Bspan-
Bp = 47px + Bspan - Bp.

As a result, from the bottom of the lowest box to the top
of the highest (=line box height)
is 10px + 47px + Bspan - Bp.
Without information on what Bspan and Bp are, we can only
say that the line box is 57px +- x, where x is totally unknown.

This demsonstrates another absurdity of the spec.

> According to your interpretation of the
> current spec, the following markup (with lines broken where shown):
> 
> Some text and
> <big style="font-size: 200%">some bigger text</big>
> in a paragraph.
> 
> would be rendered differently whether it was directly enclosed within a
> p element with line-height: 120% or if it was entirely enclosed in a
> (completely unstyled) span element within that p.

Indeed; however, I'm trying to point out that if (as you suggest) we are
to ignore the spec, we should at least ignore it for a sensible
alternative. If you do insist on following something resembling the spec,
your suggestion is a good one, but the point is that it is a CHANGE.

> 
> > Under my proposal, the enormous advanatage of having line box height
> set
> > by line-height [wow! whatever next? - box heights being set by
> height?]
> > exists.
> > Under it, you would be able to say with confidence that the line box
> is
> > the height of max(line-height, height). 
> 
> > It is also far more intuitive, and I cannot see any area in which the
> > existing spec is better.
> 
> If line-height of a block sets the line-box height (which is what you
> seem to be saying), then the following examples of commonly found
> markup (and their CSS equivalents) would be a mess:

No, no.

The height of a line box is equal to max(line-height, height) in that
block - no concept of inline boxes with a height is needed.
E.g.,  
P {line-height: 10px; font-size: 100px}
SPAN {font-size: 10px; line-height: 14px}

results in a 14px high line box.

Another reason that this approach is better is that it associates
backgrounds with the line box rather than the text.

For example:

P {line-height: 1.2}
SPAN.insideP {background: green}
BIG {background: red;
font-size: 1.2em}
<p>
<span>Content</span><big>Content</big>
At CSS 2, this would make the backgrounds look stupid (since the BIG box
is 1.2 times as big as the anonymous P content), whereas
with my proposal, the background would color the line box - pure and
simple.

Thus such absurdities are avoided - when someone looks at a page, they
don't think 'Ah, that bigger text has a bigger box, therefore its
background doesn't line up', instead they think 'There's some bigger text
in that line' - any conception of inline boxes is a highly artificial and
damaging one.
> 
> <p><font size="7">Text ...</font></p>
> 
> <p>Lots of text with some <font size="7">big text</font> in the
> middle.</p>
> 
> The line box height of the paragraph would be much smaller than the
> font size, even if the line-height were a scaling factor, so the text
> would overlap.  There would be no way to make only the line with big
> text be bigger (which is what should normally happen).  That's
> ridiculous.

See above - line heights of inline elements _are_ used, however, tyhe
concept of inline box heights is not. 
E.g., P {line-height: 1.2; font-size: 10px} FONT[size=7] {font-size: 2em}
This would give the FONT a line-height of 24px - this would be the size of
line boxes that it is in. E.g.,
<P>
<linebox>
Anonymous content <font size=7>bigger content</font>
</linebox>
Simply take max(line-height, height) for that box and you have the height
of the line box.

=====
----------------------------------------------------------
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, 17 January 2000 07:06:36 UTC