Re: [cssom-view] small update

On Fri, Apr 11, 2008 at 6:59 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> Garrett Smith wrote:
>
> > Even if offsetTop were reverse engineered accurately, which it isn't,
> > it would still have problems.
> >
>
>  Yes.
>
>
>
> > Does the abstract need a rewrite?
> >
>
>  To be honest, the abstract should be the last part written, imo.  And even
> then, it will at best imperfectly capture what's going on.  That's the
> nature of absracts.
>
>
How about:
Post Hoc Rathole?

Or:

Post hoc rathole aimed at making browsers other than Opera incompatible?

Boris, if you really want to know what IE does, the answer is not to
write a document. That is useless and pretentious. Write a test suite.


>
> > 1) clientLeft/Top - is fine in a RTL world with only top/left
> > positioning where pixels are rounded.
> >
>
>  This is the same as offsetTop.  It needs to be specified for UA interop,
> but it's pretty poor as authoring APIs go.
>
>

Yes, it's not very useful. Developers use it cause it kinda does what
they want for some things.


>
> > 2) no contentWidth or analagous property -
> > 3) offsetTop/Parent is broken by design - can't reliably determine the
> > distance between 2 arbitrary elements
> >
>
>  I think the getBoundClientRect/getClientRects APIs cover all these issues,
> no?
>
>

No . getBoundingClientRect now has a new 'width' and 'height'
property. It's going to be the same as offsetWidth and offsetHeight,
which is redundant. I mentioned this before it got added.

These new width and height properties have absolutely nothing to do
with compatibility, or rev-eng'ing a rathole.


>
> > 5) unclear on whether a CSS Pixel will include decimal precision
> >
>
>  Probably implementation-dependent, for what it's worth.  I would assume
> that anything that's |float| in the IDL will include whatever accuracy the
> UA can provide.  In that case of Gecko, say, that means it'll first be
> rounded to the nearest 1/60 of a CSS pixel and then rounded to the nearest
> floating-point number expressible on the architecture the browser is running
> on.  That sort of thing.
>

Why should you have to speculate? Shouldn't the spec be clear exactly
what it does?

el.style.fontSize = "2px"
el.style.border = "4.1em solid"
var expected = 8.2;
var actual = el.clientTop;
assertEqual( expected, actual );

>  This does raise an interesting question.  The offset* properties are
> declared as floats in the IDL in the spec.  I don't think that's compatible
> with implementations, and worse yet it's not really compatible with
> content...
>

I asked the question over and over with the example of clientTop in
previous posts.

The problem with using - long - or - int - is that you lose precision.
Cuumulatively, this can add up on border-width calculation when trying
to find a position. This is mentioned in the archives, BTW.

Not very useful.


>
>
> > Screen -
> > These properties do not seem to have anything to do with the CSSOM
> abstract.
> >
>
>  I guess I pretty much expect the abstract to have nothing to do with the
> meat of things....
>
>

The abstract is self-contained. Your assumptions of what the CSSOM is
are not part of CSSOM. They're just your assumptions that thrive on
the vagueness with which this spec was written.

Many of the CSSOM Views' features already implemented cross-browser.
Of those already implemented things, many are not that practical. In
part because of the way they're defined, and, in the case of offset*
and co, because they're implemented differently.

I'm sorry, but Mozilla had over 4 years to fix this bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=255754

Is CSSOM Views is going to fix that?

CSSOM Views can't fix innerWidth either, so it leaves it broken.
"The innerWidth attribute, on getting, must return the viewport width.
[including the scrollbar]"

That "[including the scrollbar]" is the intent of the spec, but is
omitted from the spec. It is a bug from Netscape 4.


Quality can be defined by
1) it works
2) it does something useful

The CSSOM Views API mostly fails in terms of quality.

1) It doesn't work. There are interop issues WRT existing
implementations which will not change
2) it isn't useful. I finally seem to have gotten confirmation on this
from Boris.

Not only that, but the CSSOM Views contains 11 interfaces and I think
5 are new, while others come from other APIs. Makes it hard to write a
test suite for an object implementing X if X is defined in n places.

The one thing that CSSOM Views does have is getBoundingClientRect.
While it's a good feature, it doesn't pull the rest of the spec (which
is mostly garbage) through.

You can take getBoundingClientRect, add it to your use stories, make a
failing test for it, make it pass. The place where you put the test
will be the interface that it goes on. No BUFD. Just a simple, useful
feature. Easy for everyone to find.

Thank you,

Garrett
>
> > Breaking all this down, rehashing it -- is time and energy consuming.
> > ...."
> >
>
>  I can see that.  Ideally, the above points would have made it into the
> relevant issues list.
>

I have mentioned many other problems in the archives. I'm not sure who
maintains that issues list. Do they read this forum?


Garrett

>  -Boris

Received on Saturday, 12 April 2008 17:12:10 UTC