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

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.


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

Fair enough, but how does it affect anything?


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


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

...


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


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


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

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.


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


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


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


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

Received on Thursday, 28 February 2008 23:01:22 UTC