Re: [cssom-view] small update

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:

   http://dev.w3.org/csswg/cssom-view/



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


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


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


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


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


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


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


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


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


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

I'm not sure what this means.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Thursday, 10 April 2008 11:02:31 UTC