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

On Thu, Feb 28, 2008 at 2:34 AM, Anne van Kesteren <annevk@opera.com> wrote:
> On Thu, 28 Feb 2008 03:21:12 +0100, Garrett Smith <dhtmlkitchen@gmail.com>
>  wrote:
>
> > On Wed, Feb 27, 2008 at 4:32 PM, Anne van Kesteren <annevk@opera.com>
>  > wrote:
>

>  Yeah, you're probably right.

What is the appropriate action to take?



>  > AFACT - IE 6+ has been consistent with standards mode of offsetXXX
>  > properties. Opera is implementing offsetTop as the spec specifies. I
>  > don't know which came first - opera's behaviour, or the spec.
>
>  Actually, Opera had some serious issues with sites because of its initial
>  implementation of offsetParent, etc. Reverse engineering these attributes
>  and documenting them has helped us getting an implementation that is more
>  compatible with what websites expect. I'm not claiming it's perfect though.

"not perfect," huh?

(sarcasm)

>  > <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
>  >         "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
>  > <html>
>  > <head><title></title>
>  > </head>
>  > <body>
>  > <div id='a'>
>  > <div id='b' style="position: relative;">bla</div>
>  > </div>
>  > </body>
>  >
>  > -- What is b's offsetParent? Is it #a, BODY, or HTML?
>
>  It's BODY.

According to your spec.

It is useless to have BODY be a containing block in CSS1Compat mode.
There is no reason for having BODY be an offsetParent.

I've asked you why BODY should be an offsetParent, you ignored. So I'm
asking again: Why must BODY be an offsetParent? Why is it important to
break what Internet Explorer really does? How does this help
compatibility?


>  > What is b's containing block?
>
>  The initial containing block as far as I can tell.

Are you sure?


>
>  > But why can body not have an offsetParent? It is inconsistent,
>  > unexpected, and confusing (at least to me) to give BODY special
>  > treatment.
>
>  I agree it's not that nice, but the HTML body element has special
>  treatment in other places too: event handling and CSS. So in that respect
>  it's not that bad I think.

Do you think?

BODY being offsetParent:
  PRO: AVK doesn't think it's bad
  PRO: AVK already spec'd it that way
  CON: Contradicts Internet Explorer's behavior
  CON: Impossible to determine coords of BODY element.
  CON: Impossible to determine coords of BODY's abs pos'd child when
BODY is static.

The question that came up was: "why can body not have an offsetParent?"


>  I couldn't find that function, but yes, that might be problematic.
>

Did you download the file?

My initial suggestion was for you to write a function to determine to
coordinates of [any_element].

Then I suggested that you look at how others use the CSSOM API
(Brandon Aaron's offset() function, in this case).

It seems you are writing an API that you do not actually use.

>
>
>  > If the browsers really do implement a spec'd offsetXXX, then the spec
>  > should be consistent with what IE does.
>
>  As I said before, given that IE depends on hasLayout etc. and requires
>  different code paths in quirks and standards mode I'm not convinced that's
>  the best solution. I also don't think that the various offset attributes
>  will see much use going forward once everyone has adopted
>  getBoudingClientRect() and getClientRects() methods.

IE does not depend on hasLayout to use offsetParent for body.

getBoundingClientRect does not provide any reason for why BODY must be
an offsetParent.

You seem to want to keep BODY for the "initial offsetParent." Why is
this a good idea?

I asked you before, and you ignored my question:
Will browsers really "converge" to implement offsetXXX the way you've
specified?


Consider IE8 in your answer.

I'll quote our conversation from earlier --

GS: "The browsers have different implementations - from each other and from
 the spec. Should all the browsers change? Won't that break existing
 scripts?..."

AVK: "They should converge in one way or another."
-- end.

Can you answer my second question?
2. Won't that break existing scripts?

Thank you,

Garrett

>
>
>  --
>
>
> Anne van Kesteren
>  <http://annevankesteren.nl/>
>  <http://www.opera.com/>
>

Received on Thursday, 28 February 2008 19:09:50 UTC