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

On Thu, Feb 28, 2008 at 3:06 PM, Anne van Kesteren <annevk@opera.com> wrote:
> On Thu, 28 Feb 2008 23:46:28 +0100, Garrett Smith <dhtmlkitchen@gmail.com>
>  wrote:
>
> >>  Several browsers already do this and it doesn't require a separate
>  >> quirks mode code path. This is the most straightforward solution to
>  >> that problem.
>  >
>  > This seems contradictory to me.
>  >
>  > You said earlier that the spec was based about quirks mode.
>  >
>  > If this is true, then quirks mode should be irrelevant.
>
>  I don't understand this. In general we want to minimize the difference
>  between quirks and standards mode. The less differences needed, the better.

Who is 'we'? Opera?

Why must quirks mode affect the spec?

>  Fair enough, but how does it affect anything?

I'm going to use the example you provided below, where containing
block is HTML and offsetParent is BODY - your example is the only time
when such condition happens and it causes problems.

>
>
>  > You applied this same logic to offsetParent and containing block.
>
>  I have not applied any such logic. offsetParent is not based on the
>  containing block in the specification.


Here's what you wrote:

"Layout coordinates are calculated with respect to the offsetParent, not
the containing block. Although if most browsers indeed implement
offsetParent as always being the containing block we should maybe go with
that..."

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.


>
>
>  > But
>  > you don't actually know what a containing block is. Don't even care to
>  > read what I wrote. I wrote the definition of containing block only a
>  > few days ago and you either did not read what I wrote or ignored it
>  > and forgot about it.
>
>  My apologies if this is the case. I think you're a bit overreacting though.
>

I'm getting tired of repeating myself.

Qualified apology: -1

>
>
>  > I find this to be arrogant and insulting. I went through a lot of
>  > trouble to explain that to you. If you waste my time enough, maybe
>  > I'll get tired of replying...
>
>  ...
>
>

Does ellipsis mean "waiting?" Are you waiting for me to "get tired of replying"?


>
>  > 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).

>
>  > I've mentioned before that pr
>  > The significance of the problem with having BODY as an "initial
>  > offsetParent" is that it makes it impossible to determine if BODY is
>  > an offsetParent and not a containing block, or if BODY is a containing
>  > block, or if BODY's offsetTop should include its margin
>
>  I'm not sure why this is relevant.
>

Are you interested in understanding?


>
>
>  >>  >   CON: Impossible to determine coords of BODY's abs pos'd child when
>  >>  > BODY is static.
>  >>
>  >>  That's not true as far as I can tell.
>  >
>  > Have you looked into it?
>  >
>  > Can you create a test case that shows how to find the position of an
>  > element using these properties?
>
>  <!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".

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.

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.


>  etc.
>
>
>
>  > You seem to not know what a containing block is. So your analysis is
>  > questionable.
>
>  I'm not sure how that's relevant here.
>
It is relevant because you said:

"Layout coordinates are calculated with respect to the offsetParent, not
the containing block. Although if most browsers indeed implement
offsetParent as always being the containing block we should maybe go with
that..."

Then I said that was not right, and :

An offsetParent is a containing block, but a containing block might
not be an offsetParent.

offsetParent is a relatively positioned containing block. A containing
block for a relatively positioned child could have position: static.

Then I posted an example and I asked:

What is offsetTop? What is the containing block?

>
>
>  > The function will break as offsetXXX changes. It will also break when
>  > applying styles to BODY or HTML. So will YUI. So will a lot of
>  > libraries.
>  >
>  > That seems pretty bad to me.
>
>  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?

If you mean 'web page', then I would have to disagree with your
statement. Adding position: relative to body and margin: 10px will
return inaccurate results. Menus, tooltips, d'n d will be off.

Using browser detection to address anomalies means that it breaks if
the browser changes.

>
>
>
>  > Lets look into this a little more:
>  >
>  > Q: How likely is it that Internet Explorer 8 will change its behavior
>  > to use CSSOM Views, creating an initial offsetParent for body, going
>  > against IE6 and IE7?
>  >
>  >  A. definitely, Internet Explorer will break compatibility to use an
>  > API that is more compatible with quirks mode
>  >  B highly likely - Internet Explorer will break compatibility to use
>  > an API that is more compatible with quirks mode
>  >  C possible -  Internet Explorer might break the web - there will be
>  > an initialOffsetParent that is the BODY element in IE8
>  >  D highly unlikely - Internet Explorer will not break the web - there
>  > will probably not be a new "initialOffsetParent" in IE8
>  >  E definitely not - Internet Explorer will not break the web. And
>  > initialOffsetParent property based on clobbering quirks and standards
>  > is a bad idea - even if other browsers already do it.
>
>  You'd have to ask the IE Team.

I'll put $10 on E.

It's unreasonable to expect IE to break the web.

>
>
>  > Can you write a function, based off this spec, to find the position of
>  > [any_element]? The function should work in all four major browsers, it
>  > should use offsetXXX.
>
>  It does not work for the <body> element and under similar condition.
>  Please stay reasonable

So you do know how broken CSSOM is.

If CSSOM implemented offsetXXX like IE does, the function should not
take more than a few hours to sketch out. Then a test - 2 hours. Add
to that a couple edge cases you forgot - so maybe 1-2 hours more, then
cleanup integration. Giving 1 day to write such a function seems like
it would be enough, I think. Of course, with the current situation, it
is not so easy.


Garrett

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

Received on Friday, 29 February 2008 02:09:33 UTC