Re: [cssom-view] small update

On Thu, Apr 10, 2008 at 4:02 AM, Anne van Kesteren <annevk@opera.com> wrote:
> On Thu, 10 Apr 2008 05:16:55 +0200, Garrett Smith <dhtmlkitchen@gmail.com>
> wrote:
>
> > Anne wrote:
> >
> > > 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.
> >
>
>  I don't understand this comment. The editor's draft reflects the latest
> version. It is located here:
>

It is a direct response to your statement, just above it. Your
sentence that updates won't always migrate until they're updated, So I
assumed that to mean there were updates that hadn't been updated on
the spec.

>
> > 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.
> >
>
>  I have a feeling I addressed all these comments already, but I suppose I
> can do it one more time.
>
>

Most of these issues haven't been mentioned yet. Mostly because I made
no headway in earlier attempts at discussion with you (communication
breakdown).

It's just a self-righteous, self-serving, useless statement. I think I
said you were arrogant before, well, here's exactly what I'm talking
about.


>
>
> > There are several significant problems:
> > 1) clientLeft/Top - is fine in a RTL world with only top/left
> > positioning where pixels are rounded.
> >
>
>  I rather not add more client*/scroll*/offset* attributes for now. Lets see
> how this specification goes and then maybe add them to a future version.
>
>
>
>
> > 2) no contentWidth or analagous property -
> >
>
>  I'd like to defer this to a future version as well.
>
>
>
>
> > 3) offsetTop/Parent is broken by design - can't reliably determine the
> > distance between 2 arbitrary elements
> >
>
>  There is another API in the specification you could use for this if offset*
> doesn't work for you.
>

If a feature is broken, it should be removed. Remove the broken feature.


>
>
> >
> > 4) WindowView - includes a bug from Netscape 4 - innerWidth including
> > scrollbar width (has cost a lot of developer time)speci
> >
>
>  Unfortunately we cannot change this now. In a future version we could add a
> new attribute that does not include the scrollbar I suppose.
>

You can remove the property from the spec.

>
>
>
> > 5) unclear on whether a CSS Pixel will include decimal precision
> >
>
>  I already explained several times that this is clear because of the IDL
> interfaces used for the attributes.
>
>
No, you didn't you. Instead, you said things like:" A CSSPixel is a
CSSPixel". This went on for about 4 mails. I went into a discussion
about clientTop, provided an example, added context to the problem,
and asked and whether the value should be rounded. Didn't ever get any
answer. It's all in the archives.


>
>
> > 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?
> >
>
>  User agents have implemented both so it makes sense to specify that.
>

UserAgents do a lot of things.. There's really no need for tow properties.


>
>
>
> > Should MouseEventView be packaged as a part of MouseEvents?
> >
>
>  The way I've done it in this specification is consistent with other DOM
> specifications as far as I can tell so I think it is ok.
>
>

It's harder to understand an interface if it is not clearly defined in
one place.

>
>
> > Screen -
> > These properties do not seem to have anything to do with the CSSOM
> abstract.
> >
>
>  They can be useful for when the document is displayed fullscreen. The color
> related attributes seem to affect the visual view of the document so they
> also seem useful.
>
>

The only case I can see is for those porn sites that want to make the
window fill up the screen.

>
>
> > 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?
> >
>
>  Making a new API doesn't solve existing problems. Having two APIs to do the
> same thing is also bad practice, even if the new API is so much better. This
> is one of the reasons we're standardizing on XMLHttpRequest and not on a new
> API that does the same thing.
>
>
>
>
> > 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.
> >
>
>  What kind of communication breakdowns are you speaking of? Members of the
> CSS WG are engaged in the discussions. That list subscribers do not always
> get what they want doesn't mean there's a communication breakdown.
>
>

LOL. That's too funny!

I don't want to rake over the coals again. I've had some issues WRT to
unresponded mails, overly snipped messages, responses that completely
missed the point, tangential discussion.

Saying things like "That list subscribers do not always get what they
want doesn't mean there's a communication breakdown" shows that you
really do want to play these silly games and rake back over the coals.
It's a diversion from talking about the API and I'm not going to
indulge you on that one.

>
>
> > 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.
> >
>
>  Calling the defined API the result of design by committee is missing the
> point I think -- it's a de facto standard.
>

Nobody called it Design by Committee. Go back and reread that a few more times.

>
>
>
> > CSSOM Views may make it through the various phases replete with the
> > aforementioned problems.
> >
>
>  I'm not sure what this means.
>

THe different phases are what w3c calls "status" -- Last Call, WOrking Draft.

>
>
>  --
>  Anne van Kesteren

Received on Friday, 11 April 2008 17:28:48 UTC