Beginning on October 25th, 2016, Persona will no longer be an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 407495 - Make SVG documents with percentage width/height respond to page zoom
: Make SVG documents with percentage width/height respond to page zoom
: testcase
Product: Core
Classification: Components
Component: SVG (show other bugs)
: Trunk
: All All
: -- normal with 2 votes (vote)
: mozilla15
Assigned To: Jonathan Watt [:jwatt]
: Jet Villegas (:jet)
data:image/svg+xml,<svg xmlns="http:/...
: 406754 503676 606612 719623 (view as bug list)
Depends on: 843480
Blocks: 455185 pagezoom
  Show dependency treegraph
Reported: 2007-12-08 07:45 PST by Gábor Stefanik
Modified: 2016-08-01 08:40 PDT (History)
18 users (show)
jwatt: wanted1.9.2+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

patch (15.71 KB, patch)
2012-05-03 00:16 PDT, Jonathan Watt [:jwatt]
roc: review+
Details | Diff | Splinter Review

Description Gábor Stefanik 2007-12-08 07:45:45 PST
Page zoom scales images, text and other elements, except those that have percentage sizes. This can break many percentage-based page layouts, so it should be fixed. The URL is an SVG showing a bug, here is another (a HTML): data:text/html,<body style="margin:0"><div style="background: black; width: 50%; height: 50%">
Pagezoom in on any of these examples, and notice that they don't scale.
Comment 1 Martijn Wargers [:mwargers] (not working for Mozilla) 2007-12-08 08:00:39 PST
The percentage value is calculated against the viewport. The viewport size stays the same, no matter what zoom value.
So this seems invalid to me.
Comment 2 Robert Longson 2007-12-08 09:28:00 PST
Martjin is right. 50% of the viewport width means exactly what it says.
Comment 3 Mike Schroepfer 2007-12-08 09:31:18 PST
clearing the blocking flag since this bug is resolved. 
Comment 4 Jonathan Watt [:jwatt] 2007-12-10 05:36:17 PST
I don't think I agree about this bug being invalid. I'd think of this as "take the element size to be X% of the viewport, _then_ zoom/scale it in/up by Y. At any rate, I think it would be useful to get the thoughts of a few other people first.

Whatever we choose, HTML and SVG should be consistent.
Comment 5 Robert Longson 2007-12-10 05:49:06 PST
*** Bug 406754 has been marked as a duplicate of this bug. ***
Comment 6 Boris Zbarsky [:bz] (still a bit busy) 2007-12-10 08:08:46 PST
If we were doing pixel-for-pixel scaling, comment 4 would be correct.  But we're not.  Zoom is just redefining the CSS-to-device pixel ratio.  So the viewport size in CSS pixels actually becomes _smaller_ when you zoom, for example.  So comment 1 is right on the money, I think.

And HTML and SVG _are_ consistent, no?
Comment 7 Robert Longson 2007-12-10 08:11:28 PST
HTML and SVG _are_ consistent.
Comment 8 Jonathan Watt [:jwatt] 2007-12-10 08:39:16 PST
Yes, HTML and SVG are currently consistent. I just meant that if we changed anything we should keep them consistent - sorry.

I think from the average user's perspective it's going to be frustrating to have the Zoom In and Zoom Out menu items work on some content but have no effect on other content. Since percentage width/height are the common/default case in SVG, it'll be especially frustrating here.

I'm not sure that the limitations of the way zoom is currently implemented should come before how it should ideally behave.
Comment 9 Boris Zbarsky [:bz] (still a bit busy) 2007-12-10 09:22:35 PST
It's not a matter of limitation but a matter of what the goal is.  Please see roc's blog about the various "ideal" behaviors for zoom.  There are tradeoffs here, not just an obvious "ideal" behavior.
Comment 10 Gábor Stefanik 2007-12-19 11:04:32 PST
The problem here is that percentages shouldn't be calculated against the zoomed viewport, instead the original viewport should be the base of the calculation. Also, consider a rectangle which has a pixel height but a percentage width. When zooming, the shape of the rectangle changes, even though Zoom is supposed to change sizes, not shapes. (Maybe making percentage zoom on the document root max out at 100% is a good idea to prevent horizontal scrolling, however.)
Comment 11 Robert O'Callahan (:roc) (email my personal email if necessary) 2007-12-19 13:22:41 PST
I've seen pages/demos where this would be useful. However, changing this way would mean that when you zoom into a site using percentage widths, you would invariable need to scroll horizontally to see all the content, and that's a worse user experience on most real sites.
Comment 12 Robert O'Callahan (:roc) (email my personal email if necessary) 2007-12-19 13:26:04 PST
One thing we could do, I suppose, is to have different treatment for the case where the document root is percent-sized SVG whose content is going to be scaled to the viewport size. In that case we could apply the percentage sizing to the unscaled viewport, because we know that otherwise zooming is going to have no effect, which will surprise the user.
Comment 13 Jonathan Watt [:jwatt] 2007-12-19 22:52:52 PST
I now think we should, despite comment 4.
Comment 14 Lie Ryan 2007-12-19 23:21:36 PST
On the other hand, if you met a page that is way too wide for your screen (this is real problems, with some "webdesigner" wannabe that designs with stupidity in mind) you can have an option to resize the page to your viewport, while possibly enlarging the text to fit the eye. 
Comment 15 Robert O'Callahan (:roc) (email my personal email if necessary) 2007-12-20 00:53:49 PST
Pages that are too wide for your screen are rarely too wide because of percentage widths, that would probably mean they were too wide for *any* screen.

Jonathan, do you want to whip up a patch for this?
Comment 16 Henrik Skupin (:whimboo) 2008-06-19 01:45:45 PDT
Shouldn't it be a more general component than SVG?
Comment 17 Robert Longson 2009-07-11 10:05:18 PDT
*** Bug 503676 has been marked as a duplicate of this bug. ***
Comment 18 Darxus 2009-07-11 10:20:56 PDT
I agree with #12.
Comment 19 Robert Longson 2010-10-22 23:21:17 PDT
*** Bug 606612 has been marked as a duplicate of this bug. ***
Comment 20 Robert Longson 2012-01-19 16:19:14 PST
*** Bug 719623 has been marked as a duplicate of this bug. ***
Comment 21 Jonathan Watt [:jwatt] 2012-05-03 00:16:24 PDT
Created attachment 620607 [details] [diff] [review]
Comment 22 Jonathan Watt [:jwatt] 2012-05-04 00:47:54 PDT
Comment 23 :Ehsan Akhgari (Away Oct 25 - Nov 9) 2012-05-04 13:36:03 PDT

Note You need to log in before you can comment on or make changes to this bug.