Re: [cssom-view] small update

On Mon, Mar 17, 2008 at 6:52 AM, Anne van Kesteren <annevk@opera.com> wrote:
>
>  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.

So the standard is based on quirks mode?

Why standardize quirks mode? I thought quirks was "non-standard"


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

What do you mean "Works well"?

(See the example below)

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


Is there a specification where BODY is the 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.
>
>

It is not something that any pages do and as far as I can remember,
had inconsistent results in browsers. Position: relative on BODY is
useful

It use useful because makes BODY a containing block for absolutely
positioned children; BODY margin affects absolutely positioned
children.


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

Problem:
How to measure the distance between a descendant its parentNode:

function distanceFromOffsetParent(el) {
  return {x:el.offsetLeft, y: el.offsetTop};
}


If el.offsetLeft is the distance from el to its parentNode, then the
function distanceFromOffsetParent will provide desirable results.

Sad path:
If the parentNode is BODY, then (even) if the parentNode has position:
relative and el has position, then the function will return the
distance between el and the edge of the document.

This is how CSSOM defines it, and in reality, it is a problem in Opera.

How should other browsers adopt this without breaking pages?

How does this concur with your Abstract:-

Abstract

The APIs introduced by this specification provide authors with a way
to inspect and manipulate the view information of a document. This
includes getting the position of element layout boxes, obtaining the
width of the viewport through script, and also scrolling an element.

-
?

Does the API have any distiguishable architecture by which it
accomplishes its goal? It seems to be a haphazard standarization of
preexisting properties and quirks behavior.

The non-standard features provided by browsers seem to be wrapped up
into a big ball of mud which will only grow larger with time. This
includes things like the ElementView interface including a "clientTop"
but no "clientBottom" and the WindowView interaface's "innerWidth"
property including scrollbar width (this is a bug that has plagued my
scripts all the way back to NS4 (!))

The only logical approach seems to study these non-standard features,
understand what they accomplish (or attempt to, as is the case), and
replace them with something better.

Garrett

>
>  Kind regards,
>
>
>
>
>  --
>  Anne van Kesteren

Received on Tuesday, 18 March 2008 18:55:22 UTC