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

On Thu, Feb 28, 2008 at 12:01 PM, Anne van Kesteren <annevk@opera.com> wrote:
> On Thu, 28 Feb 2008 20:09:40 +0100, Garrett Smith <dhtmlkitchen@gmail.com>
>  wrote:
>  > "not perfect," huh?
>  >
>  > (sarcasm)
>
>  It would be good if you stayed constructive.

Same for you.

>
>  > It is useless to have BODY be a containing block in CSS1Compat mode.
>  > There is no reason for having BODY be an offsetParent.
>
>  This is what several browsers implement already.
>
>
>
>  > 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?
>
>  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.


>
>
>
>  >>> What is b's containing block?
>  >>
>  >>  The initial containing block as far as I can tell.
>  >
>  > Are you sure?
>
>  Pretty sure, but it's been a while since I studied CSS 2.1 in detail.
>
Ah, then part of the problem is that you don't know what a containing
block is. When I said "Are you sure," I gave you a chance to go look
at the spec, which I posted earlier in this thread. Here it is again:

"CSS2.1, 10.1 Definition of "containing block"
"... if the element's position is 'relative' or 'static', the
containing block is formed by the content edge of the nearest
block-level, table cell or inline-block ancestor box.""

Please read and then tell me what the correct answer is.

http://www.w3.org/TR/CSS21/visudet.html#containing-block-details

It is extremely frustrating to deal with someone who is unwilling to think.

Here is the example again:

<!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>

I posted the question in response to your vague statment

"Although if most browsers indeed implement
offsetParent as always being the containing block we should maybe go with
that."

It was based on the simple fallacy of affirming the consequent:

It basically goes like this:
    If Bill Gates owns Fort Knox, then he is rich.
    Bill Gates is rich.
    Therefore, Bill Gates owns Fort Knox.

You applied this same logic to offsetParent and 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.

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

>
>
>  > 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.
>
>  There's another API for that.

The only reason you've given so far for making body an "initial
offsetParent" ( IOP is the only term that I could find appropriate) is
that other browsers do it this way. Even after I've shown that
creating an IOP is confusing, unclear, and undesirable.

Part of the reason the other browsers do this is that you've had an
influence on them.

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

>
>
>
>  >   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?

You seem to not know what a containing block is. So your analysis is
questionable.

>
>
>
>  >>  I couldn't find that function, but yes, that might be problematic.
>  >
>  > Did you download the file?
>
>  I did, but apparently something went wrong as I just retried and found the
>  function you mentioned. It sees to use getBoundingClientRect() and falls
>  back to offset otherwise. Doesn't seem too bad.

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.

>
>
>  > It seems you are writing an API that you do not actually use.
>
>  My profession is Web developer, if that's what you mean. I've certainly
>  used the API though, see the numerous tests I pointed out earlier.
>
I see.

Once you scratch beneath the surface, you'll realized that there's a
lot more to the problem.


>
>
>  > I asked you before, and you ignored my question:
>  > Will browsers really "converge" to implement offsetXXX the way you've
>  > specified?
>
>  I can't predict the future. That's the plan though.
>

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.


>
>
>  > 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?
>
>  As currently specified the API will work fine for most scripts that simply
>  try to determine the position of an element.

This is not true.

Please prove that this is true.

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.

>  specifics of a particular implementation it might be problematic yes.
>  We'll have to await implementation feedback.
>
>
>  --
>
>
> Anne van Kesteren
>  <http://annevankesteren.nl/>
>  <http://www.opera.com/>
>

Received on Thursday, 28 February 2008 22:46:36 UTC