W3C home > Mailing lists > Public > www-style@w3.org > May 2008

RE: [CSS21] Why are browser default style values different from Appendix D

From: Saloni Mira Rai <salonir@microsoft.com>
Date: Tue, 6 May 2008 23:00:35 -0700
To: Alan Gresley <alan@css-class.com>
CC: Arron Eicholz <Arron.Eicholz@microsoft.com>, "Ph. Wittenbergh" <jk7r-obt@asahi-net.or.jp>, CSS <www-style@w3.org>, Alex Mogilevsky <alexmog@exchange.microsoft.com>
Message-ID: <E8245DDD23CF8443A20CDFABD553C2FD2B0CF6C62B@NA-EXMSG-C112.redmond.corp.microsoft.com>

Hello,

Arron did modify the test to put the UL within a "non hasLayout" element, and the value was still 0 for margin-top and margin-bottom.
Can you send the test where you are seeing the 19px?

Also, to reiterate, IE7 values are not and should not be the focus here. In each of the cases you say hasLayout interferes with the test, all other browsers are consistent. This suggests that IE7 data for these elements would not affect the end decision.
(Also, other browsers do not have "hasLayout". So far we haven't seen problems with other browser data so I am going to continue assuming that it is all correct and do not require debate)

Lets instead look at the elements for which real world implementations are different from the spec. As Elika said on this list before, if there is consensus between majority of the implementations, then we have good enough reason to drive these edits back into the spec.
I would request that everyone examine the table and discuss which values make sense, and which need to be modified.


Thanks,
Saloni

________________________________________
From: Alan Gresley [alan@css-class.com]
Sent: Tuesday, May 06, 2008 6:15 PM
To: Saloni Mira Rai
Cc: Arron Eicholz; Ph. Wittenbergh; CSS; Alex Mogilevsky
Subject: Re: [CSS21] Why are browser default style values different from       Appendix D

Saloni Mira Rai wrote:
> Hi Alan,
>
> The data I have sent out actually does not contain the information for nested lists.
>
> Thanks,
> Saloni


Well that a big error on my part. Let's back track to your list message.

http://lists.w3.org/Archives/Public/www-style/2008May/0014.html


Which has a table attached where you have highlighted rows in pink. You say.

"I also highlighted rows that show differences between the spec and
current implementations."


I would like to look into these differences between the spec and current
implementations but I keep on seeing some zeros for one implementation.
For unordered list you have the property for margin.


| App. D  |  IE7       |  FF2   |  FF3   |  Op    |  Saf   |  Final
--------------------------------------------------------------------
|1.12em 0 | 0 0 0 30pt | 16px 0 | 16px 0 | 16px 0 | 16px 0 |  1em 0


If only one element UL appears inside the BODY element then the above
values in the table is true but the reason that IE7 shows the top and
bottom margin as zero is that in IE7, the BODY element is hasLayout=true
by default. The same allies for Ordered List. If the UL or OL was inside
a DIV with either a border or padding and hasLayout=false then the
values for IE7 would be.


|  IE7             |
--------------------
| 19px 0 19px 30pt |


This is the point I drawing your at attention too. As Philippe has said
[1].

"According to the Dom toolbar the values are 'auto', and margin-left:30pt."


For IE7 the vertical margins with auto for unordered list is
approximately 19px. The same applies for the margin-top of the H1, H2,
H3, H4, H5, H6, P elements which I have mentioned [2]. The margin-top
will disappear in hasLayout=true containers.

It would be of great benefit to see the UA style sheet defaults values
for IE8 in the table instead of focusing on IE7. The only benefit I can
see for keeping IE7 in the table is for authors alone.

I will work on an updated table and upload it soon.


[1] http://lists.w3.org/Archives/Public/www-style/2008May/0017.html
[2] http://lists.w3.org/Archives/Public/www-style/2008May/0024.html


Alan
Received on Wednesday, 7 May 2008 06:01:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:06 GMT