SVG element not vertically scaling within container

RESOLVED FIXED

Status

()

RESOLVED FIXED
11 years ago
11 years ago

People

(Reporter: jwitch, Assigned: jwatt)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

11 years ago
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.
(Reporter)

Comment 1

11 years ago
Created attachment 286195 [details]
svg vertical scaling problem
(Assignee)

Comment 2

11 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.
Status: UNCONFIRMED → NEW
Depends on: 294086
Ever confirmed: true
(Assignee)

Comment 3

11 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

11 years ago
Created attachment 286282 [details]
testcase for debugging

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

11 years ago
Assignee: nobody → jwatt
OS: Linux → All
Hardware: PC → All
(Assignee)

Comment 5

11 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

11 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
Last Resolved: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.