Closed
Bug 54858
Opened 24 years ago
Closed 24 years ago
images not streched to specified dimensions
Categories
(Core :: Layout, defect, P3)
Tracking
()
People
(Reporter: rvj, Assigned: clayton)
Details
It seems that images are scaled with aspect ration preserved rather than stretched to desired height and width expressed as percentages. IE5 seems to do it correctly by default - have I missed something or is Gecko correct? In the sample code below, the iframe is correctly sized using percentages. <HTML> <BODY id=body scrolling=0 style=';margin-left:0;margin-right:0;margin- top:0;;background-color:red'> <DIV STYLE="position:absolute;top:10%;width:100%;height:30%;background- color:yellow"> <IFRAME ID='' STYLE="position:absolute;width:80%;top:10%;height:80%;left:10%;" SRC=""></IFRAME> </div> <DIV STYLE="position:absolute;top:60%;width:100%;height:30%;background- color:green"> <IMG src="anypic.gif" style="position:absolute;width:80%;top:10%;height:80%;left:10%" > </div> </BODY> </HTML>
noticed a couple of other points a) if width is given actual value image and height remains as percentage image does strech b) however if height is given actual value and width as percentage aspect ratio is preserved In other words height or width scaling is inconsistant. But that raises another question if you want to set height (or width) as a percentage, what value to supply to width (or height) to preserve aspect ratio? Does 0% seem useful for this purpose - or should it be that if only one attribute is supplied then aspect ratio scaling will be performed relatively to the axis given? a) stretched to fit (no aspect ratio preserved) < img src="somepic.jpg" style="width:50%;height:50%"> b) stretched to height and aspect ratio preserved in width < img src="somepic.jpg" style="height:50%"> c)stretched to width and aspect ratio preserved in height < img src="somepic.jpg" style="width:50%"> One final question what do you need to specify to ensure that the auto scaled axis is then centered horizontal or vertically in the containing box?
Updated•24 years ago
|
QA Contact: petersen → chrisd
Comment 3•24 years ago
|
||
Reporter: Could you give us a VERY SIMPLE test case? Preferably one that did not involve absolute positioning, and so on. Is the problem simply that we do not support % heights on replaced inline content? This would be bug 54119...
CSS2 10.5 ( http://www.w3.org/TR/REC-CSS2/visudet.html#the-height-property ) says: <percentage> ... If the height of the containing block is not specified explicitly (i.e., it depends on content height), the value is interpreted like 'auto'. Since the height of BODY is not given explicitly, the height of the DIVs are treated like auto, and therefore the same for the image. This bug is probably invalid, at least until CSS3 changes things (which I hope it does, but I'd rather not implement something other than the spec). However, our behavior should probably be investigated further (esp. on IFRAME, TABLE, etc.).
Reporter-what build were you using when you filed this bug? There were a few issues with Height Percent that were solved in a recent build (10/14?). Please try that out, and/or let us know what bild you were using. Thanks for testing Mozilla!
Comment 6•24 years ago
|
||
iframe and img from testcase render identically for me on linux trunk 2000-11-13-08. I presume that this was fixed as a consequence of bug 54119 being fixed. There is a separate bug (bug 41656) for % height of tables/iframes. Marking worksforme. Reporter, please reopen if you still see the problem on a recent Mozilla build.
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Reopening, marking DUPLICATE.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Duplicate of 41656. *** This bug has been marked as a duplicate of 41656 ***
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → DUPLICATE
Comment 9•24 years ago
|
||
verifying as a duplicate of 41656 '(table/iframe) % height NOT ignored in block with no height specified'
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•