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

Re: New Working Draft: Positioning HTML Elements with Cascading Style Sheets

From: Jim King <jimk@mathtype.com>
Date: Tue, 04 Feb 1997 11:33:09 -0800
Message-Id: <>
To: Bert Bos <bert@w3.org>
Cc: www-style@w3.org
>> >> 2)Is there a particular reason that you can't make the line-height take
>> >> relative positioning into account?  If I have an image that forces the
>> >> line-height larger, then I subscript that image using {position:
>> >> relative...}, that will leave a large amount of white space above the 
>> >> and overlap the bottom.  While I can see the power of having the 
>> >> line-height NOT adjust, it would be good to have the option.
>> >Good question. Could you come up with a quick example that illustrates this,
>> >which I can forward to the document authors?
>This is not something for the proposed positioning features. The goal of
>WD-positioning is to allow elements to be put in other places than where
>they belong typographically. The example you give is a simple matter of
>finding the proper vertical alignment,
>The straightforward way would be to use this:
>    <P>This is an inline equation on line 2:
>     <IMG STYLE="height: 6em; width: 10em;
>*                vertical-align: -2.5em"
>          SRC="equation.gif">
>    <BR>
>    This is line 3, but it is very long to make sure the overlap

Agreed. If CSS ever adds <length> to the 'vertical-align' attribute, this
would be the correct way to do it. 

But I'm still not sure that positioning shouldn't move the item's
placeholder with the item.  What is the purpose for leaving a blank gap in
the page where the item is NOT? If I want to nudge an item around, I don't
necessarily want overlaps (although I can see the utility of overlaps for
some purposes). 

I'll give you another example: I have an image and I WANT it to overlap
something below it, so I drop it with the positioning attributes.  But
because the image took up space above the line, the box for the line is
still big, but with nothing in it. Yes, I wanted the overlap below, but I
certainly don't want the line-gap above. I guess I could explicitly set the
'line-height' for the image, but: 

>workaround. Vertical-align allows percentages, which are relative to the
>line-height value, so you can do this hack instead:
>    <P>This is an inline equation on line 2:
>     <IMG STYLE="height: 6em; width: 10em;
>                 line-height: 2.5em;
>                 vertical-align: -100%"
>          SRC="equation.gif">
>    <BR>
>    This is line 3, but it is very long to make sure the overlap

in both cases 'line-height' won't work because CSS1 4.4 paragraph 1
specifically states that replaced elements don't have a line-height. So
you've got to wrap the IMG in a SPAN just to get the line-height.

IMHO, the proper course is to do things that Hakon already said should be
kept in mind for the next round of CSS - namely:
1) allow <length> in 'vertical-align'
2) let replaced elements have a 'line-height'

Either one would let us subscript by a specific amount. Since neither is in
the spec now and so won't be implemented by browsers in the next round, I
was hoping that the Positioning spec would add the abilities we don't have -
especially since they specifically mentioned subscripting and superscripting
by a precise amount as a possible use.

In general I think it's a hole in CSS relative positioning that needs to be
filled, whether it is filled by fixing the CSS spec or by making these
things possible through direct positioning statements (via the positioning
spec). There is a certain amount of overlap between the two, so it's not
unreasonable to do it in Positioning.
Jim King
Product Manager

Design Science, Inc.            Sales:   sales@mathtype.com
4028 Broadway                   Support: support@mathtype.com
Long Beach, CA 90803            
USA                             World Wide Web: 
voice: 562-433-0685                 http://www.mathtype.com
fax:   562-433-6969
Received on Tuesday, 4 February 1997 14:32:01 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:26:42 UTC