Closed
Bug 401144
Opened 17 years ago
Closed 17 years ago
SVG element not vertically scaling within container
Categories
(Core :: SVG, defect)
Core
SVG
Tracking
()
RESOLVED
FIXED
People
(Reporter: jwitch, Assigned: jwatt)
References
Details
Attachments
(2 files)
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.8.1.6) Gecko/20070723 Firefox/2.0.0.6 (Debian-2.0.0.6-0etch1) Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.8.1.6) Gecko/20070723 Firefox/2.0.0.6 (Debian-2.0.0.6-0etch1) placing an inline SVG element with 100% sized tags within a HTML container does not scale vertically and instead overflows. Reproducible: Always Steps to Reproduce: see attachment Expected Results: SVG element should scale within the confines of the container.
Assignee | ||
Comment 2•17 years ago
|
||
So SVG in Firefox 2 will incorrectly take take percentage values as relative to the content window width and height instead of the containing block's width and height. This is why you're seeing the SVG being so large. In trunk (development) builds, the SVG doesn't show at all. This is actually correct behavior given the current testcase, since the SVG's width and height defaults to 100%, but the table size doesn't have a fixed width or height for the SVG to work out what these percentage values should be. Hence with the table relying on it's content (the SVG) to tell it its size, and with the content (the SVG) relying on the table to have a fixed size to work out it's percentage width and height, we have a cyclic dependency. Thus the width/height of the SVG is resolved to be zero. You can fix this by adding: height: 100%; width: 100%; to the 'table' entry in the CSS. Once the CSS is fixed and the SVG can work out it's percentage values, it still gets them wrong unfortunately, but at least the SVG shows up then. The patch in bug 294086 makes things a lot better for the fixed testcase, so I'll mark this bug as depending on it and we can revisit it after that patch has been checked in.
Assignee | ||
Comment 3•17 years ago
|
||
Note to self: the remaining problems seem to be the space added for descenders (make the SVG display:block to get rid of that) and the fact that the height defaults to 150px.
Assignee | ||
Comment 4•17 years ago
|
||
This testcase sets the table width and height to 100%, makes the SVG display:block, sets bgcolor on the td elements and sets an explicit height of 100px and 150px on the first and second SVG fragments respectively.
Assignee | ||
Updated•17 years ago
|
Assignee: nobody → jwatt
OS: Linux → All
Hardware: PC → All
Assignee | ||
Comment 5•17 years ago
|
||
So the one remaining issue where the height of the SVG is 150px is actually the correct behavior. The reason is that, even with the height of the table set, the <td> elements don't have a fixed height. Again, the rules of CSS say that if the height of the SVG's containing block (the <td>) relies on the SVG, then the SVG cannot resolve it's percentage height and so it must fall back to a height of 150px. Note that a similar thing happens if you replace the <svg> with a <div> with a percentage height. Since the <td> does not have a fixed height, the percentage value on the div does not work.
Assignee | ||
Comment 6•17 years ago
|
||
For the most part the issues with the testcase were fixed by the fix for bug 294086, so marking this bug FIXED.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•