Re: Layout Information for SVG Elements

Boris Zbarsky <[email protected]> Tue, 24 Nov 2009 23:29:38 -0500
Newsgroups gmane.comp.mozilla.devel.svg
Message-ID <[email protected]>
On 11/24/09 10:24 PM, Steven Roussey wrote:
>> You should, imo, just drop the offset* stuff.  It's broken and useless.
>
> OK, knowing how it is broken would be helpful. For example: for just
> width/height?

It rounds the values to integer CSS pixels, if nothing else.  That means 
they can be off from the actual value; the higher DPI your screen the 
more off they can be.

> What else gives the relative distance to the nearest positioned
> parent?

What does that even mean?  Note that this is NOT what offset* do.  They 
give the offset to the offsetParent, period.  That need not be 
positioned (e.g. it could have a transform instead, or be a table cell 
or be a table)), and not all positioned things are offsetParent, 
depending on the child (e.g. the offsetParent of a fixed-pos node is the 
<body> no matter what the ancestors of that node look like).

Then there's the question of what the offsets are relative to.  They're 
sort of relative to the padding box except when border-box sizing is 
used except when we ended up using the <body> as the offsetParent, 
unless we only used it because we found nothing better.

Yes, that sounds ridiculous.  Yes, that's what needs to happen for web 
compat.  No, the numbers this produces are not generally useful in any 
way other than adding up while walking up the offsetParent chain to find 
a document offset... which getBoundingClientRect just gives you.

We've had this discussion with John before, on one of the other 
newgroups.  Check the archives?

> Both.<svg:svg>  also says it is 40px. Changing its width from 50px to
> 150px makes a clear difference if you have text around it, as viewed
> in the content. But getBoundingClientRect still returns 40px for the
> width.

This looks like a bug, pure and simple.  Filed 
https://bugzilla.mozilla.org/show_bug.cgi?id=530985 with some analysis.

> MathML has a similar issue with its top most element and
> getBoundingClientRect. All the ones inside look fine.

Can you describe the mathml issue in sufficient detail that I can reproduce?

-Boris