Closed Bug 392261 Opened 13 years ago Closed 9 years ago

Image with max-width should be zoomed without proportions distortion

Categories

(Core :: Layout, defect)

x86
Windows XP
defect
Not set

Tracking

()

RESOLVED INVALID

People

(Reporter: mtanalin, Unassigned)

References

()

Details

(Whiteboard: [CSS-spec lack])

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6

Image is zoomed with proportions distortion if max-width is smaller than width and image height is set explicitly.

Reproducible: Always

Steps to Reproduce:
1. Create HTML page with image.
2. Set width and height (!) for image.
3. Set image max-width smaller than its width.
Actual Results:  
Image is zoomed disproportionately resulting in image distortion.

Expected Results:  
Image should be zoomed with preserving initial proportions defined by width and height combination -- regardless whether height is set explicitly or not set at all. Freezing one dimension while changing other one is insensible here.

Currently, Firefox _can_ behave corrently, but only in case of height is not set at all.

Opera 9.22 and IE 7 behaviors can be considered as an examples of correct behavior here.

Demonstration of the bug is available through the bug URL.
Small errata:
behave corrently -> behave correctly
Version: unspecified → Trunk
Rendering of the test URL in different browsers for comparison: Fx 3.5.3, Fx 3.5.3 using Coral IE Tab, IE 8, Opera 10 and SRware Iron 3 (a Google Chrome 3 mod). 

http://img2.pict.com/0c/80/fd/1661695/0/800/bug392261differentbrowsers2.png

Please note that color styles were applied in some of the browsers, but these styles don't affect size.

Note that Firefox 3.5.3, Opera 10 and Iron render the page identically, except for said color styles, i.e. 1st image distorted, 2nd image correct.

Interestingly, Firefox with Coral IE Tab shows both images without distortion, while Internet Explorer 8 shows both images distorted.
Currently (as opposed to when I've filed this bug) I suppose that most correct solution would be to have dedicated CSS property to explicitly define behavior like as follows:

IMG {preserve-proportions: preserve; }

But there is (yet?) no such a property. Thus, we have to specify either image width/height OR max-width, not both at the same time. But specified width/height are useful to prevent page "jumps" (repetitive reflows when images are downloaded one by one) during page loading and therefore improves usability (user can start reading text with no need to wait until page is entirely loaded).

In fact, it perhaps that currently there is no formal standards-compliant solution for max-width and explicitly specified image dimensions to coexist. And it perhaps that *formally* such distortion is *correct* behavior while is *nonsensical* as applied to *images*.
Reporter, are you still seeing this issue with Firefox 3.6.13 or later in safe mode or a fresh profile? If not, please close. These links can help you in your testing.
http://support.mozilla.com/kb/Safe+Mode
http://support.mozilla.com/kb/Managing+profiles

You may also wish to try with the latest Firefox 4 beta, http://www.mozilla.com/en-US/firefox/all-beta.html.
Whiteboard: [CLOSEME 2011-1-30]
(In reply to comment #4)

Yes, I still seeing this in latest Firefox 3.6.13 as well as Fx 4 nightly and any other modern browser (including Opera 11, Chrome 8, and even latest IE9 preview 9.0.8023.6000), and this is apparently by design.

At the same time there is currently NO solution other than non-specifying image width/height (which is quite partial solution since it has negative impact to user experience during page load, as I've mentioned above). For more explanation as well as possible theoretic CSS solution (currently non-implemented and even non-discussed by CSS WG at all as far as I know), see comment 3.
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Whiteboard: [CLOSEME 2011-1-30]
Yeah, as filed this bug is invalid.

And I don't see what the problem is, really.  You're _explicitly_ specifying a height for the image.  If you don't want it to have that height.... don't do that.

What actual behavior were you trying to achieve, if I might ask?  That is, why is the height specified at all?
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → INVALID
Note, in particular, that HTML defines that the width and height attributes of <img> map directly to CSS properties.  So the testcase is identical (per HTML spec) to one that sets no attributes but has the following CSS:

  width: 412px;
  max-width: 200px;
  height: 192px;

The question is, again, what you expect this to do and why.
(In reply to comment #6)
> why is the height specified at all?

The point is clearly stated in comment 3.

Again: specifying dimensions of images is useful to prevent page "jumps" (repetitive reflows when images are downloaded one by one) during page load. At the same time, max-width might be used to prevent very wide images to go beyond right side of content area. When combined, these two leads to undesirable distortion of images.

On of probable (unfortunately nonexistent) CSS solutions is described in comment 3 as well.
> But specified width/height are useful to prevent page "jumps"

Uh... no.  They're only useful if those will actually be the right dimensions.  And if you're also using max-* or min-*, then all bets are off...
(In reply to comment #9)
Image dimensions specified explicitly are useful _most of the time_, while max-width is to prevent _extreme_ (and rare) cases only (such extreme case is when one reflow is better than breaking page layout at all due to too wide image).

Anyway, such theory (your viewpoint) vs. practice (my viewpoint) discussion is not a topic of this bug. There _is_ CSS problem in web-developing _practice_, but unfortunately there is currently no _CSS-spec-level_ solution (as I already have stated in comment 5) -- that's all.
Whiteboard: [CSS-spec lack]
You need to log in before you can comment on or make changes to this bug.