Re: [cssom-view] small update

Garrett Smith wrote:
> What users will have is a suite of tests that define exactly what the
> spec does.

That would be nice, but in practice they won't.  The problem here is the 
combinatorial explosion issue.

> The problem here is the assumption that Microsoft will implement the
> bad ideas, or ideas based on bugs, and in so doing, will break
> millions of pages.

Who is making this assumption, exactly?

> Making a spec out of buggy features is dumb. Waste of time.

If they have to be implemented anyway to be web-compatible, pooling 
reverse-engineering resources makes all the sense in the world.

> No, Boris, what you "get" is some frustration that you want to point
> at me.

Excuse me?  I'm not in any way invested in this discussion.  I'm just tired of 
content-less mails going by and both you and Anne wasting your time arguing 
about things that don't matter that much in some sense when it seems like we 
could be making progress on real problems here.

> my point is that CSSOM Views should be scrapped and rewritten.

So you've said.  Repeatedly.  You might even be right; I haven't even looked at 
this draft.

In the end, the decision is going to end up being made by the working group, the 
  W3C overall, and the implementors (in that order, more or less).

 > I do not appreciate being misrepresented, Boris.

You said "there are issues, but I'm not telling you about them."  I'm not sure 
what there is to misrepresent here....

> I started with offsetTop and the discussion fell apart.

Yeah, I noticed.  It seemed there were some fundamental disagreements on what 
the purpose of the specification was, so the technical discussion was more or 
less killed by them.

> The only sane approach would be not to waste time discussing a
> specification that is mostly bad and instead be proactive and produce
> a specification that might actually be useful.

Right.  But useful for what purpose?  To actually implement a web browser, one 
has to implement offsetTop.  Now there are two options.  Either every web 
browser implementor from now and forevermore will have to reverse-engineer the 
implementation, leading to more and more just slightly divergent 
implementations, or the reverse-engineering job will be done _once_ and then 
people can try to implement the result.  Like any reverse-engineering job it 
won't be pretty.  But there is a fundamental constraint here: compatibility with 
existing content.

None of this is that useful to an author, and I think there should be better 
APIs provided that authors can use (getBoundingClientRect, say).  If they are 
not in the draft and you have suggestions for them, please suggest them.  Even 
if you only have use cases that they should solve or design criteria they should 
satisfy, suggest that.  The fact is, the spec will likely need to cater to both 
authors and UA implementors.  For the former, it needs to provide useful tools. 
  For the latter, it needs to specify these tools in detail, as well as 
specifying existing things that authors will do no matter what.

> I think Microsoft should step up and be proactive in tackling this
> issue.

This would be nice, but thinking that someone else should do something doesn't 
go very far in terms of getting it to actually happen.

-Boris

Received on Friday, 11 April 2008 21:08:13 UTC