Re: [cssom-view] small update

On Fri, Apr 11, 2008 at 3:34 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> [I assume this was off-list on purpose.[

No, sorry, I'm going to put it back on the list.

I hate it when I do that.

>
>
>  Garrett Smith wrote:
>
> > 1) How long before all implementations are compatible with the
> > re-engineered and/or reverse-engineered stuff?
> >
>
>  Depends on their priorities and shipping schedules...
>
>
>
> > 2) After (1), will the features solve problems that they attempt to solve?
> >
>
>  I don't see offset* as attempting to solve a problem, to be honest.  If it
> is, it's failing.  This is the case no matter how you try to specify it.
>

Good point. OffsetTop isn't a great solution. The abstract of the spec
indicates that the spec is aimed at helping authors solve problems.
offsetTop, as a proposed solution, "does something" in browsers. That
something depends on the browser and the document and the elements
it's used on. As webapps get more advanced, they start to realize
these problems and create functional abstractions to find element
positions, where these abstractions address the variations in use
cases of offset* in browsers. The specification falls short of it's
promise:

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

Even if offsetTop were reverse engineered accurately, which it isn't,
it would still have problems.

Does the abstract need a rewrite?

>
>  Hmm.  Perhaps this time it's I who misread.  You said (quoting from the
> archive),
>
Here's a snip of what I wrote from the thread you replied:--
"
There are several significant problems:
1) clientLeft/Top - is fine in a RTL world with only top/left
positioning where pixels are rounded.
2) no contentWidth or analagous property -
3) offsetTop/Parent is broken by design - can't reliably determine the
distance between 2 arbitrary elements
4) WindowView - includes a bug from Netscape 4 - innerWidth including
scrollbar width (has cost a lot of developer time)
5) unclear on whether a CSS Pixel will include decimal precision

The package design is questionable. For example:
MouseEventView  - contains a - pageX - and an alias - x - property. I
do not see the point in this. Is this really necessary?
Should MouseEventView be packaged as a part of MouseEvents?

Screen -
These properties do not seem to have anything to do with the CSSOM abstract.

Breaking all this down, rehashing it -- is time and energy consuming.
...."
-- 

It was to provide an overview of problems in the spec and that's all
it was meant to be. That's a big difference than "I'm not telling
you." That's what I took offense to.


>
> >
> > >  Right.  But useful for what purpose?
> > >
> >
> > It's called progress.
> >
>
>  That's so vague as to be meaningless.  Any time we say "X is useful",
> that's a shorthand for "X can by used by Y to accomplish Z".  The real
> question is what X, Y, and Z are.
>

1) make a specification of [properties that aren't very good but get
used 'cause there's nothing else] (reinvented), and define them in a
new way
2) reverse engineer accurately (rev eng'd)
3) make something good and useful
4) strike some sort of middle ground between 2 and 3.

* There's no real need for IE to adopt a new version of offsetTop. Nor
Mozilla, nor Webkit.
* There's no reason for IE to implement innerWidth as specified. It's
not useful to have the scrollbar width. Finding the dimensions of the
document (no scrollbars), cross-browser, is painful.
* clientTop should not be hard to rev eng, but it's one of those "not
very good" properties that should really be replaced by something
better. The value never includes a floating point decimal, that much
is for sure.

The spec doesn't really follow the abstract, as far as I see it.

[snip]

Garrett

>  -Boris
>

Received on Friday, 11 April 2008 23:23:02 UTC