On 10/30/13 5:56 PM, Ryosuke Niwa wrote:
Interesting. Could you point me to the part of the spec. that mandates this
behavior?
http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#images-0
says:
When an img element represents some text and the user agent does
not expect this to change, the element is expected to be treated
as a non-replaced phrasing element whose content is the text,
optionally with an icon indicating that an image is missing, so
that the user can request the image be displayed or investigate
why it is not rendering. In non-graphical contexts, such an icon
should be omitted.
What an <img> represents is at
http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#the-img-element
if you search for "What an img element represents depends on the src
attribute and the alt attribute" (sadly no direct link there). The
relevant bit:
If the src attribute is set and the alt attribute is set to a value
that isn't empty
The image is a key part of the content; the alt attribute gives a
textual equivalent or replacement for the image.
If the image is available and the user agent is configured to
display that image, then the element represents the element's
image data.
Otherwise, the element represents the text given by the alt
attribute. User agents may provide the user with a notification
that an image is present but has been omitted from the rendering.
As far as I checked, Firefox is the only browser that exhibits this behavior.
Chrome, Internet Explorer, and Safari all show a missing-image box.
Yes, this is a known bug in Chrome, IE, and Safari. This bug makes
image alt text inaccessible to users who are not using assistive
technologies.
-Boris
P.S. For those who care about the W3C HTML spec, not the WHATWG one,
see http://www.w3.org/html/wg/drafts/html/master/rendering.html#images-0
and
http://www.w3.org/html/wg/drafts/html/master/embedded-content-0.html#the-img-element
for equivalent text.
