Layout Information for SVG Elements
Steven Roussey
anything useful for SVG elements in the layout panel. The layout panel
displays basic information about an element (height/width, padding,
margin, offset). I'd like to get at least some basic information for
SVG, and perhaps setup the panel to be extensible for a Firebug-SVG-
extension. I already have the Edit button for a SVG element have a
hook for a extension developer to swap their editor.
But back to the issue at hand:
http://code.google.com/p/fbug/issues/detail?id=1953
What basic information could be there, and how to get it?
-steve--
Boris Zbarsky
> Looking at Issue 1953 for Firebug, I can see that Firebug does not do
> anything useful for SVG elements in the layout panel. The layout panel
> displays basic information about an element (height/width, padding,
> margin, offset).
None of that makes much sense for SVG. It's not clear what "size" or
"position" would mean for these, so much, especially when <use> is involved.
> What basic information could be there, and how to get it?
Fill and stroke information seems like something I might want, but I
don't do much svg inspecting....
-Boris
Steven Roussey
> "position" would mean for these, so much, especially when <use> is involved.
I suppose only the outside element would make sense -- it's size as
part of a html doc assuming that it was embedded that way. Otherwise,
you are right. Event the title of the tab "Layout" doesn't make sense.
In general it should probably give some text saying that an html
element is not selected. Later, we could have a SVG specific panel
showing fill and stroke, transforms, and a few other things. It could
show in place of the layout tab.
Boris Zbarsky
> I suppose only the outside element would make sense -- it's size as
> part of a html doc assuming that it was embedded that way.
That should already work; does it not? If not, what APIs are you using
to fill in the layout pane? Is it still doing the silly offset* thing
or something?
-Boris
Robert O'Callahan
element.getBoundingClientRect() will give you a true bounding box
relative to the viewport. element.getBBox() will give you the bounding
box of the shape excluding stroke extents.
Rob
Rick
It occurred to me to mention bounding boxes.
Transform nesting might be useful. Since it is a large display, maybe show
a bounding box transformed against the client rect. Rendering the element
inside it would be sweet if it wasn't too difficult.
Styling. It would be useful to have some way to navigate up the style tree
to see where things are set. The Style window shows class information. (I
always use classes, so I don't know what else is there.)
--
Cheers!
Rick
Steven Roussey
Well... if the option "Show Bounding Client Rectangle" is selected,
then it shows data. Otherwise, it does not.
But anyway, if the option is off then it shows offsets and uses
element.offset* which results in nothing, and height/width of NaN.
With the option on it shows the bounding rectangle and uses
element.getBoundingClientRect() -- but the values are wrong.
Looking at the svg of a circle here:
http://math.chapman.edu/~jipsen/mathml/asciimathandmathmlsvg.xhtml
<svg:svg width="50px" height="50px">
<svg:circle cx="25px" cy="25px" r="20px" fill="green"/>
</svg:svg>
It says it has a width and height of 40px. Using Firebug to change the
height/width settings has no effect on the getBoundingClientRect call.
Strange...
Boris Zbarsky
> Well... if the option "Show Bounding Client Rectangle" is selected,
> then it shows data. Otherwise, it does not.
>
> But anyway, if the option is off then it shows offsets and uses
> element.offset* which results in nothing, and height/width of NaN.
You should, imo, just drop the offset* stuff. It's broken and useless.
> Looking at the svg of a circle here:
> http://math.chapman.edu/~jipsen/mathml/asciimathandmathmlsvg.xhtml
>
> <svg:svg width="50px" height="50px">
> <svg:circle cx="25px" cy="25px" r="20px" fill="green"/>
> </svg:svg>
>
> It says it has a width and height of 40px.
Height and width of which? The <svg:circle> or the <svg:svg>? The
former in fact has a bounding rect with width=height=40px.
-Boris
Steven Roussey
> > element.offset* which results in nothing, and height/width of NaN.
>
> 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?
What else gives the relative distance to the nearest positioned
parent?
> > Looking at the svg of a circle here:
> >http://math.chapman.edu/~jipsen/mathml/asciimathandmathmlsvg.xhtml
>
> > <svg:svg width="50px" height="50px">
> > <svg:circle cx="25px" cy="25px" r="20px" fill="green"/>
> > </svg:svg>
>
> > It says it has a width and height of 40px.
>
> Height and width of which? The <svg:circle> or the <svg:svg>? The
> former in fact has a bounding rect with width=height=40px.
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.
MathML has a similar issue with its top most element and
getBoundingClientRect. All the ones inside look fine.
-steve--
Boris Zbarsky
>> 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
Steven Roussey
> 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?
Oh God. I put in a change today to switch to getBoundingClientRect for
all svg/mathml/etc elements. I wonder if anyone would miss it for
HTML. I'm going to see if we can't switch to the bounding box view as
the default...
The reason I thought about positioned elements was that in Firebug, if
you change the top offset in the layout view to 50, for example, it
set the element's style to "top:50px". Which is yet another thing
altogether.
> > 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?
http://math.chapman.edu/~jipsen/mathml/asciimathandmathmlsvg.xhtml
Both fractions have the getBoundingClientRect values off, though the
second one in blue is more obvious (says 19x20 yet the mstyle inside
is 19x45). The first one has is math element with height/width of 8x20
and the inside mfrac is 8x26.
-steve--
Boris Zbarsky
> http://math.chapman.edu/~jipsen/mathml/asciimathandmathmlsvg.xhtml
>
> Both fractions have the getBoundingClientRect values off, though the
> second one in blue is more obvious (says 19x20 yet the mstyle inside
> is 19x45). The first one has is math element with height/width of 8x20
> and the inside mfrac is 8x26.
Looks correct to me. In both cases the fraction overflows the <math>
element. You can put a border on the <math> to see that.
-Boris
Steven Roussey
> Looks correct to me. In both cases the fraction overflows the <math>
> element. You can put a border on the <math> to see that.
https://bugzilla.mozilla.org/show_bug.cgi?id=219873
So it is not the same this bug? I guess it is not so much a bug as it
is by design. Just curious how we get the size of the math element to
highlight it.
Can SVG overflow like that at all? I'm guessing not, as it is
specifying a canvas size of sorts.
I'll keep my eyes on 530985.
Thanks,
-steve--
Boris Zbarsky
> https://bugzilla.mozilla.org/show_bug.cgi?id=219873
>
> So it is not the same this bug?
It's the same issue, but it's not a bug in terms of CSS as long as
<math> keeps claiming to not be a replaced element.
Arguably it should stop claiming that.
> Just curious how we get the size of the math element to
> highlight it.
Why are you worrying about this? Do you worry about it in cases of html
overflow?
> Can SVG overflow like that at all?
Looks like no.
-Boris
Steven Roussey
> > Just curious how we get the size of the math element to
> > highlight it.
>
> Why are you worrying about this? Do you worry about it in cases of html
> overflow?
No. I should have left the highlight part out. I'm simply curious.
-s
Boris Zbarsky
In that case, I'm not sure what information you're trying to get,
exactly? The overflow area? You can get that (or close to it) by
adding up the bounding client rects for all descendants of the element,
modulo XBL.
-Boris