Firefox ignores img height / width?

  • Thread starter Tomasz Chmielewski
  • Start date
T

Tomasz Chmielewski

I noticed that Firefox ignores img height and width.

This can be demonstrated with the simple code pasted below (or, just go
to http://wpkg.org/test.html).

The code below points to a non-existing image (or an image which can't
be fetched).
In IE or Konqueror, we will see a 400px x 200px blank space.

In Firefox and Seamonkey we just don't have any blank space (specified
by height and width), so website look will likely break without an image.

Which browser's behaviour is correct?


<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html><head><meta content="text/html; charset=ISO-8859-1"
http-equiv="content-type">
<title>test</title>
</head>
<body>
<table style="text-align: left; width: 100%;" border="1" cellpadding="2"
cellspacing="2">
<tbody>
<tr>
<td>
<img style="width: 400px; height: 200px;" alt="Image file missing"
src="no_such_image.jpg"><br>
IE will show a 400px x 200px blank space. Firefox will not show any
blank space, although we specified image width and height.
</td>
</tr>
</tbody>
</table>
<br>
</body>
</html>
 
R

Roderik

Tomasz Chmielewski schreef:
I noticed that Firefox ignores img height and width.

This can be demonstrated with the simple code pasted below (or, just go
to http://wpkg.org/test.html).

The code below points to a non-existing image (or an image which can't
be fetched).
In IE or Konqueror, we will see a 400px x 200px blank space.

In Firefox and Seamonkey we just don't have any blank space (specified
by height and width), so website look will likely break without an image.

Which browser's behaviour is correct?
Click to expand...

If the image is not available it falls back to the alternative, the alt
text, which is probably rendered as an inline element.
If it is right to fall back to an inline element, I don't know. I would
also prefer that it just took the dimensions as specified.
 
A

Andy Dingley

I noticed that Firefox ignores img height and width.
Click to expand...
The code below points to a non-existing image (or an image which can't
be fetched).
In IE or Konqueror, we will see a 400px x 200px blank space.
Click to expand...

By "ignores the height of an image", just which image did you mean?
You didn't supply an image, so the size of it becomes an irrelvance.
Instead FF sizes the relevant box to be a suitable sive to display the
alt text you supplied. On the whole, this seems like a more useful
behaviour, IMHO.
In Firefox and Seamonkey we just don't have any blank space (specified
by height and width), so website look will likely break without an image.
Click to expand...

What do you mean by "break" ? If you mean that the layout of the
website will break if the image isn't present, then that's the fault
of the coder for relying on using images to control the size and
layout of things! That technique has been obsolete for over 10 years,
since HTML 4 and CSS first appeared.
 
B

Ben C

Tomasz Chmielewski schreef:

If the image is not available it falls back to the alternative, the alt
text, which is probably rendered as an inline element.
If it is right to fall back to an inline element, I don't know. I would
also prefer that it just took the dimensions as specified.
Click to expand...

I suppose the issue is whether img is display: inline or display:
inline-block.

If it's inline, then it goes from being replaced inline to just
ordinary inline. Width and height don't apply to non-replaced inline
elements.

If it's inline-block, then it goes from being replaced inline-block
(which is exactly the same as replaced inline) to ordinary inline-block,
which is not the same as inline, because width and height do work for
inline-block. That's what Opera appears to do for example.

Since Firefox doesn't support inline-block, it's perhaps not surprising
that img is replaced inline.

Either is correct.
 
J

Jonathan N. Little

Tomasz said:
I noticed that Firefox ignores img height and width.

This can be demonstrated with the simple code pasted below (or, just go
to http://wpkg.org/test.html).

The code below points to a non-existing image (or an image which can't
be fetched).
In IE or Konqueror, we will see a 400px x 200px blank space.

In Firefox and Seamonkey we just don't have any blank space (specified
by height and width), so website look will likely break without an image.

Which browser's behaviour is correct?


<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html><head><meta content="text/html; charset=ISO-8859-1"
http-equiv="content-type">
<title>test</title>
</head>
<body>
<table style="text-align: left; width: 100%;" border="1" cellpadding="2"
cellspacing="2">
<tbody>
<tr>
<td>
<img style="width: 400px; height: 200px;" alt="Image file missing"
src="no_such_image.jpg"><br>
IE will show a 400px x 200px blank space. Firefox will not show any
blank space, although we specified image width and height.
</td>
</tr>
</tbody>
</table>
<br>
</body>
</html>
Click to expand...

Since image is inline as default, if missing FF only displays the alt
text and the "height" needed got that inline text... Want constancy, then:
ADD
vvvvvvvvvvvvvvv
<img style="width: 400px; height: 200px; display: block;" alt="Image
file missing" src="no_such_image.jpg"><br>
 
R

Roy A.

Tomasz Chmielewski skrev:
I noticed that Firefox ignores img height and width.
Click to expand...

First of all, a vendor don't have to follow any specifications.
This can be demonstrated with the simple code pasted below (or, just go
to http://wpkg.org/test.html).
Click to expand...

Thank you for that example. It shows that Firefox is getting ready
enough to bend som rules.
The code below points to a non-existing image (or an image which can't
be fetched).
In IE or Konqueror, we will see a 400px x 200px blank space.
Click to expand...

"This property specifies the content height of boxes generated by
block-level and replaced elements."
http://www.w3.org/TR/REC-CSS2/visudet.html#propdef-height
In Firefox and Seamonkey we just don't have any blank space (specified
by height and width), so website look will likely break without an image.
Click to expand...

That's true. But why don't you supply an image? Don't use images as an
plaseholder, maybe that's the reason.
Which browser's behaviour is correct?
Click to expand...

These people are just playing with words. The specification says:

"This property specifies the content height/width of boxes generated
by block-level and replaced elements."
http://www.w3.org/TR/REC-CSS2/visudet.html

If there is no block-level or replaced elements to genereate any
height/width, there is always a
property who specifies it.

I have read all the specifications, but it is to much form me. Maybe
someone can cum up
with something I didn't understand.
 
R

Roy A.

By "ignores the height of an image", just which image did you mean?
Click to expand...

The OP did not say that height and width did refer to any image. An
image is an
replaced element. So I think he was talking about the box around the
image.
You didn't supply an image, so the size of it becomes an irrelvance.
Click to expand...

Why? An image is an replaced element, it's the box around that's
importent. Just look at how the object element is rendered, without an
image, object or other references. I really don't think Firefox should
make exeptions like that. I know other browsers do that. But Firefox??
Instead FF sizes the relevant box to be a suitable sive to display the
alt text you supplied. On the whole, this seems like a more useful
behaviour, IMHO.
Click to expand...

For you it might seems like a more useful behviour. But the rest of us
would have some
problem:

"This property specifies the content height of boxes generated by
block-level and replaced elements."
http://www.w3.org/TR/REC-CSS2/visudet.html#propdef-height
What do you mean by "break" ? If you mean that the layout of the
website will break if the image isn't present, then that's the fault
of the coder for relying on using images to control the size and
layout of things!
Click to expand...

No, the fault is that the coder is relaying on height and width when
dispalying the alt text.
That technique has been obsolete for over 10 years,
since HTML 4 and CSS first appeared.
Click to expand...

Now we can't specify height and widht on images? I don't think so.
 
B

Ben C

The OP did not say that height and width did refer to any image. An
image is an
replaced element. So I think he was talking about the box around the
image.


Why? An image is an replaced element, it's the box around that's
importent. Just look at how the object element is rendered, without an
image, object or other references. I really don't think Firefox should
make exeptions like that. I know other browsers do that. But Firefox??
Click to expand...

The question is, is it still a replaced element when the image isn't
actually there and the alt text is displayed instead?

If not, then you can make sense of what's happening by observing that
Firefox displays it as a non-replaced inline, and Opera as a
non-replaced inline-block.
 
R

Roy A.

The question is, is it still a replaced element when the image isn't
actually there and the alt text is displayed instead?
Click to expand...

That's a better question. If yes, it make sense that alt text is
displayed as an replaced element. It's a mesh to sometimes display it
as an replaced element, and sometimes display it as an non-replaced
element.
If not, then you can make sense of what's happening by observing that
Firefox displays it as a non-replaced inline, and Opera as a
non-replaced inline-block.
Click to expand...

Slow down, 'inline-block' is CSS 2.1. The img element is an inline
element, not an 'inline-block' element. What's next? display: auto?
Opera, and some others displays it as an replaced inline element, not
an non-replaced inline-block.
 
B

Ben C

That's a better question. If yes, it make sense that alt text is
displayed as an replaced element. It's a mesh to sometimes display it
as an replaced element, and sometimes display it as an non-replaced
element.


Slow down, 'inline-block' is CSS 2.1. The img element is an inline
element, not an 'inline-block' element. What's next? display: auto?
Opera, and some others displays it as an replaced inline element, not
an non-replaced inline-block.
Click to expand...

You may be right, but a browser can perfectly well make an img
inline-block by default-- a replaced inline-block displays exactly the
same as a replaced inline.

But I tried a little JavaScript test:

var elt = document.getElementById("one");
var style = getComputedStyle(elt, "");
alert(style.display);

And Opera does report "inline", not "inline-block", both when the actual
image is present and when it isn't.
 
T

Tomasz Chmielewski

Jonathan said:
Since image is inline as default, if missing FF only displays the alt
text and the "height" needed got that inline text... Want constancy, then:
ADD
vvvvvvvvvvvvvvv
<img style="width: 400px; height: 200px; display: block;" alt="Image
file missing" src="no_such_image.jpg"><br>
Click to expand...

What's interesting, when Firefox still loads such a page (that is,
without your "display: block" tip), it displays the missing image
exactly the same as IE or Konqueror (an empty box with a given size
instead of an image).
Only when the page is fully loaded, the missing image "scales down" to
the size of "alt" text.
 
T

Tomasz Chmielewski

Roy said:
That's true. But why don't you supply an image? Don't use images as an
plaseholder, maybe that's the reason.
Click to expand...

I "discovered" it pretty accidentally.

I was trying to find out why a 100% HTML/CSS-compliant page renders
correctly in Firefox/IE, but looks like crap in Konqueror.
After I removed an image, I noticed that the page starts to look crappy
in exactly the same way in Firefox.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Help with Visual Lightbox: Scripts 2
How to wrap <td> content . 16
Help with my responsive home page 2
Please Help? 0
Responsive width SVG image with fixed height rectangle at left and bottom - see my pen 0
Align img inside nav tabs section 5
I need help fixing my website 2
SendGrid email issue in responsive Gmail 1

Members online

Total: 20 (members: 1, guests: 19)
Robots: 428

Forum statistics

Threads
473,769
Messages
2,569,577
Members
45,054
Latest member
LucyCarper

Latest Threads

Top