RE: A why on inline rendering

Staffan,
I think you have many good points and your understanding is pretty good. I will try to answer some of your questions. Concerning 'text-height' and why its initial value is not 'max-size', you may be surprised to discover that some browsers use 'auto' (Nav 7.2, I think) while others use 'max-size' (IE6) as initial value. (I have not tried Opera or others). (afaik, nobody has implemented 'text-height' of course but you may assume that the 'initial' value would de facto be there.) The reason to create 'text-height' was that there are various ways today to compute text content height for non-replaced inline elements and to capture various implementations. There is however not a complete consensus for what should be the initial value.

The reason why replaced elements take into account margin/padding/border for alignment or line stacking is mostly historic. The specification has to deal with context where most browsers have implemented these features the same way. Same thing about the opposite situation for non-replaced inline elements. Should we add more flexibility concerning adding m/p/b for non-replaced inline elements? Maybe so. I agree that the different behavior between replaced and non-replaced is not logical. You may also see that browsers don't necessarily do the same thing for edge lines (first or last) as for the other lines (see for example IE6). Probably a matter of discussion at the next week CSS WG face to face meeting.

In general browsers behavior vary a lot concerning these issues and it does not make easier to write a specification which recognizes the current situation while allowing to move forward to a 'cleaner' model.

Finally there is the issue of keeping the design reasonably simple. As of today, the line module is not terribly reader friendly and I am a bit hesitant to make it even more complicated, but again your points are valid.

Michel

Received on Friday, 28 February 2003 12:27:26 UTC