Re: [cssom-view] small update

Hi Mike,

On Fri, 14 Mar 2008 23:04:55 +0100, Mike Wilson <mikewse@hotmail.com>  
wrote:
> I have studied some of the differences between the various
> approaches and made some comparison tables below. There are
> lots of data here so please excuse (and inform me) if something
> is not correct. The HTML file used for testing is at the end of
> this mail.

Thanks! The one piece that seems to be missing here is quirks mode. The  
specification intents to deal with quirks mode, limited quirks mode, and  
no quirks mode, as defined by HTML 5. Because I believe the current model  
can be implemented without deviations in any quirks mode they are not  
mentioned explicitly.


> Observations:
>
> 1) CSSOM differs from IE by letting div1 point to BODY instead
>    of HTML.
>
>    Q: What was the rationale for this change? (I agree that it
>       is "cleaner" not to special-case children of BODY to
>       instead point to HTML, but IE is the mother of these
>       properties so...)

The rationale is that it's more consistent with non-IE browsers and that  
it also works for quirks mode.


> 2) IE points div3b to div2b (as opposed to div1 in CSSOM).
>    In this respect IE matches the rules for Containing
>    Block to determine offsetParent. I have the impression that
>    the offset properties were designed in the "spirit" of
>    Containing Block for consistency with dimensional properties
>    top, left etc. These are interpreted with respect to the CB
>    so it would make sense to let the corresponding offset
>    properties also do this. [The "simple?" column maps the CB
>    algorithm]
>
>    Q: Did you consider using the CB algorithm for offsetParent
>       and were there any hard problems?

It would not be consistent with any browser. Even IE deviates from it as  
you illustrate.


>    Q: Have you considered CSSOM's deviation with IE for div3b
>       above or is it something that needs to be fixed in the
>       spec?

I don't consider it a bug in the specification. The specification as is  
works with deployed content and works well in both quirks and no quirks  
mode. That's really all that matters as far as offset* is concerned, in my  
opinion.



> offsetLeft (and others)
> -----------------------
> Note: the example file assigns margin, border and padding to
> all elements including the HTML element. Values of these
> properties are indicated below in parenthesis (m,b,p) and the
> body of the table shows the value of offsetLeft:
>
> offsetLeft for/in:   IE7        FF2        CSSOM      simple?
> HTML(4m,2b,1p)       0          -2*        0          4
>  BODY(32m,16b,8p)    39**       -16*       0          33/HTML
>   div1(4m,2b,1p)     67**/HTML  47*/BODY   67***/BODY 12/BODY
>    div2b(32m,16b,8p) 33         31*        33         33
>     div3b(4m,2b,1p)  12/div2b   43*/div1   61/div1    12/div2b
>
> *   The Firefox algorithm seems to be completely different and
>     I have no guess on how to interpret this.
> **  The BODY=39 and div1=67 values actually are not the
>     distance to the border edge of the |HTML| element but
>     rather the distance to its margin edge or to the
>     viewport's left edge.
> *** The value 67 is actually not the distance to the border
>     edge of the |BODY| element but rather the distance to the
>     viewport's left edge.
>
> Apart from where noted, all offsets in the table add up
> correctly according to the "padding edge to border edge" rule.
>
> Adding some relative positioning, this is what happens:
>
> offsetLeft for/in:   IE7        FF2        CSSOM
> BODY left+10px       39->49     -16        0
> div1 left+10px       67->77     47->57     67->77
>
> So, to my observations:
>
> 3) As can be seen in both tables IE returns useful values for
>    BODY's offsetLeft property while CSSOM hardwires it to 0.
>
>    Q: What was the rationale for this deviation from IE's
>       behaviour?

This is because the HTML body element is special and not the HTML html  
element. (In the CSSOM specification anyway.) If we'd give "meaningfull"  
results for the HTML body element scripts that try to determine their  
position would go hopelessly wrong, because when offsetParent points to  
the HTML body element offset are given with respect to the initial  
containing block origin and not the padding edge of the HTML body element.


> 4) As can be seen in the upper table, CSSOM returns offsetLeft
>    = 67 for div1, which is the distance to the viewport edge or
>    margin edge of the |HTML| element, even though div1 reports
>    using BODY as offsetParent, thus:

Actually, not neccessarily the margin edge of the root element. The root  
element can be positioned just like any other element.


>      div1.offsetLeft = <distance to viewport/HTML>
>      div1.offsetParent = BODY
>    It would be more consistent to use
>      div1.offsetLeft = <distance to HTML>
>      div1.offsetParent = HTML
>    or
>      div1.offsetLeft = <distance to viewport>
>      div1.offsetParent = null
>    or
>      div1.offsetLeft = <distance to BODY>
>      div1.offsetParent = BODY

I agree that some of these would be more intuitive than special casing the  
HTML body element, but they are not more compatible with deployed content  
and various renderings modes. You're probably best of using  
getBoundingClientRect() plus pageXOffset/pageYOffset.


>    This change from IE's behaviour leads to returning an
>    offsetParent that isn't the element used when calculating
>    offsets, which is inconsistent.

Not if you consider the HTML body element to be special.


>    Suggestion: use one of the suggested combinations above,
>    probably best to return offsetParent = null or HTML.
>    (This relates to observation 1 above.)
>
>    [Btw it seems everybody is using margin edge instead of
>    padding edge when measuring from the |HTML| element]

And that's not inconsistent? The CSSOM specification is never measuring  
against the HTML html element though, as far as I can tell.

Kind regards,


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

Received on Monday, 17 March 2008 13:52:14 UTC