- From: Garrett Smith <dhtmlkitchen@gmail.com>
- Date: Fri, 29 Feb 2008 12:00:46 -0800
- To: Www-style <www-style@w3.org>
I hit send by accident in the middle of typing and did not reply to list -- back to list (with partially incomplete mail). On Fri, Feb 29, 2008 at 11:58 AM, Garrett Smith <dhtmlkitchen@gmail.com> wrote: > On Fri, Feb 29, 2008 at 3:39 AM, Anne van Kesteren <annevk@opera.com> wrote: > > On Fri, 29 Feb 2008 03:09:23 +0100, Garrett Smith <dhtmlkitchen@gmail.com> > > wrote: > > > > > That's why we got into the discussion about containing block. > > > offsetParent is a containing block (of something), because > > > offsetParent has to have position other than static - > > > > > > <div style="position: static"><div id="C"></div></div> > > > > > > - outer element is a containing block for child C when C is position: > > > static|relative. Outer elem isn't a containing block. > > > > > > <body style="position:static"><div id="C"></div></body> > > > > > > - outer element is a containing block for child C when C is position: > > > static|relative. Outer elem isn't a containing block. > > > > You're probably falling asleep already, but I don't really understand what > > you're trying to say. > > outer elem isn't an offsetParent - is what I meant. > > You don't actually know what I'm doing, BTW. or "It would be nice if > you could stay constructive." > > [insert_smiley_here]. > > > > > > > > > > > >>> Part of the reason the other browsers do this is that you've had an > > >>> influence on them. > > >> > > >> You mean that their behavior changed? (Other than Opera.) > > > > > > That is not what I said. > > > > > > Your documentation affirms the behavior - behavior which is > > > odd/confusing/deviating - of other browsers (not IE). > > > > You said that other browsers have a certain behavior because of my > > influence. > > Thats a fair statement. > > > Now you're saying something else... > > > > I'm saying the same thing I've been saying all along. You have an influence. > > > > > > > > >> <!doctype html> > > >> <div id=x style=position:absolute;top:10px>xxx</div> > > >> <script> alert(document.getElementById('x').offsetTop) </script> > > > > > > The CSSOM, Opera, Mozilla, and Webkit say "body". > > > > They'd say 10. IE7 too, fwiw. > > > FOr offsetParent, not offsetTop, they would say "body". > > > > > > > > > > > > getComputedStyle(document.body,'').marginTop > > > > > > Reveals "8px" in 2 browsers. > > > > > > The offsetTop, according to CSSOM, should be the distance between the > > > border edge of #x and the padding edge of it's offsetParent. > > > > > > x's border-edge is 10px from HTML > > > BODY's padding edge is 8px from HTML > > > > > > 10px - 8px = 2px > > > > > > Then there's the special case for body. Here's where it's a problem. > > > > This is what quirks mode expects and you need to special case at some > > point anyway. The HTML html element can be positioned too, etc. > > > a positioned documentElement - do left/top values apply? > > border-top-width - that's clientTop > > margin-top on documentElement - there would be no way to obtain this > value - offsetTop would be 0 and offsetParent would be null. > > Browsers' default css (e.g. html.css) don't include margin for to > documentElement. Adding margin to documentElement is not something the > browsers seem to agree on very well - for example: > > > > and you'd > > have the same issues. So I don't really see this as a problem. Also, this > > is a legacy API and people are already migrating their scripts to use > > getClientRects() and getBoundingClientRect() (see jquery for instance). > > > > > > > > > These browsers will report "10" for offsetTop. The distance from the > > > element to the element's containing block is, in fact, 10. But the > > > containing block is not BODY. The containing block is HTML. We have an > > > element that reports 10px from it's offsetParent, BODY. > > > > > > The example you provided does not tell us how far x is from the > > > padding edge of its offsetParent. If offsetParent is BODY, then the > > > actual distance of the border edge of #x to the padding edge of BODY > > > is 2px -- not 10px. > > > > True, offsetParent being the HTML body element is a special case. > > One that makes it impossible to determine the location of a child of > body. This is proven in the example you provided - thanks. > > According to the current revision of CSSOM, BODY is an > initialOffsetParent, essentially. > > > > > > > >> Yet the function works fine with current implementations, including > > >> those where offsetParent is mostly <body>. > > > > > > When you say 'implementation' do you mean browser or web page? > > > > Browser implementations that have to deal with existing Web pages. > > That function seems to work in their example. Once you start doing > things like adding position: relative to BODY, adding margin and > border to body, the whole thing falls apart. This issue is not just > seen in jQuery. > > The author worked very hard just to address all the browser > differences. When a browser matching their browser checker changes its > behavior, it can break the script. It's an extra maintenance burden. > If the behavior changes to match the CSSOM spec, it will not be > possible to determine the position of an element. (see example above). > > Having BODY as an initialOffsetParent is a problem in Safari, Opera, > and Mozilla. > > The browsers are less likely to make a change to get rid of the > initialOffsetParent if the current revision of CSSOM is promoted as > the correct or "standard" way. Developers are just going to have to > code around the problems. > > Garrett > > > -- > > > > > > > > Anne van Kesteren > > <http://annevankesteren.nl/> > > <http://www.opera.com/> > > >
Received on Friday, 29 February 2008 20:01:03 UTC