[cssom-view] small update

[Anne van Kesteren-2]

Hi,

I made a few small changes in how the APIs are defined (clearer  
definitions, I think) and added AbstractView from DOM Level 2 Views. I  
also renamed WindowView to ScreenView and defined it to be for visual  
media only. I also moved offset*, scroll*, and client* attributes to their  
own interface that will only function for objects implementing  
HTMLElement. As roc mentioned on this list they're not that useful now we  
have getClientRects() and getBoundingClientRect() so we might as well  
restrict them for now.

I also fixed small mistakes as reported on a blog entry by Peter-Paul Koch:

   http://www.quirksmode.org/blog/archives/2008/02/the_cssom_view.html

The updated editor's draft can be found here:

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

I think it's ready for Last Call.

Kind regards,


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

[Robert O'Callahan-3]

A few comments...

You might want to clarify in getBoundingClientRect what an "empty" border-box is. In our implementation, we consider a box empty if its width OR height is zero. IE considers a box empty if the width AND height are zero. (I think our definition is more useful, e.g. if you're trying to scroll an element into view, or you want to draw the bounding box of the element.)

In our implementation of getBoundingClientRect, if all the client rects are empty, getBoundingClientRect just returns the first one. That might not have bottom == top or left == right. This seems to be more useful than what the spec says. I don't remember what IE does.

For table elements, getClientRects returns a rect for the table border-box and a separate rect for the caption if one is present (both in Gecko 1.9 and IE7 IIRC). You might want to mention this in the spec.

Anonymous block boxes such as those created for block-in-inline splits are "drilled into" by getClientRects. So for example, given
<span>Foo <div style="width:50px; height:50px;"></div> Bar</span>
the span would have three client rects, one for the first inline, one for the <div> (with width 50px), and one for the last inline. This is true in both Gecko 1.9 and IE7 and it matters for Web-compatibility.

For SVG elements, which don't really have border-boxes, our implementation of getClientRects returns a single rect which is the bounding-box of the SVG element.

In our implementation, if an element is a descendant of an SVG foreignObject, we treat the nearest enclosing foreignObject as establishing the viewport for the element for the purposes of getClientRects and getBoundingClientRect. It doesn't seem to make sense to use the true viewport in the presence of possible SVG transformations.

Thanks,
Rob
--
"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]

[Garrett]

---------- Forwarded message ----------
From: Garrett Smith <dhtmlkitchen@...>
Date: Thu, Mar 6, 2008 at 12:35 PM
Subject: Re: [cssom-view] small update
To: Anne van Kesteren <annevk@...>


On Thu, Mar 6, 2008 at 4:22 AM, Anne van Kesteren <annevk@...> wrote:
 >
 >  Hi,
 >
 >  I made a few small changes in how the APIs are defined (clearer
 >  definitions, I think) and added AbstractView from DOM Level 2 Views. I
 >  also renamed WindowView to ScreenView and defined it to be for visual
 >  media only. I also moved offset*, scroll*, and client* attributes to their
 >  own interface that will only function for objects implementing
 >  HTMLElement. As roc mentioned on this list they're not that useful now we
 >  have getClientRects() and getBoundingClientRect() so we might as well
 >  restrict them for now.
 >
 >  I also fixed small mistakes as reported on a blog entry by Peter-Paul Koch:
 >
 >    http://www.quirksmode.org/blog/archives/2008/02/the_cssom_view.html
 >
 >  The updated editor's draft can be found here:
 >
 >    http://dev.w3.org/csswg/cssom-view/
 >
 >  I think it's ready for Last Call.

 Not without more tests its not.

 The way you've spec'd offset* doesn't really reflect what browsers do.

 You seem to be in denial about this, or are unwilling to investigate
 the matter more. You also seem to want to avoid a lot of questions and
 don't want to test. I'm not sure what the reluctance is. What is the
 problem, Anne?




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

[Anne van Kesteren-2]

On Thu, 06 Mar 2008 21:36:29 +0100, Garrett Smith <dhtmlkitchen@...>  
wrote:
>>  I think it's ready for Last Call.
>
>  Not without more tests its not.

Formal tests are typically done during Candidate Recommendation stage.


>  The way you've spec'd offset* doesn't really reflect what browsers do.

As far as I can tell it matches three out of four browsers relatively  
well. Not perfect yet, of course, but that's to be epxected.


>  You seem to be in denial about this, or are unwilling to investigate
>  the matter more. You also seem to want to avoid a lot of questions and
>  don't want to test. I'm not sure what the reluctance is. What is the
>  problem, Anne?

I have tried to answer your questions, but it seems we simply disagree on  
what the specification should be based. I'm not sure why you keep being so  
hostile in your comments as I mean no harm.


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

[Garrett]

On Thu, Mar 6, 2008 at 12:55 PM, Anne van Kesteren <annevk@...> wrote:

> On Thu, 06 Mar 2008 21:36:29 +0100, Garrett Smith <dhtmlkitchen@...>
>  wrote:
>
> >>  I think it's ready for Last Call.
>  >
>  >  Not without more tests its not.
>
>  Formal tests are typically done during Candidate Recommendation stage.
>
>
>
>  >  The way you've spec'd offset* doesn't really reflect what browsers do.
>
>  As far as I can tell it matches three out of four browsers relatively
>  well. Not perfect yet, of course, but that's to be epxected.
>

Even a basic, simple test would fail what CSSOM:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang="en">
 <head>
  <title>offset: margin on BODY</title>
  <script src="support/test.js"></script>
  <link rel="stylesheet" href="support/test.css">
  <style>
   body { margin:10px; position: relative; }
   #t { position: relative; top: 0 }
  </style>
 </head>

 <body>
  <p id="t">TEST</p>
  <hr>
  <script> test('BODY', 10, 10) </script>
 </body>
</html>

This is testing the AVK CSSOM Spec. I do not agree with the expected
result which (coincidentally) is only attained in Opera.

This is not an edge case at all.There are also more complex, yet
benign examples which will fail.

But since I (and the other 3 browsers) do not agree on the expected
result, it seems only fair to ask the question:"What should the
expected result be?"

To answer this question, I think a test is the best approach. I do not
think this is unreasonable. Nor do I find it to be inappropriate.
Putting up little tests on each thread is not exactly the way to
maintain a test suite.

Spec'ing existing features is not the same thing as designing
futuristic HTML 5 features. If you make stuff up, it causes problems.

There's still an unanwsered email in the archives, and plenty of questions.

Garrett

>
>
>  >  You seem to be in denial about this, or are unwilling to investigate
>  >  the matter more. You also seem to want to avoid a lot of questions and
>  >  don't want to test. I'm not sure what the reluctance is. What is the
>  >  problem, Anne?
>
>  I have tried to answer your questions, but it seems we simply disagree on
>  what the specification should be based. I'm not sure why you keep being so
>  hostile in your comments as I mean no harm.
>

You're calling me hostile, huh?

Things like putting: "..." after I asked you if you're waiting for me
to get tired replying should be considered what, "harmless"? Some
questions I've asked have been snipped, unanswered or answered
carelessly, and I've had to repeat the questions, which has led away
from the original point.

It is difficult for me to participate in a discussion with such distractions.

Now, regardless of my own opinion on your behavior, there are several
problems with the spec. Condemning you as harmless would do nothing to
improve the spec, would it?

There's still an unanwsered email back in the archives, if I'm not mistaken.

Garrett

>
>  --
>
>
> Anne van Kesteren

[Anne van Kesteren-2]

On Thu, 06 Mar 2008 23:00:55 +0100, Garrett Smith <dhtmlkitchen@...>  
wrote:
> Even a basic, simple test would fail what CSSOM:

What do you mean?


> [...]
>
> This is testing the AVK CSSOM Spec. I do not agree with the expected
> result which (coincidentally) is only attained in Opera.

Given the other constraints I think this result makes the most sense, but  
if I'm open to suggestions on how to improve various algorithms.


> This is not an edge case at all.There are also more complex, yet
> benign examples which will fail.

Please tell!


> But since I (and the other 3 browsers) do not agree on the expected
> result, it seems only fair to ask the question:"What should the
> expected result be?"

See above.


> To answer this question, I think a test is the best approach. I do not
> think this is unreasonable. Nor do I find it to be inappropriate.
> Putting up little tests on each thread is not exactly the way to
> maintain a test suite.

I'm not sure what you're talking about.


> Spec'ing existing features is not the same thing as designing
> futuristic HTML 5 features. If you make stuff up, it causes problems.

Most of HTML 5 is exactly in the same ballpark, so it's unclear to me what  
point you're trying to make here.


> There's still an unanwsered email in the archives, and plenty of  
> questions.

If you mean  
http://lists.w3.org/Archives/Public/www-style/2008Feb/0339.html I was  
hoping you would finish it first.


> You're calling me hostile, huh?

Yes.


> Things like putting: "..." after I asked you if you're waiting for me
> to get tired replying should be considered what, "harmless"?

It was simply to mark a continuation of the previous sentence I wrote.  
FWIW, you sounded hostile in that e-mail too.


> Some questions I've asked have been snipped, unanswered or answered
> carelessly, and I've had to repeat the questions, which has led away
> from the original point.

It's still not exactly clear to me what your problem is, apart from that  
you found some cases that you think should work differently from the  
specification. It's also not clear to me what your desired solution is and  
why that would work better than what is currently in the specification.


> Now, regardless of my own opinion on your behavior, there are several
> problems with the spec. Condemning you as harmless would do nothing to
> improve the spec, would it?

I'm not sure what this means.


> There's still an unanwsered email back in the archives, if I'm not  
> mistaken.

See above.


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

[Ambrose Li-3]

On 06/03/2008, Anne van Kesteren <annevk@...> wrote:
>
>  On Thu, 06 Mar 2008 23:00:55 +0100, Garrett Smith <dhtmlkitchen@...>
>  > Spec'ing existing features is not the same thing as designing
>  > futuristic HTML 5 features. If you make stuff up, it causes problems.
>
>
> Most of HTML 5 is exactly in the same ballpark, so it's unclear to me what
>  point you're trying to make here.

I can't believe this complete breakdown in communications.

But I agree with GS that this should not be handled in the same way as
HTML 5. The two are not in the same ballpark.
--
cheers,
-ambrose

Yahoo and Gmail must die. Yes, I use them, but they still must die.
PS: Don't trust everything you read in Wikipedia. (Very Important)

[Garrett]

On Thu, Mar 6, 2008 at 8:40 PM, Ambrose Li <ambrose.li@...> wrote:
> On 06/03/2008, Anne van Kesteren <annevk@...> wrote:
>  >
>  >  On Thu, 06 Mar 2008 23:00:55 +0100, Garrett Smith <dhtmlkitchen@...>
>

>  I can't believe this complete breakdown in communications.
>

OK, so I ran this thread by a friend and she told me that I was being
a jerk. So for that I offer my apology. Rereading it, it does sound a
little hostile. That's not my goal.

I will try to provide more tests from the format I have (automated
suite) to the format used by the CSSOM Spec.

Garrett

>  cheers,
>  -ambrose
>
>  Yahoo and Gmail must die. Yes, I use them, but they still must die.
>  PS: Don't trust everything you read in Wikipedia. (Very Important)
>

[Bjoern Hoehrmann]

* Anne van Kesteren wrote:
>   http://dev.w3.org/csswg/cssom-view/

You need a reference to DOM Level 2 Views. DOM Level 2 Views defines how
the module interacts with the DOM .hasFeature(...) and related methods,
but such a definition is absent from your draft. Since it is meant to
update the older DOM module, you need to have some discussion of this.

The specification ought to have some kind of introduction that puts it
into some context beyond what you say in the Abstract of the document.

"The HTML body element is the first body HTML element child of the root
HTML element html." might be better written as "In documents whose root
element is the HTML element html, the HTML body element is the first
body HTML element child of the root element, if any." The current text
is unclear whether <svg ...><html ...><body> is a HTML body element, at
least assuming obvious definitions of the terms.

In section 2.1 you have a [CSS21] reference that is no link and has no
entry in the References section. Why is the method called "query"? I'd
think an .isX, .hasX, .canX, .supportsX, .doesX, ... name would be more
appropriate.

I don't quite understand the colorDepth and pixelDepth attributes.

The elementFromPoint(...) method takes two integers that specify the
point. Could you comment on why, other than status quo, these should not
be floats? Many of the interfaces in the document specify coordinates as
floats. If the arguments are to be integers, perhaps a note about that
would be useful.

For RangeView.getBoundingClientRect(...) you have:

  3. Otherwise, return a union of the boxes in list, excluding boxes
     that are empty, as a single TextRectangle object. If all boxes are
     empty let the top attribute of the new TextRectangle object be the
     value of the top attribute of the first border box in the list
     returned. Do likewise for left and then let bottom be equal to top
     and right to left.

Couldn't this be written as follows:

  3. Otherwise, return a (static) TextRectangle object describing the
     smallest rectangle that includes the first item in list and all
     non-empty rectangles in list.

This would precisely define which among the many possible unions to use
and avoids several redundant points in the original (such as that the
items in the list describe border boxes and what to do with only empty
rectangles). If my text is equivalent, I would rather you use the short
version.

Objects implementing the MouseEvent interface are required to also im-
plement the MouseEventView interface, however there are name clashes in
the two interfaces (specifically the screenX/Y and clientX/Y attributes)
which needs to be explained or otherwise resolved in your draft.

The MouseEventView has two redundant attributes x and y, there should be
a note which one authors should use to avoid confusion and promote con-
sistency.

Why is the TextRectangle called thusly? Wouldn't, say, ClientRectangle
be a better name?

Editorially, I rather dislike the high amounts of redundant text you've
included, it makes it very difficult to read the text correctly (you'll
either ignore parts that look similar and miss differences, or you'll
try very hard not to, which I find rather exhausting). The same goes for
the rather elaborate text.

As an example, section 6.3 would be better written like so:

  If an element does not have an associated CSS layout box or if it is
  an inline box, all the following attributes have the value zero. All
  values are in number of CSS pixels.

  clientTop
     The computed value of the border-top-width property plus the
     width of any scrollbar rendered between the top padding box
     and top border box.

  clientWidth
    If element A is the root element, the width of the viewport;
    otherwise the width of the padding box of element A (excluding the
    width of any rendered scrollbar between the padding and border box)

  ...

By the way, instead of referring to the width of the viewport, it might
be wise to refer to the viewport's .innerWidth attribute if that is what
you mean (the name clientWidth would suggest using the .outerWidth).

Similarily, it would be very useful if you would use more mathematical
notation instead of text where approprate, for example, rather than

    2. If x is negative act as if it was zero.

    3. If x is greater than the content width minus the content box
       width act as if it was the content width minus the content box
       width.

define to use `min(content width - content box width, max(0, x))`. This
saves readers from checking that the two phrases above are the same and
it translates more naturally into code, in addition to being shorter.

The main point here is that many people do not bother to fully read and
understand all the text, so keeping the key points as brief as possible
goes a long way of ensuring that people understand them.

On a further note I would suggest avoiding constructs like If X does not
have A or B as in "If element A does not have an associated CSS layout
box or vertical overflow stop this algorithm" -- it's not clear whether
you stop if just one of them is absent. Using "Unless X has A and/or B"
would be better.

There are many terms that you use, like content width, context box with,
associated CSS layout box, and current rendering mode, that you never
properly introduce. Links to their definitions would be very useful.

I think Microsoft's MSDN has a nice diagram that illustrates the various
measures and coordinates, is there a chance you could include something
similar in the draft?
--
Björn Höhrmann · mailto:bjoern@... · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: [phone] · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

[Anne van Kesteren-2]

On Fri, 07 Mar 2008 05:40:13 +0100, Ambrose Li <ambrose.li@...>  
wrote:
> But I agree with GS that this should not be handled in the same way as
> HTML 5. The two are not in the same ballpark.

They both specify a bunch of things that have been implemented already in  
a non-interoperable way. What's your reason for saying they're not?


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

[Robert O'Callahan-3]

On Fri, Mar 7, 2008 at 7:58 PM, Bjoern Hoehrmann <derhoermi@...> wrote:

Why is the TextRectangle called thusly? Wouldn't, say, ClientRectangle
be a better name?

Because that's what IE calls it. ClientRectangle would be better, but would it be better enough to bother changing to it?

Rob

--
"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]

[Erik Dahlstrom]

On Thu, 06 Mar 2008 13:59:53 +0100, Robert O'Callahan  
<robert@...> wrote:

> A few comments...
...
> For SVG elements, which don't really have border-boxes, our  
> implementation
> of getClientRects returns a single rect which is the bounding-box of the  
> SVG
> element.

Is "the bounding-box" for SVG the same as what SVGLocatable.getBBox  
returns on the element? Since those bboxes are in user-space coordinates  
it should be noted that they may not be aligned with the screen coordinate  
system. Or do you mean SVGLocatable.getScreenBBox (from SVGT12), which is  
aligned with the screen coordinate system?

Or do you mean that if one calls getClientRects on any SVG element you get  
back the rootmost <svg> element clientrect? And if an svg element is not  
inside an <svg> fragment what do you get? And in case there's an <svg>  
inside an <svg> and a you query a child of the innermost <svg> element, do  
you get the nearest or the rootmost <svg> element clientrect?

> In our implementation, if an element is a descendant of an SVG
> foreignObject, we treat the nearest enclosing foreignObject as  
> establishing
> the viewport for the element for the purposes of getClientRects and
> getBoundingClientRect. It doesn't seem to make sense to use the true
> viewport in the presence of possible SVG transformations.

That seems sensible.

Cheers
/Erik

--
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

[Robert O'Callahan-3]

On Sat, Mar 8, 2008 at 1:00 AM, Erik Dahlström <ed@...> wrote:

On Thu, 06 Mar 2008 13:59:53 +0100, Robert O'Callahan
<robert@...> wrote:

> A few comments...
...

> For SVG elements, which don't really have border-boxes, our
> implementation
> of getClientRects returns a single rect which is the bounding-box of the
> SVG
> element.

Is "the bounding-box" for SVG the same as what SVGLocatable.getBBox
returns on the element? Since those bboxes are in user-space coordinates
it should be noted that they may not be aligned with the screen coordinate
system. Or do you mean SVGLocatable.getScreenBBox (from SVGT12), which is
aligned with the screen coordinate system?

For consistency with non-SVG elements, it's a box in CSS pixel units, aligned with and relative to the viewport (either the true viewport or a foreignObject-based viewport). I guess that's almost the same as getScreenBBox.

Rob

--
"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]

[Erik Dahlstrom]

On Fri, 07 Mar 2008 13:09:22 +0100, Robert O'Callahan  
<robert@...> wrote:

> On Sat, Mar 8, 2008 at 1:00 AM, Erik Dahlström <ed@...> wrote:
>
>> On Thu, 06 Mar 2008 13:59:53 +0100, Robert O'Callahan
>> <robert@...> wrote:
>>
>> > A few comments...
>> ...
>> > For SVG elements, which don't really have border-boxes, our
>> > implementation
>> > of getClientRects returns a single rect which is the bounding-box of  
>> the
>> > SVG
>> > element.
>>
>> Is "the bounding-box" for SVG the same as what SVGLocatable.getBBox
>> returns on the element? Since those bboxes are in user-space coordinates
>> it should be noted that they may not be aligned with the screen  
>> coordinate
>> system. Or do you mean SVGLocatable.getScreenBBox (from SVGT12), which  
>> is
>> aligned with the screen coordinate system?
>>
>
> For consistency with non-SVG elements, it's a box in CSS pixel units,
> aligned with and relative to the viewport (either the true viewport or a
> foreignObject-based viewport). I guess that's almost the same as
> getScreenBBox.

Well, even I am sometimes fooled by the fact that "Screen" in  
"getScreenBBox" means "Client" [1]. Sorry if that led to any confusion :)

If the implementation is almost the same as getScreenBBox, how does it  
differ? And why?

Cheers
/Erik

[1] http://www.w3.org/TR/SVGMobile12/svgudom.html#svg__SVGLocatable

--
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

[Robert O'Callahan-3]

On Sat, Mar 8, 2008 at 2:31 AM, Erik Dahlström <ed@...> wrote:

On Fri, 07 Mar 2008 13:09:22 +0100, Robert O'Callahan

<robert@...> wrote:

> For consistency with non-SVG elements, it's a box in CSS pixel units,
> aligned with and relative to the viewport (either the true viewport or a
> foreignObject-based viewport). I guess that's almost the same as
> getScreenBBox.

Well, even I am sometimes fooled by the fact that "Screen" in
"getScreenBBox" means "Client" [1]. Sorry if that led to any confusion :)

If the implementation is almost the same as getScreenBBox, how does it
differ? And why?

Because of the foreignObject viewport exception. That appears to be the only difference.

Rob
--
"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]

[Bjoern Hoehrmann]

* Robert O'Callahan wrote:
>On Fri, Mar 7, 2008 at 7:58 PM, Bjoern Hoehrmann <derhoermi@...> wrote:
>
>> Why is the TextRectangle called thusly? Wouldn't, say, ClientRectangle
>> be a better name?
>
>Because that's what IE calls it. ClientRectangle would be better, but would
>it be better enough to bother changing to it?

As far as I can tell, the name occurs only in the documentation. The
interfaces are actually called IHTMLRect and IHTMLRectCollection if
you use the API from, say, C++, and Internet Explorer generally does
not expose either interface name in JavaScript in an important way,
so I don't think the existing naming matters. As I understand it, the
interface is used in several places that do not deal with text at all,
so I find this name rather confusing.
--
Björn Höhrmann · mailto:bjoern@... · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: [phone] · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

[Anne van Kesteren-2]

On Fri, 07 Mar 2008 23:35:07 +0100, Bjoern Hoehrmann <derhoermi@...>  
wrote:
> As far as I can tell, the name occurs only in the documentation. The
> interfaces are actually called IHTMLRect and IHTMLRectCollection if
> you use the API from, say, C++, and Internet Explorer generally does
> not expose either interface name in JavaScript in an important way,
> so I don't think the existing naming matters. As I understand it, the
> interface is used in several places that do not deal with text at all,
> so I find this name rather confusing.

I'm fine with changing the names. The current names are based on the MSDN  
documentation and Firefox' implementation. If we decide on changing it  
anyway, maybe we should keep the interface names generic?

   Rectangle
   RectangleList


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

[Bjoern Hoehrmann]

* Anne van Kesteren wrote:
>I'm fine with changing the names. The current names are based on the MSDN  
>documentation and Firefox' implementation. If we decide on changing it  
>anyway, maybe we should keep the interface names generic?
>
>   Rectangle
>   RectangleList

These names may be overly generic, they could clash with other current
or future interfaces (DOM Level 2 Style for example uses "Rect" already)
especially for rectangles defined by a point and two lengths (like the
"SVGRect" in SVG) rather than four offsets as this type of rectangle is.
--
Björn Höhrmann · mailto:bjoern@... · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: [phone] · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

[Robert O'Callahan-3]

ClientRectangle/ClientRectangleList are fine with me.

Rob
--
"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]

[Anne van Kesteren-2]

On Sat, 08 Mar 2008 00:00:25 +0100, Bjoern Hoehrmann <derhoermi@...>  
wrote:
> These names may be overly generic, they could clash with other current
> or future interfaces (DOM Level 2 Style for example uses "Rect" already)
> especially for rectangles defined by a point and two lengths (like the
> "SVGRect" in SVG) rather than four offsets as this type of rectangle is.

On Sat, 08 Mar 2008 06:56:14 +0100, Robert O'Callahan  
<robert@...> wrote:
> ClientRectangle/ClientRectangleList are fine with me.

Given that renaming is acceptable and that other specifications use "Rect"  
instead of "Rectangle" the interfaces are now called "ClientRect" and  
"ClientRectList".


(By the way, I'm working on addressing the other comments. I thought it  
would be good to fasttrack this one given the soon shipping  
implementations.)


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