Re: [cssom-view] small update

Garrett Smith wrote:
> Seems to me you're saying the the spec is for implementors

In general... yes.  The spec is telling the implementors how their 
implementation should behave.  The implementors aren't the only stakeholders, of 
course, but a spec that doesn't define how the implementations should behave is 
pointless.

> and that the abstract should be post hoc.

Just that I'd do it that way.

> If that's true, then we're standardizing existing properties.

Yes, offset* and client* and getBounding* are pretty much existing.

> We've agreed that the properties are of little use.

That has little to do with whether they need standardizing.  What's important 
for that is whether they're used, not whether they're useful.

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

Sounds like an oversight that was fixed to me....

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

I assume there was a formal issue raised on this, if it's a problem?

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

I'll be honest...  it's hard to look at that mail and say "here is a problem in 
the spec."  An ideal issue e-mail would be short, and would say up front what 
the problem is, then have evidence as needed....  If I were the editor of this 
spec, I'd have had a hard time converting that mail to a useful trackable issue.

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

You're missing the case when there are multiple boxes generated by the element, 
I think.  For example, a <span> containing a <div> containing a <table>.  As 
specified in the editor's draft right now, offsetWidth doesn't really handle 
that situation the same way that getBoundingClientRect().width does.

> I meant the css - width - property -- that's the content area width.

Ah.  Yeah, that seems like it could be a useful addition.  Was there a mail that 
suggested adding it (and didn't contain anything other than this suggestion)?

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

Sure.  But the history doesn't matter for what we do going forward, in this 
case.  That's just life when de-jure standardizing de-facto standards.

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

Yes.

> I would think that a test suite would be all you would need for
> implementation.

Uh... no.  A test suite would be equivalent to reverse-engineering (the test 
suite, in this case).  The issue is that going from test suite to code requires 
an inductive step where you create some rules (your code) based on data (the 
tests).  We want all UAs to perform this step identically, so that when they're 
tested on some test that is NOT in the test suite, they behave identically.

> I also believe that a test suite would provide enough
> awareness of the problems as to deem them unfit for a w3c spec.

Well... To become a REC, this draft will need a test suite, and at least two UAs 
passing it.  If you think that this is impossible, it'll just never become a REC.

> Me looking like the rude guy, Anne looking like the standards guy.

Anne's looking like a not-that-responsive-editor guy to me, but whatever.

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

We need both, as I keep saying.  Making it possible for UAs to sanely implement 
the legacy stuff, and new better APIs for authors.  You care only about the 
latter.  I care about both.

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

Ideally some of these choices would coincide.

Note that item 1 is a lot easier than item 2, so if in practice web page compat 
is good enough with item 1, a new impl should go for item 1.

> 1) get the width of an element.

I agree that this should be added.

> 2) convert that to 'em' (so I can interpolate some values for a
> transition/animation)

I'm not sure why "em" is needed for that, to be honest...

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

This has definitely come up before.  I would assume that another part of CSSOM 
would provide it.

> But the spec is too different from what IE does.

That could be a problem.

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

If all UAs have to implement that bug in practice... then it's worth it, 
perhaps.  Many parts of existing specs have exactly such origins.

> Do you have a different definition of quaility?

For a specification, sure.

1)  Implementing it in my UA will make my UA more
     useful to users or authors.
2)  I can implement it as written.

Of course from an author's point of view those are not the most important 
criteria, by any means.

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

If Anne actually reads this question, I'll be very surprised.  If you want to 
raise and issue with the editor, send out a mail about that issue and _only_ 
that issue.  Anything else is just asking for the issue to be missed.

> IMO it's so complicated that it should not be
> standardized. no matter what, it will break implementations.

That might be acceptable to the implementors.  That is, some of them may not 
mind switching from what they do now to whatever gets specified if the result is 
simple and has decent web compat.

> They don't agree.

Yes.  Of course.  That's because they all reverse-engineered independently.

> What's worse is that CSSOM Views specifies offset* in a
> way that is less desirable and also conflicts with current
> implementations.

That sounds like an issue that should be explicitly raised.

-Boris

Received on Monday, 14 April 2008 08:31:52 UTC