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

>> 1) You never define what units are available.  I'd suggest allowing all
>> units available in 6.1 and 6.2 of the CSS spec:
>Right. The draft does say it is extending the CSS1 spec (by providing new
>properties) hence all the units available in CSS1 are still available.
>> I don't think this can be assumed, given that some of the CSS
>> spec elements don't support all of them,
>can you give an example of what you mean? Is this an ambiguity in the
>CSS1 spec, the positioning spec, or both?

Well, In December we had a discussion about 'vertical-align' in CSS1, and
found that only allows % values (other than the preset Top, Bottom, etc...)
- not em, px, etc.... It was too late for anyone to change the spec, but
Hakon was mentioned looking at it in the next round.

On re-reading the grammar in the Positioning spec, I notice that everything
explicitly allows <length>, so I was wrong - this is covered.

>> 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 image
>> 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?

Here's an example that my company worries about all the time - an inline
equation that should be vertically aligned so that the baseline of the text
inside lines up with the baseline of the text outside.  All values are in
em's because we want the equation to size properly with the browser's text:

<P>This is line 1</P>
<P>This is an inline equation on line 2:
    <IMG STYLE="height: 6em; width: 10em;
                position: relative;
                top: 2.5em;"
         SRC="equation.gif">
<BR>
This is line 3, but it is very long to make sure the overlap happens.</P>

In the above example, since the line height is not changed by positioning,
there would be a large gap between line 1 and 2, and the equation would
overwrite (or be overwritten by, since the z-order isn't defined explicitly)
the line below it.

Maybe another element such as:
==========================================================================
'space-anchor'
Value:   page | element
Initial: page
Applies To:  elements with the 'position' property of type 'relative'.
Inherited: no

For elements with 'relative' positioning, defines how the space reserved for
the normally rendered element is treated.

- The default value ('page') will cause the space reserved for the element 
  not to move with the element. When the contents of these elements are 
  moved, they may obscure any content below them depending on the 
  corresponding z-index attribute.
- The value ('element') will cause the space reserved for the element to 
  move with the element itself.  For example, the line-height of an image 
  moved down using the 'top' attribute will adjust to the final destination 
  of the image, and it will not obscure any content below because the its
  padding will be taken into account for the positioning of the next line.
=========================================================================

So by adding 'space-anchor: element;' to my example there would be no collision.

Obviously I came up with the terminology off the top of my head. With some
thought, I'm sure someone can think of better names for attributes.
Jim King
Product Manager
jimk@mathtype.com

==================================================================
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 Monday, 3 February 1997 13:23:13 UTC