Re: [cssom-view] small update

On Wed, Apr 9, 2008 at 10:05 AM, Anne van Kesteren <annevk@opera.com> wrote:
>
>  On Wed, 09 Apr 2008 18:07:52 +0200, Ambrose Li <ambrose.li@gmail.com>
> wrote:
>
> > The problem with assuming that IE "can fix it" is that IE is not
> upgradable on legacy systems, and people are still using legacy systems. 40%
> of "my"
> > site's visitors are still using IE 6 and another 40% IE 7, and anyone
> using IE 6 will not upgrade to IE 8+ any time soon. Any attempt to
> standardize
> > quirks mode must take into account IE's existing behaviour and not
> > assume that IE can "fix" anything.
> >
>
>  This problem is not exactly unique to what we are discussing here. Updates
> to CSS (and other Web specifications) in general will not always migrate to
> such environments until they are updated.
>

Then update the specification, Anne, so we can see if the updates
migrate. If there has been updates, do not keep them to yourself.

Regardless, the API seems to miss it's mark. It stars off good:

"The APIs introduced by this specification provide authors with a way
to inspect and manipulate the view information of a document. This
includes getting the position of element layout boxes, obtaining the
width of the viewport through script, and also scrolling an element."

But it doesn't follow through.

There are several significant problems:
1) clientLeft/Top - is fine in a RTL world with only top/left
positioning where pixels are rounded.
2) no contentWidth or analagous property -
3) offsetTop/Parent is broken by design - can't reliably determine the
distance between 2 arbitrary elements
4) WindowView - includes a bug from Netscape 4 - innerWidth including
scrollbar width (has cost a lot of developer time)
5) unclear on whether a CSS Pixel will include decimal precision

The package design is questionable. For example:
MouseEventView  - contains a - pageX - and an alias - x - property. I
do not see the point in this. Is this really necessary?
Should MouseEventView be packaged as a part of MouseEvents?

Screen -
These properties do not seem to have anything to do with the CSSOM abstract.

Breaking all this down, rehashing it -- is time and energy consuming.

I think a better API could be written with fewer, more closely related
interfaces, with massive improvements in flexibility, and (big part)
without breaking the web any more. I don't have much experience with
w3c spec writing process; it sure is a killer huh?

To address the issues of the current CSSOM one at a time would be too
time consuming due to the recent communication breakdowns witnessed by
other list subscribers, who have also expressed their frustrations.

Designing a new API would be faster and would avoid problems of design
by committee. It would be useful, would break nothing, and would be
easy for vendors to implement. It would provide a proactive response
to a problem.

CSSOM Views may make it through the various phases replete with the
aforementioned problems.

Garrett



>  --
>  Anne van Kesteren

Received on Thursday, 10 April 2008 03:17:35 UTC