16621 - Gecko is not honouring IMG dimensions if IMG is unloadable

Status: VERIFIED INVALID

(Core :: Layout, defect, P3)

Description

[Sean Richardson]

Summary:
If an IMG is unloadable, a box whose size is defined by the
width and height attributes will be drawn, but it will then disappear.

To Reproduce:
View the "(dis)Honouring IMG dimensions if unloadable" testcase attachment.
(best done with a slow link if the speculation below is valid)

Result:
As described in summary.

Expected:
The box for the unloadable image would remain, possibly with a "broken image"
icon inside it. (If the webpage author took the trouble to define the
image dimensions, why would they ever get rubbed out?)

Speculation:
The border disappears, a fraction of a second after it is drawn,
just after necko passes the message to gecko that the image is NOT
on its way.

Occurs on:
1999-10-15-11-M11 on Windows NT.

Comment 1

[Sean Richardson]

Attachment: (dis)Honouring IMG dimensions if IMG unloadable

Comment 2

[Masatoshi Kimura [:emk]]

Width/height should be ignored if IMG unloadable because width/height do not
apply to the inline non-replaced elements. See also the Bug 1994.

Comment 3

[Sean Richardson]

Ah, this is the crux of the matter. I fail to see why, just because it does
not load or cannot be loaded, and IMG should lose the only essential
attribute of its graphical nature that remains: its area.

If there is a specific part of the HTML 4.0 spec
( http://www.w3.org/TR/REC-html40/ ) that demands this, could someone
please point it out? I've looked, and I don't see it.

IMO, the essential problem here is a bug in HTML: there is no way for
an HTML author to explicitly define whether a specific image is a
replacement for text or an adjunct to text.

Some images, when used as adjunct illustrations, really are worth a thousand
words, for example an image whose ALT text would be "Screenshot showing
Communicator 4.x Proxy settings for Indianapolis campus."  Presumably the
context of this image would be written directions, but while both the image and
the text are meant to improve understanding of a topic, both have distinct
roles and neither could completely substitute for the other.

If, in this example, when the image failed to load, that ALT text were
placed in a box whose size was defined by the height and width attributes,
it would retain its semantic identity and provide a cue that the entire content
of the webpage is not at present available. If that same ALT text were to appear
inline with the same display properties as the surrounding text, it could
confuse.

Failing a new attribute in HTML 4.0, and I suppose it is way too late for that,
the ONLY proxy available as to whether an IMG is meant to replace text or
be an adjunct to text is the presence or absence of the height and width
attributes. Presumably authors who don't set height and width don't care
about the exact form of the display, and those who do set them, do care.

To put it another way, if the visual size of the image is undefined,
and the image cannot be loaded, it makes sense to treat the ALT text
as inline, but if the visual size is only UNCONFIRMED because the image
cannot be loaded, why throw away information that was coded by the
page author for a reason?

Reading the Status Whiteboard, the suggestion there makes sense.
Reading http://www.w3.org/TR/REC-html40/struct/objects.html, IMG and
OBJECT look to have no scope restrictions, although the DTD says not in PRE.
Reading http://www.w3.org/TR/REC-html40/sgml/dtd.html, OBJECT is defined as
%flow, but IMG is not defined as %flow, %block, or %inline. This feels like
an intentional ommission. In the wild, IMG is used is used in inline
contexts as part of a text flow, is also used as a block contexts,
set off from the text, and is also used in "semi-block" contexts, when floated
with align="left" or align="right".

Arguably, if an author wants a block context for an IMG, all that is needed
is to wrap it in a DIV (or of course in a TABLE).  But if I am understanding
correctly, this would not on its own stop the IMG node from losing its
dimensions if it cannot load. Also, if this was the only way to keep
the visual size of an IMG when the image (say, an illustrative photo) fails to
load, it would be necessary to use tables to be sure that it is positioned
beside the relevant text if it does not load. Ugh, Ugh, Double Ugh.
(If there is relevant CSS for this, it needs evangelism).

Note that I am not arguing here for preserving behaviour depended upon by
the "good old days" of table-based layout. I don't consider those to be
the good old days. There are many other contexts in which it makes sense
to want an image to take up area even if it does not load. Besides, those
who really want table cells to have specific sizes can use height and width
for their TDs.

Nor does this have anything to do with accessability. Braile browsers will
already be ignoring the height and width attributes.

What I am arguing for is to maintain the visual distinctiveness of what was
coded to be visually distinct for the purposes of semantic distinctiveness.
I know full well that for many, visual cues are useless, but for those of
us who will be using Mozilla as a graphical browser, that does not apply.

If an image MUST lose its dimensions when it cannot be loaded,
I would advocate using CSS background-color to provide a substitute
visual distinctiveness if the dimensions of the IMG are not undefined.

Also, if the disposition of this bug report is going to be WONTFIX,
be prepared for some evangelism in the face of shocked disbelief.
There are people who will want specific images set off from the text
even if the image does not load. What would they need to use? OBJECT?
Wrap IMG in DIV? CSS2 properties?

Out here on the periphery of the internet, random packet loss is a reality
when the backbones and exchange points get clogged.

Comment 4

[troy]

It's not an HTML issue, it's a CSS issue. The CSS2 spec states the the 'width'
and 'height' properties apply to inline replaced elements, but not to
inlinenon-replaced elements.

The IMG is a replaced element, but when it can be rendered we display its
alternate content. The alternate content is not inline replaced, it's inline
non-replaced

Comment 5

[Hixie (not reading bugmail)]

The alt attribute specifies alternate text that is rendered when the
image cannot be displayed. User agents must render alternate text when
they cannot support images, they cannot support a certain image type
or when they are configured not to display images.

The alternate text is just that: alternate. In other words, it should
be a textual alternative for the meaning of the image. It should
convey the same thing as the image.

Authors should not specify irrelevant alternate text when including
images intended to format a page, for instance, alt="red ball" would
be inappropriate for an image that adds a red ball for decorating a
heading or paragraph. In such cases, the alternate text should be the
empty string (alt=""). Authors are in any case advised to avoid using
images to format pages; style sheets should be used instead.

Authors should not specify meaningless alternate text (e.g., "dummy
text") either. Not only will this frustrate users, it will slow down
user agents that must convert text to speech or braille output.

The essential aspect of an image is _not_ its area; it is its meaning.
That the information is in graphical format is _not_ (usually)
essential.

> IMO, the essential problem here is a bug in HTML: there is no way
> for an HTML author to explicitly define whether a specific image is
> a replacement for text or an adjunct to text.

All images are replacements for text. Or rather, both text and images
are replacement for "meaning". That is to say, one can always be used
instead of the other -- both can be used to convey meaning -- but
sometimes one is much better at conveying a particular meaning than
the other.

> Some images, when used as adjunct illustrations, really are worth a
> thousand words, for example an image whose ALT text would be
> "Screenshot showing Communicator 4.x Proxy settings for Indianapolis
> campus."

That would *never* be a valid ALT text. It would be valid content for
the _title_ attribute, but not the alt attribute.

The relevant alternate text would be something like: "The proxy
settings dialog box has 'proxy.i.edu' in the 'host' field and '3128'
in the 'port' field for every protocol."

There should also be a page reading something like:

   ** Screenshot showing Communicator 4.x Proxy settings for
   Indianapolis campus. **

   The image depicts the Proxy Settings dialog box for the
   Communicator 4.x application as it is set for the Indianapolis
   campus. The dialog box has four rows of edit boxes, labelled HTTP,
   FTP, GOPHER and HTTPS. Each row has two edit boxes, aligned in two
   columns, with the labels 'host' and 'port' at the top.

   Each 'host' field has the content 'proxy.i.edu' and each 'port'
   field has the content '3128'.

This page should be linked to the <IMG> tag using the "longdesc"
attribute. The tag should therefore look like this:

   <IMG src="screenshot1.png" height="200" width="300"

        alt="The proxy settings dialog box has 'proxy.i.edu' in the
        'host' field and '3128' in the 'port' field for every
        protocol."

        title="Screenshot showing Communicator 4.x Proxy settings for
        Indianapolis campus."

        longdesc="screenshot1.desc.html"

        >

Note that the alt text is a replacement for the image, the title gives
a brief description (caption) of the image, and the longdesc file
gives a long description of the image.

> Presumably the context of this image would be written directions,
> but while both the image and the text are meant to improve
> understanding of a topic, both have distinct roles and neither could
> completely substitute for the other.

Not perfectly, no. But if the image is not present, then correct
alternative text, inline, is better than the image's title, in an
otherwise empty box! (And anyway, an empty box looks ugly.)

> If, in this example, when the image failed to load, that ALT text
> were placed in a box whose size was defined by the height and width
> attributes, it would retain its semantic identity and provide a cue
> that the entire content of the webpage is not at present available.
> If that same ALT text were to appear inline with the same display
> properties as the surrounding text, it could confuse.

The reader of the page frankly couldn't care less if the author has
made a mistake and the page is not completely available. The reader
wants the information. So if an image is not available, the page
should adapt. This is what alt text is designed to do.


Have you ever looked at what Lynx does with pages containing images?
When the author has written correct alternative text, the reader still
gets all the information, although obviously in a slightly less
efficient way than with them. But the reader is not told "Ooh, sorry,
my information is only worth reading if you can see images".

Mozilla is now doing this correctly.

[Verifying invalid.]