W3C home > Mailing lists > Public > www-style@w3.org > March 2008

Re: [cssom-view] small update

From: Anne van Kesteren <annevk@opera.com>
Date: Sun, 09 Mar 2008 15:42:17 +0100
To: robert@ocallahan.org
Cc: www-style@w3.org
Message-ID: <op.t7q64rvd64w2qv@annevk-t60.oslo.opera.com>

Changes can be reviewed at the usual location:

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


On Thu, 06 Mar 2008 13:59:53 +0100, Robert O'Callahan  
<robert@ocallahan.org> wrote:
> 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.)

Done by talking about width/height instead of talking about empty.


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

Ok, changed.


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

Done. (For all elements whose computed value of display has a value of  
table or inline-table and which have a child element whose computed value  
of display is table-caption.)


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

Fixed.


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

Fixed.


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

Also fixed.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
Received on Sunday, 9 March 2008 14:42:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:02 GMT