Re: partial resolution: line-height in MSIE

Thomas Reardon wrote:
> ...  We clearly have a bug in
> beta2 and are fixing it this afternoon.  Basically we were
introducing
> the 'internal leading' bias into the line-height calculation, which
was
> incorrect.

Is there a similar problem with 'internal paragraph leading' and
margin calculations? I am unable to override default vertical spacing
for the <P> and <Hn> tags. Explicitly setting vertical margins to '0'
for these tags in a style declaration doesn't have the expected
effect.

Also...

It appears the default element spacing is added to the top of the
element. This will be a problem when wrapping text in multiple
columns is supported. Since there is no mechanism for ignoring the
top margin of a text element when it is at the top of a column, the
top line of a wrapped column will not be aligned with the top line of
a column in which a text element begins.

The "margin: n n n n" method for specifying margins doesn't work, and
as Carl Morris pointed out the method for specifying colors and font
names is not in accordance with the CSS spec.

I cannot get rid of the top margin of the document. The only way to 
put an element flush with the top of the document is to use negative
margins, which is a very bad idea since there is no guarantee another
browser will have the same defaults.

Tables do not line up with the left margin. With both the document
margin and the table margins set to zero, the table border should be
flush to the left of the window and it's not. Also, cellpadding
doesn't work right in tables. If a text element in a table cell has a
margin of zero, it's horizontally-aligned flush to the table border
regardless of table cellpadding.

I eagerly await the fixes.

David Perrell

Received on Monday, 5 August 1996 16:48:48 UTC