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

RE: [cssom-view] Why is body's offsetParent null ?

From: Mike Wilson <mikewse@hotmail.com>
Date: Wed, 23 Apr 2008 15:03:45 +0200
Message-ID: <BAY116-DAV13C0A7F9AEC6B9F7C4BF96A4E30@phx.gbl>
To: "'Anne van Kesteren'" <annevk@opera.com>, "'Www-style'" <www-style@w3.org>
Cc: "'Daniel Glazman'" <daniel.glazman@disruptive-innovations.com>
Message-ID: <017401c8a542$766934d0$0a01a8c0@mikedeskxp>

> On Wed, 23 Apr 2008 13:37:43 +0200, Mike Wilson 
> <mikewse@hotmail.com>  
> wrote:
> > Anne van Kesteren wrote:
> > > Following that (special casing position:relative on the HTML 
> > > body element)  
> > > would break finding the position of an element within the page, 
> > >    http://lists.w3.org/Archives/Public/www-style/2008Apr/0366.html
> >
> > That's only the current behaviour of Firefox you're talking 
> > about, right?
> No, if we followed Internet Explorer we would have to introduce  
> differences between quirks and standards mode which is currently a  
> non-goal of the specification. We'd also have to figure out 
> how hasLayout  
> affects everything as explained in this blog post:

You are replying to the wrong thing.
Your statement was that Garrett's suggestion would break finding the
position of an element within the page. I referred to your post and
showed that IE doesn't break finding the position within the page.
It has nothing to do with trying to emulate hasLayout or anything
else IE-specific. 

You seem to try to scare people into your own preference with threats
about that all quirks of IE will have to be implemented. That is just
not true in my opinion. I strongly believe that the standard should
propose a simplified version of the IE model (something like the one 
I showed) instead of leaning towards the bug-ridden cloned impls made
by IE's competitors.

> I don't think we want to go anywhere near that.

Of course not! But that is not the point.

<table snipped>
> I agree that some of this is more desirable and initially I 
> thought it  
> would be more like that, but I don't think it's worth going in this  
> direction because:
>    1. Emulating IE completely is not feasible anyway given hasLayout.

A non-issue as I mentioned above.

>    2. This requires a different code path for quirks mode 
> making browser  
> unnessarily more complicated as better solutions for authors 
> are available.

As I've said before; why this focus on quirks mode?
If there must be only one algorithm why not make it compatible with
IE's standards mode instead of quirks mode?

>    3. This special cases the root element instead which is arguably  
> somewhat of an improvement, but not much.

It is less special-casing than what CSSOM currently suggests.

>    4. This would be incompatible with three out of four browsers.

I guess the "three browsers" you refer to are:
1) Firefox 2: algorithm entirely and admittedly broken
2) Opera 9: already updated to follow the CSSOM draft spec, or what Opera
   version should we look at to see what was "before" CSSOM?
3) Safari 2: does like IE, Safari 3: does like CSSOM
   (inspired by the draft CSSOM perhaps?)

It's worth mentioning:
4) Konqueror: does like IE

So I would argue that (1) and (2) should be ignored. You're right that
Safari 3 does like IE but that seems to be a recent change. This 
picture is a bit different from the one you're painting.

Now when talking about browsers I have to bring up another thing.
Considering deployed content on the Web that is using offset* properties - 
what browsers was that content made for? I would say IE as they invented 
the properties. I wouldn't say Opera or Safari. What is your position on
This is a crucial part of being backwards compatible with the Web.

> Maybe we should leave this as messy as it is today and focus only
> on the new methods.

With the current state of CSSOM I think it would be better to remove
the offset* properties from the spec, and then have Anne publish a
report on his findings on IE reverse-engineering, for all browser
vendors benefit.

Best regards
Received on Wednesday, 23 April 2008 13:04:39 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:36 UTC