RE: [cssom-view] New WD "CSSOM View Module"

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