Re: [CSS21] response to issue 75

On 16 Feb 2004 at 16:57, Ian Hickson wrote:
> > The top of a box in the subtree in the last sentence of
> > the paragraph would be the top content edge i assume?
> 
> No, it would be the top of the line-height, as for the other vertical
> alignment values. The "top of the box" wording is used identically for
> several of the vertical-align values.
> 
Yes, that does seem to sidestep the difference between replaced 
and non-replaced inlines regarding margin/padding/border, if that 
distinction is understood. 

There may be a typo in 10.6.1, BTW:
 formed => former

> > I have also been thinking about whether introducing a 'line-spacing'
> > property might reduce the issues with 'line-height'.
> 
> I'm not really sure I understand which "issues" this (or your alternate
> inline box model) would solve.

Sorry if i am being unclear, its probably mostly because i have a 
hard time getting my head around theese things. 

Basically i belive that there are major differences in how seemingly
simple cases of inline rendering is handled in major implementations, 
and that this difference is to some degree caused by the intricate model
currently defined. I think previous posts to this list makes it rather
clear that the model is complex and difficult to understand. In my 
opinion the path CSS3 takes is to keep (and expand) the model but make 
most things any browser currently implements defined through a property.
IMVHO this might be a misstake, since the model is not quite good enough
(not because it doesn't work, but because it is to difficult and thus
introduce differences and has what i see as unintuitive parts).

If you are interested in such examples i could provide a few, but i 
think your knowledge of such examples is far greater than mine.

In addition to what i see as issues with the implementations of the 
inline rendering, i think the model is not quite intuitive compared 
to the box model used for blocks. What i think i am trying to refer 
to here is the fundamental difference between width and height in 
blocks, which i belive should apply to line-boxes and non-replaced 
inlines as well. I also think that "disregarding" vertical 
margin/padding/border for non-replaced elements creates a model that 
gives unexpected results that are difficult to understand without 
knowing a lot about the details of inline formatting. Also, having 
the height of a non-replaced box being defined by the font(or fonts, 
a 'should' changed into a 'may' which i dont think the major browsers 
implement, except IE due to using a different model) of its textual 
contents seem unintuitive, since the case where non-textual content 
is higher is so common as well as since this is not similar to how 
the block box model works. 

I was also trying to ask whether it would be feasible to make changes in
this area. I think it might be, since pages are unlikely to depend on
the intricate parts of this model, and since there are major differences
already in implementations. I do have some idea of what such a 
change would mean in terms of work on the recommendations
however...

Regarding my freely written thoughts on an alternate model i think it 
might be better to clarify those at a later time if they are 
interesting, but essentially i was aiming for a model where each 
subtree of boxes in a line is more "self-contained" and "block-box-
like", and where margin/padding/border is significant in both 
dimensions for both replaced and non-replaced elements. To achieve 
that i considered reducing the importance of line-height, making top 
and bottom work versus the parent, and making the hight and baseline 
of non-replaced depend on contents.

>>     <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.

>Why? The click already bubbles to the <a>.

Yes.. i'm just trying to say that it seems more intuitive to me that the
link box covers the area which you can click to activate it, not claiming
that the current model stops links from working. Another example 
might be when you put a border on an object which has a nested object 
as fallback, it probably doesn't make sense to most users in at least 
one browser since the outer, unused object seem to get turned into a 
non-replaced inline.

>> 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.

>I don't understand what this is trying to show.

The idea was to point out that non-replaced borders are defined to bleed,
which i think is less than ideal. Especially since replaced borders
are not. This might explain me not understanding that "the top of the 
box" in the vertical-align issue you resolved in this thread was a 
way to specify that it depended on the type of inline box.

 /Staffan

Received on Wednesday, 18 February 2004 17:33:17 UTC