Re: [cssom-view] small update

Garrett Smith wrote:
> How about:
> Post Hoc Rathole?

I'm not sure what the point of being deliberately offensive is here....

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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 Sunday, 13 April 2008 22:45:30 UTC