Re: [CSS21] response to issue 75

On 11 Feb 2004 at 21:40, Bert Bos wrote:
>			...The top of the
>     aligned subtree is the highest of the tops of the boxes in the
>    subtree, and the bottom is analogous.
>    Changed definitions:
> 
>      'top'
>         Align the top of the aligned subtree with the top of the 
line
>         box. 
>      'bottom'
>         Align the bottom of the aligned subtree with the bottom of 
the
>         line box.
> 

Interesting. The top of a box in the subtree in the last sentence of 
the paragraph would be the top content edge i assume? I think it 
might be wierd if margin/padding/border had the "expected" effect for 
children of top or bottom aligned boxes but not (normally) otherwise.

To my mind this is an improvement and it does sound very reasonable 
for CSS 2.1. However, personally i think that it might be wise to 
consider an alternate model for inline rendering in a future version 
of CSS. I would like to know if something like the following might 
actually work without giving to many "backwards compatbility" issues, 
or if another model could be constructed without causing to many 
issues. 

In case this is interesting to discuss, the rest of this message are 
some more or less wild thoughts on such a model:


Each inline node (replaced as well as non-replaced) has a baseline. 
The baseline of a replaced element is document language and/or UA 
defined, while the baseline of a non-replaced element is defined by 
its children as well as its text contents. Typically, a replaced 
element such as an image would have a baseline below its bottom 
margin edge, while any non-replaced elements or line box containing 
text would have a baseline through its content area.

The baseline of a non-replaced inline box is defined by finding the 
highest top margin edge of a child box or textnode, as well as the 
lowest bottom margin edge, when the children are aligned vertically 
in the box. The sum of those values is the box height. 

Each box generated by an inline element is aligned versus its parent, 
or if no parent exists, versus the line box. The top and bottom 
values for the 'vertical-align' property are not relative to the line 
box for an element that has a parent.  

When calculation the edges, child boxes that have baseline as their
computed vertical-align are considered first. In the second pass when 
children with vertical-align other than baseline are considered, 
document order is used to set their position and caculate their 
effect on the parent or line box. If for example a box holds two 
images with the same distances from top margin edge to bottom margin 
edge, their order becomes significant in calculating the baseline of 
the box if their vertical-align differ. 



I think something similar to the above might give a simpler model for 
what goes where in inline rendering, if corrected and written up in 
rec-talk. The idea is to vertical-align everything versus the parent, 
and to let the non-replaced inlines get their height by their 
contents, similar to blocks. In addition, i think allowing vertical 
margin/padding/borders to "work" in an inline context would 
be a good idea.

I have also been thinking about whether introducing a 'line-spacing'
property might reduce the issues with 'line-height'. This new 
property would have the suggested default value of 0 to .2em, while 
'line-height' would have the initial value 'auto'.

I've also been considering whether it would be feasible to allow 
width/height for non-replaced inline elements, for instance by making 
them apply to every box that element generates, but that might 
introduce some interesting issues with horizontal positioning on the 
line and how to scale the baseline as well as overflow considerations 
i suppose.

One obvious difference in many pages seem to be (assuming an image 
higher than 1.2em)

    <a href="dummy" style="border: solid"><img src="dummy.png"/></a>

where the a-box would in this model be high enough to potentially be 
the thing you click on when activating the link as you press the 
image. This seems like a good thing to me.

Another example that would seem to work better in a model like the 
above is of course
    Text row one</br>
    <span style="border-top: solid .5em">Text row two</span>
but that is for obvious reasons never used.

 /Staffan

Received on Thursday, 12 February 2004 15:49:47 UTC