Re: [cssom-view] small update

On Sun, Apr 13, 2008 at 3:44 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> Garrett Smith wrote:
>
> > How about:
> > Post Hoc Rathole?
> >
>
>  I'm not sure what the point of being deliberately offensive is here....
>

Then post hoc [what]?

Seems to me you're saying the the spec is for implementors, and that
the abstract should be post hoc. If that's true, then we're
standardizing existing properties. We've agreed that the properties
are of little use.

The point would be to be completely clear on exactly what this is.


>
>
> > Post hoc rathole aimed at making browsers other than Opera incompatible?
> >
>
>  That's basically an accusation that the editor is abusing his position.
> It's a pretty serious issue: if true, the editor should be replaced.
> I don't think this is what's going on, but perhaps there's overwhelming
> evidence I've missed.
>
>

I believe you may have missed some evidence, Boris. OffsetTop and
offsetParent have been redefined in ways that are opera-compatible and
only Opera compatible. One of those ways was mentioned over a year ago
by Mike Wilson twice, was ignored both times, and was just recently
corrected after being brought up again.

Another way, is that offsetTop has been defined in a way that works
differently when the offsetParent should be BODY, but in fact, the
spec defines it in a way that is only compatible with Opera. The
incompatibility affects every other browser. This has been pointed out
very clearly on the list. I attached a file, too. There should, at the
very least, be mention of these incompatibilities in the
specification.

It's in the archives:
http://lists.w3.org/Archives/Public/www-style/2008Mar/0198.html


>
> > 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.
> >
>
>  You need both.  A test suite can test various testcases.  Then one needs to
> do the job of synthesizing the results into something that can actually be
> implemented without having to re-analyze each testcase.
>
>  Note that no test suite for any feature or set of features like this can be
> complete, by the way.  The best we can do is an approximation of the whole
> thing.
>
>
>
> > Yes, it's not very useful. Developers use it cause it kinda does what
> > they want for some things.
> >
>
>  Sure.  But the upshot is that UAs have to implement it to be compatible
> with the web.
>
>
And they've already done that for some things and done a pretty awful
job at it. At least for offset* they have. ClientTop/Left seems to
work pretty well in Webkit and even Opera, AFAIK. The MSDN page with
the "DHTML is so cool." diagram has a clear example what clientTop
is/does.

>
> >
> > >
> > > > 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
> >
>
>  Not in all cases, actually...  At least not as the editor's draft is
> currently written.
>
"...
The width attribute, on getting, must return the width of the rectangle box.
Note: This is identical to right minus left.
..."

Seems to be the same as offsetWidth to me. I'm missing some edge case
with negatives or what?


>  But OK.  Perhaps I misunderstand what contentWidth is.  Is there a
> description somewhere that you can point me to?
>
>

I meant the css - width - property -- that's the content area width.
IE has a pixelWidth, and that is the content width, but pixelWidth
doesn't get the pixelWidth unless the style attribute has a width (of
any unit) set. clientWidth includes padding. There's no way to get the
- width - property off an element directly.

>
> > These new width and height properties have absolutely nothing to do
> > with compatibility, or rev-eng'ing a rathole.
> >
>
>  Agreed.  I seem to recall the argument being that they're a convenience for
> authors.  I can see how if getBoundingClientRect is generally returning the
> information I want those properties might conceivably be useful...
>
>  Your claim, on the other hand, is that getBoundingClientRect is just not
> returning the information you want, right?
>
>
No, that's wrong, sorry. It returns the information I want. I did
think it was worth mentioning that the new properties of - width - and
- height - were not necessary because they are covered by offsetWidth
and offsetHeight, but I now see that the offsetWidth property is a -
long - and box.width is a float, so it is giving some useful property,
even if offsetWidth is a more efficient call.

>
> >
> > > 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?
> >
>
>  I think it would make sense for the spec to include the "anything that's
> |float| in the IDL will include whatever accuracy the UA can provide"
> language, sure.
>
>
>
> > el.style.fontSize = "2px"
> > el.style.border = "4.1em solid"
> > var expected = 8.2;
> > var actual = el.clientTop;
> > assertEqual( expected, actual );
> >
>
>  In general, that assert would fail.  See above description of the rounding
> that happens for layout coordinates in Gecko, for example.
>
>
>
> > The problem with using - long - or - int - is that you lose precision.
> >
>
>  And the problem with not using it is incompatibility with existing scripts
> that already use those properties.
>
>

That is true. Programs rely on properties that are imprecise, not
because they want to; because there's nothing else and they sort of
work.


>
> > Cuumulatively, this can add up on border-width calculation when trying
> > to find a position. This is mentioned in the archives, BTW.
> >
>
>  Yes, that's why we just need a separate API (using float) for future use.
>
>
>
> > The abstract is self-contained. Your assumptions of what the CSSOM is
> > are not part of CSSOM.
> >
>
>  The CSSOM is whatever it specifies, from my point of view as an
> implementor. What it _claims_ to specify is more or less irrelevant to me.
> Of course it's nice when the claims match reality.
>
>

OK, so we're coming from different standpoints. You think it's nice if
it does what it claims to do, but want to have a specification that
allows you to implement them.

I would think that a test suite would be all you would need for
implementation. I also believe that a test suite would provide enough
awareness of the problems as to deem them unfit for a w3c spec.

The offset* properties, as specified, work different than
implementations, and the implementations, at least IE, are not going
to change to match Opera (bet $).

Last year, I thought it would be a good idea to have offset* and
pixel* properties spec'd out. I wrote a bunch of tests and the results
I found forced me to change my mind. Around that time, I did a lot of
research and ran into CSSOM. I saw many problems in it. I mailed Anne
but we didn't get very far (there's mention of this in the archives).
Then CSSOM Views showed up on the list and here we are today: Me
looking like the rude guy, Anne looking like the standards guy.

The reality of the matter is it's a rathole - admit it! Replace that
old stuff with useful stuff that works, is easy to implement, that is
a simple API.


>
> > 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.
> >
>
>  Yep.  For these "features" they just need to be specified so that others
> won't have to reverse-engineer them.
>

If a new implementation has a choice between:
make it work like:
1) CSSOM
2) IE
3) [another browser]

I'd hope that for the sake of usefulness, it would work like IE, cause
IE's offset* are not good, but they're certainly not as bad as the way
that CSSOM Views specifies them.

However, I'd really rather have something useful. I see many new
proposals, yet I still find myself wanting things like:

1) get the width of an element.
2) convert that to 'em' (so I can interpolate some values for a
transition/animation)

1) find the inherited/rendered style of an element.

>
>
> > 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?
> >
>
>  That bug's fix is waiting on a thorough reverse-engineering of IE, which is
> what Anne is working on, as far as I can tell.  Basically, this is one of
> those areas  where changing nothing is preferable to making random changes.
> Making non-random changes requires significant reverse-engineering.
>
>
But the spec is too different from what IE does. Mike Wilson raised
excellent questions on that:
http://lists.w3.org/Archives/Public/www-style/2008Mar/0197.html

And I brought up some points on that, too (linked above).


>
> > 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]"
> >
>
>  Yes....  If there is a need for another getter for some other width, such a
> getter should be added.  But changing innerWidth will simply break sites
> that work around the breakage in it now.
>
>

Agreed. I don't advocate breaking the web. In fact, there are scripts
out there that absolutely expect taht scrollbar width in there.

You know, I have a function that gets the viewport width, but the
testcase merely verifies that the result is a number. That's because
that is all that the testcase is capable of doing. That such a test
cannot be written and made to pass is a very clear indication of a
problem.

I fail to see the reason for making an official w3c document out of a bug.

>
> > 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
> >
>
>  Quality from whose point of view?
>

Do you have a different definition of quaility?


>
>
> > The CSSOM Views API mostly fails in terms of quality.
> >
>
>  I think there are two issues here that you're still conflating.  One issue
> is designing a useful API.  I have no comments on how well that's going,
> since I'm not sure anyone has even bothered to try yet.  The other issue is
> clearly documenting the expected behavior for legacy methods/properties.
> Quality for that is measured by how well the documented behavior matches the
> web and by no other metric.
>
>

They are two issues, and I have described them separately. Both issues
contribute to an argument for a new document and for scrapping the
existing one.
1) does it work?

In some places, CSSOM "works" in implementations as it is specified.
In other places it does not.

2) does it do something useful?

In some cases, these properties are useful.
In other use cases, there is a real need to get the clientBottom, and
have that in floating point number, or to get the width of the content
- area, as a float, either as pixel or from em calculation.


>
> > 1) It doesn't work. There are interop issues WRT existing
> > implementations which will not change
> >
>
>  "work" is not a on-off state.  Neither is "interop".  Something can work in
> limited ways; UAs can be mostly interoperable.  The goal of documenting the
> legacy API here is to increase the degree to which they're interoperable.
>
Unfortunately, the way offsetTop is specified, it introduces a change.
This is a change which Opera -- and only Opera -- adopted very early
on.

That change is one that I linked above.

I do now know which came Opera's implementation of the change
introduced by CSSOM Views, or the change introduced by CSSOM Views
where BODY can't be an offsetParent. Anne, can you please tell us
which one came first? Was it Opera's bug that made it into the spec,
or is is a new feature that Opera was early to adopt?



Another introduction in CSSOM:
"The computed value of the position property of A is static and the
ancestor is one of the following HTML elements: td, th, or table."

Which is not at all what IE, Mozilla, or Opera do. An element becomes
eligible to be an offsetParent if it has position:relative, but that
goes right against exactly what the spec says.

               <table>
                    <tbody>
                        <tr id="tr">
                            <td>hey</td>
                            <td style="position: relative"><div
id="divTD1" style="position:relative">hi</div></td>
                        </tr>
                    </tbody>
               </table>


javascript:alert(document.defaultView.getComputedStyle(document.getElementsByTagName("td")[0],'').position)

Indicates "static" in Safari, yet the TD is the offsetParent. Until
the div has position: relative removed, then BODY is offsetParent.

               <table>
                    <tbody>
                        <tr style="position: relative" id="tr">
                            <td id="TD1">hey</td>
                            <td><div id="divTD1"
style="position:relative">hi</div></td>
                        </tr>
                    </tbody>
               </table>

writeUpTree('TD1');

What's the offsetParent of TD1? Turns out that a bug in Webkit makes
it agree with CSSOM. IMO it's so complicated that it should not be
standardized. no matter what, it will break implementations. They
don't agree. What's worse is that CSSOM Views specifies offset* in a
way that is less desirable and also conflicts with current
implementations.

Tired hands.


Garrett

>
>
> > 2) it isn't useful. I finally seem to have gotten confirmation on this
> > from Boris.
> >
>
>  "useful" is also not an on-off state.  It's not as useful as a
> better-designed API might be, by any means.  Perhaps some energy should be
> spent designing this better API instead of beating the dead horse of
> "offset* and client* suck". Yes.  They suck.  They still need to be clearly
> specified.
>
>
>
> > Not only that, but the CSSOM Views contains 11 interfaces and I think
> > 5 are new
> >
>
>  For what it's worth, interface count is not that useful as a metric of
> anything.  Some of what I see here is that the same methods are being added
> to different types of objects (e.g. elements and ranges) and have to have
> slightly different behavior, so you end up with multiple interfaces with
> identically-named methods.
>
>
>  > 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.
> >
>
>  I'm not sure what you mean here.  If you mean that the interfaces an
> Element, say, implements are scattered across multiple specifications,
> that's just a general consequence of the way the W3C works....
>
>
>
> > 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.
> >
>
>  It might be garbage from your point of view as an author.  It's rather
> useful to me as an implementor.  We have very different needs out of a spec.
> Ideally, it would cater to both.  But don't expect it to cater to only your
> needs and neglect mine, just as I don't expect it to specify the legacy
> methods only without introducing better APIs for authors to use.
>
>  -Boris
>

Received on Monday, 14 April 2008 07:16:00 UTC