The default bug view has changed. See this FAQ.
Bug 41924 (alttext)

Change how layout handles broken images (alt text)

NEW
Unassigned

Status

()

Core
Layout: Images
P1
major
17 years ago
10 months ago

People

(Reporter: Hixie (not reading bugmail), Unassigned)

Tracking

(Depends on: 3 bugs, Blocks: 2 bugs, {access, top100})

Trunk
Future
access, top100
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.2 -
wanted1.9.2 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Hixie-P1] TODO: see comment 179 (py8ieh: reexamine test case), URL)

Attachments

(5 attachments, 2 obsolete attachments)

(Reporter)

Description

17 years ago
We need to change how to display images when Mozilla is not displaying the 
actual graphics. This can happen when images are disabled, blocked, not yet
downloaded, or simply broken.

These can be IMG elements or INPUT elements which have the "type" attribute set 
to "image".

The following specification is based on 
   http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/altspec.txt
...but does not include the additional features to be introduced in the next
version of Mozilla.

To display the placeholders/alternative text, Mozilla needs to work out what to
use as Alternative Text and what to use for an Icon. It then needs to use these
to create a Placeholder that replaces the IMG or INPUT element in question.

Alternative Text
----------------

If the IMG or INPUT element has an "alt" attribute, then the contents
of that attribute should be used as the alternate text.

Otherwise, the alternate text should be the contents of the first of
the following attributes that is present on the IMG or INPUT element:

   title
   id
   name

Experience has shown that the filename is considerably less useful
than would be first thought, and therefore we should ignore it when
inventing the alternate text.

In Mozilla, this has to be implemented in the function called
GetAlternateTextFor.

   http://lxr.mozilla.org/seamonkey/search?string=GetAlternateTextFor


Icon
----

Alternative text will be prefixed by an icon (as described below). The
icon is chosen from the following list:

  For images that have not been downloaded, use a generic image or object icon.

  For images that are known to be broken, use the broken image or object icon.

In future releases this proposal will introduce:

  For images that have been blocked, a blocked image icon.

  For images that are in a format not supported by Mozilla, an unknown 
  format icon.

In the next section, when referring to "an icon", the icon should be chosen 
from the list above.


Placeholders
------------

If an image cannot or will not be shown, then:

  For images that have not been downloaded but are about to be (i.e. for images
  that are not blocked, when images are enabled):

    If the "height" and "width" attributes are given, create a *borderless* box 
    with the height and width given (interpret the height and width attributes 
    as pixel lengths) and a transparent background.

    Insert an image icon inside the placeholder (regardless of the existence of 
    any alternative text).

    If there is any alternative text, then insert it after the image icon in 
    the placeholder frame.

    If the frame is too small for the icon and/or the alternative text then 
    they will be clipped, just like with the CSS declaration "overflow:hidden". 

  For ALL other cases (blocked images, images not downloaded in "Don't Load 
  Images" mode, broken images, unrecognised images, and images not downloaded 
  and with no "height" and "width" attributes):

    Replace the IMG or INPUT frame with an empty inline element.

    If there is any alternative text then insert a text frame containing an
    image icon inside the IMG or INPUT element.

    If there is any alternative text, then insert it after the image icon in 
    the text frame.

These IMG and INPUT frames should be treated just like any other frame as far 
as style resolution is concerned.

The image-followed-by-alternative-text is equivalent to the pseudo-CSS3:
   content: url(icon) alternative-text;
This is why I say the image icon should go in the _text_frame_ (internally it 
very probably does not in fact).

The icons should be relatively small so as not to disrupt most text but be 
easily clickable, for instance 16 pixels by 16 pixels square.

There should never be a sized placeholder frame for an image where we do not 
know the size.
(Reporter)

Comment 1

17 years ago
There is a testcase of this behaviour here:
   http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/IMGalt2.html

Various bugs are about to marked DUPs of this one. Bug 34981 is marked:

------- Additional Comments From Michael La Guardia 2000-06-02 16:07 -------
putting on nsbeta2+ radar.  Will become minus on 6/15.  We won't be holding the
beta for this.
Blocks: 7954
Severity: normal → major
Keywords: nsbeta2
Priority: P3 → P2
Whiteboard: [nsbeta2+] 6/15
(Reporter)

Comment 2

17 years ago
*** Bug 34981 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 3

17 years ago
*** Bug 40623 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 4

17 years ago
*** Bug 23691 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 5

17 years ago
*** Bug 24125 has been marked as a duplicate of this bug. ***

Comment 6

17 years ago
changing to [will be minus on 6/15], a more common radar
Whiteboard: [nsbeta2+] 6/15 → [nsbeta2+] [will be minus on 6/15]

Comment 7

17 years ago
Re-assigning to myself for further investigation...
Assignee: clayton → nisheeth

Comment 8

17 years ago
I'm going to attach a patch that computes the alt text correctly.  I believe 
that we display the icon properly already.  I'm going to defer the 
implementation of the logic specified in the "Placeholders" section of your 
comment till after beta2.
Status: NEW → ASSIGNED

Comment 9

17 years ago
Created attachment 10214 [details] [diff] [review]
Patch to GetAlternateTextFor()
Ian -- I'm curious why you think the ID attribute will work well for alternate 
text (and the NAME attribute for any elements other than INPUT).  I think these 
attributes are used mainly for JS scripting, and I think names for JS scripting 
are probably just as useful as filenames.

Comment 11

17 years ago
I should correct myself and say that the attached patch implements what Ian's 
bug report specified and not that it "computes the alt text correctly".  Based 
on David's comment, it seems that we still need to determine whether Ian's 
suggested implementation is the best approach.

I'm going to hold off on checking in the patch till after beta 2.  Please let 
this bug fall off the beta 2 radar.  Thanks.

Comment 12

17 years ago
Setting target milestone to M18...
Target Milestone: --- → M18
(Reporter)

Comment 13

17 years ago
A good point, David. That particular section of my spec is based on
work by many other people, with emphasis on simplification (hence why
I do not recommend that we use the "height" and "width" attributes to
heuristically determine whether an image is a ruler or a bullet or
more important). Most other specs work on the principle that 'id' and
'name' (and the filename) are close to human readable. We found
through experience that this is not the case with the filename. Should
we therefore also assume that it is not the case with the "id" and
"name" attributes?

I just examined the source of a random selection of top100 sites, and
found that in fact there are precious few pages which stick "id" on
<img> elements and also rather few that use "name" on image inputs. Of
those that did, your (David's) suspicions were right: they were mainly
two letter codes or long strings of numbers: not very useful to us.

My revised recommendation would therefore be to yank the 'name' and
'id' parts of the alt code generator altogether, leaving only 'alt'
and 'title', and defaulting to blank.

Nisheeth: Sorry sorry sorry about changing the spec _again_; thankfully 
this is just a very minor change and should take you very little time
to take into account... Thanks for implementing this!

David: Name is now valid on IMG, see HTML 4.01.

Note that I will need to reexamine my test case to make sure it does not expect
'name' and 'src' to be used to generate alternate text. It has not yet been 
updated to use the most recent recommendation on how to generate alternate text.
Whiteboard: [nsbeta2+] [will be minus on 6/15] → [nsbeta2+] [will be minus on 6/15] (py8ieh: reexamine test case)
But I think it probably is a good idea to use the name attribute for INPUT 
elements.
(Reporter)

Comment 15

17 years ago
When I was looking around the top100, I found very few form elements
with NAME attributes that were useful to the reader (in fact, none).

Of the top 100 sites on the list I have, 38 had text matching
   s/type *= *['"]? *[iI][mM][aA][gG][eE]/gos
...on their main page.

Here are the results (one line per image button):

  www.abcnews.com: alt="go!" value="Go City"
  www.abcnews.com: 
  www.altavista.com: name="search" alt="Search"
  www.amazon.com: name="Go" value="Go"
  www.angelfire.com: alt="go get it!"
  www.angelfire.com: alt="Go Get It!" 
  www.att.com: alt="Go." name="image"
  www.att.net: alt="Go." name="image"
  www.att.net: alt="Shop." name="image"
  www.att.net: alt="Go." name="image"
  www.att.net: alt="Go." name="image2"
  www.barnesandnoble.com: name="Go!" alt="Search"
  www.barnesandnoble.com: alt="Go!" 
  www.barnesandnoble.com: name="Sign Up!" alt="Sign Up"
  www.beyond.com: name="GO!" value="GO!" 
  www.beyond.com: name="GO!" value="GO!" 
  www.broadcast.com: name="newsletter" alt="Go"
  www.cnn.com: name="submit"
  www.cnn.com: value="Go"
  www.cnnsi.com: name="submit"
  www.dejanews.com:
  www.demon.net: alt="submit"
  www.digitalcity.com: name=submit
  www.earthlink.net: name="IMAGE" value="Submit Search" alt="To GoTo.com"
  www.earthlink.net: alt="Subscribe"
  www.ebay.com: alt="Find It!" value="Find It"
  www.egghead.com: value="Look Up"
  www.flash.net: 
  www.flash.net: 
  www.fortunecity.com:
  www.freeyellow.com:
  www.goto.com: alt="Find It" name="Find It!"
  www.hotbot.com: alt="Search"
  www.hotbot.com: name="act.super" value="+Revise+"
  www.icq.com: name="Go"
  www.ivillage.com:
  www.ivillage.com:
  www.lycos.com: alt=""
  www.mindspring.com: 
  www.miningco.com: alt="Go" name="Action"
  www.msn.com: alt="Begin your Web search" id="y"
  www.msn.com: alt="Sign in to Hotmail" id="m"
  www.netcom.com:
  www.pathfinder.com: name="x2"
  www.sidewalk.com: value="Go!"
  www.theglobe.com:
  www.travelocity.com: value="Search"
  www.travelocity.com: value="GO"
  www.tripod.com: alt="gogetit" 
  www.usatoday.com: alt="go Get It"
  www.usatoday.com:
  www.washingtonpost.com: name="go"
  www.washingtonpost.com: name="getquotes"
  www.washingtonpost.com: alt="Go Out!" name="GO"
  www.washingtonpost.com:
  www.weather.com: alt="go!" value="Go City"
  www.weather.com: alt="go!"
  www.xoom.com: value="Search"

From the 58 image inputs,
   28 had an alt attribute
   24 had a name attribute, of which
   15 had a useful name attribute 
   14 had a value attribute, all useful
   13 had no useful attributes
   10 had a value and no alt
    9 had a bad name attribute
    2 had an id attribute, all bad

So: I would stick to my new stance that we should not use the 'name'
attribute. However... while I am encouraged by the 28 with the 'alt'
attribute, I am slightly worried by the fact that this means that 30
(just more than 50%) of the image inputs would disappear altogether
when images are disabled. This leads me to propose that what we do for
image inputs be similar to what we do for normal buttons: use the text
of "value" if "alt" is not present, and then if that is not present,
the default text "Submit" (translated for each locale). However, this will 
probably be too time consuming for FCS. 

How does the normal submit button get its default text? Anyone know?
Can we possibly leverage some of that code?

Comment 16

17 years ago
Marking nsbeta2-, now that 6/15 has passed.
Whiteboard: [nsbeta2+] [will be minus on 6/15] (py8ieh: reexamine test case) → [nsbeta2-](py8ieh: reexamine test case)

Comment 17

17 years ago
*** Bug 42921 has been marked as a duplicate of this bug. ***

Comment 18

17 years ago
Marking nsbeta3...
Keywords: nsbeta3

Comment 19

17 years ago
*** Bug 44205 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 20

17 years ago
*** Bug 44647 has been marked as a duplicate of this bug. ***

Updated

17 years ago
Blocks: 40785

Updated

17 years ago
No longer blocks: 40785

Updated

17 years ago
Keywords: 4xp, correctness
(Reporter)

Updated

17 years ago
Blocks: 8979
Depends on: 11011
Summary: Change how layout handles broken images → Change how layout handles broken images (alt text)
(Reporter)

Comment 21

17 years ago
*** Bug 47383 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 22

17 years ago
*** Bug 47383 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 23

17 years ago
*** Bug 42474 has been marked as a duplicate of this bug. ***
(Reporter)

Updated

17 years ago
Keywords: mostfreq
(Reporter)

Comment 24

17 years ago
*** Bug 48354 has been marked as a duplicate of this bug. ***

Comment 25

17 years ago
*** Bug 48354 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 26

17 years ago
*** Bug 48612 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 27

17 years ago
*** Bug 48655 has been marked as a duplicate of this bug. ***

Comment 28

17 years ago
This bug has been marked nsbeta3- because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another
known resource will be working on this bug,or if it blocks your work in some way 
-- please attach your concern to the bug for reconsideration, but do not clear 
the nsbeta3- nomination.
Whiteboard: [nsbeta2-](py8ieh: reexamine test case) → [nsbeta2-][nsbeta3-](py8ieh: reexamine test case)

Comment 29

17 years ago
Well, yeah, I don't really think a mostfreq bug should be nsbeta3- (and 
futured, which this likely will be soon).  Can someone explain what remains to 
be done here, so I can take a look when I return?
(Reporter)

Comment 30

17 years ago
*** Bug 49760 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 31

17 years ago
Per Eric Krock in bug 49760: "Whatever's causing this is a clear must-fix for
nsbeta3."

Ok, so we are running out of time for 6.0. Here is the thing I believe
absolutely must be fixed for this release, and I *would* pull the build off the
wire for it: We should *not* use the filename as alternative text.

We already have a patch for this (see 1st attachment). The patch could be
improved to use the value of the 'value' attribute instead of the 'name'
attribute. However, this is an incredibly easy change.

We can delay the placeholder sizing and the icon placing for first release, I
could live with that. But if we continue using the filename (as I originally
said we should) then this may become one of the most often reported bugs. And
sometimes it can be difficult to spot that this is the bug.

Removing [nsbeta3-] to retrigger evaluation in light of above 'quick-fix'.
Keywords: top100
Whiteboard: [nsbeta2-][nsbeta3-](py8ieh: reexamine test case) → [nsbeta2-](py8ieh: reexamine test case)
Actually, I have REOPENed bug 49760 because I don't believe it's a DUP of this 
bug. Bug 49760 appears to be a case of composite URLs from the sidebar (which 
are a combination of two URLs concatenated together) causing the browser to fail 
to find linked image files (that's the bug) which then causes the images to 
display as broken, triggering the behavior noted in this bug. So my comments in 
bug 49760 don't apply to this bug.

Comment 33

17 years ago
*** Bug 47301 has been marked as a duplicate of this bug. ***

Comment 34

17 years ago
*** Bug 50294 has been marked as a duplicate of this bug. ***

Comment 35

17 years ago
> and then if that is not present, the default text "Submit" (translated for
> each locale). However, this will probably be too time consuming for FCS.

Actually, we already have a default, localized text string for use on Submit
buttons that could be re-used for image inputs when images are turned off.  For
English, the string is "Submit Query", and that might also be a reasonable thing
to use for image inputs.  Here's a snippet of code used to get that string:

nsAutoString str;
nsFormControlHelper::GetLocalizedString("Submit", aString);

The function nsFormControlHelper::GetLocalizedString to get the localized string
from a locale file string bundle is already written and tested, and is located
in mozilla/layout/html/forms/src/nsFormControlHelper.cpp

If this string is not acceptable, an alternative key/value could also be added
with just a few lines of code.  If we decide to implement this and the
imlementor needs assistance, just drop me a line!  :)

Comment 36

17 years ago
This got triaged too aggressively.  I agree that it'll be bad to ship without 
the attached patch.  Putting on the nsbeta3+ radar...
Whiteboard: [nsbeta2-](py8ieh: reexamine test case) → [nsbeta2-][nsbeta3+](py8ieh: reexamine test case)

Updated

17 years ago
Whiteboard: [nsbeta2-][nsbeta3+](py8ieh: reexamine test case) → [nsbeta2-][nsbeta3+][fixinhand](py8ieh: reexamine test case)
(Reporter)

Comment 37

17 years ago
Eric: Cool!

Nisheeth: Note that the patch needs tweaking slightly to use the 'value'
attribute instead of the 'name' attribute, for INPUT elements, and if 
the 'value' attribute is empty, to use the code Eric kindly gave us:

   nsAutoString str;
   nsFormControlHelper::GetLocalizedString("Submit", str);

...and use the value returned in 'str' instead (for INPUT elements). Feel free
to call me if you have a question about this (since the 'spec' has been through
so many revisions...).
Whiteboard: [nsbeta2-][nsbeta3+][fixinhand](py8ieh: reexamine test case) → [nsbeta2-][nsbeta3+][fixinhand] (py8ieh: reexamine test case)

Comment 38

17 years ago
Ian, please check if the following implementation for GetAlternateTextFor() is 
correct.  Thanks!

static void
GetAlternateTextFor(nsIContent* aContent,
                    nsIAtom*    aTag,  // content object's tag
                    nsString&   aAltText)
{
  nsresult  rv;

  // The "alt" attribute specifies alternate text that is rendered
  // when the image can not be displayed
  rv = aContent->GetAttribute(kNameSpaceID_HTML, nsHTMLAtoms::alt, aAltText);
  if (NS_CONTENT_ATTR_NOT_THERE == rv) {
    // If there's no "alt" attribute, then use the value of the "title"
    // attribute. Note that this is not the same as a value of ""
    rv = aContent->GetAttribute(kNameSpaceID_HTML, nsHTMLAtoms::title, 
aAltText);
  }
  if (NS_CONTENT_ATTR_NOT_THERE == rv) {
    // If there's no "alt" or "title" attribute, use the value of the "value" 
attribute
    rv = aContent->GetAttribute(kNameSpaceID_HTML, nsHTMLAtoms::value, 
aAltText);
  }
  if (NS_CONTENT_ATTR_NOT_THERE == rv) {
    // If there's no "value" attribute, either, and aContent is an input element
    // use the localized string for "Submit" as the alternate text.
    if (nsHTMLAtoms::input == aTag) {      
      nsFormControlHelper::GetLocalizedString("Submit", aAltText);      
    }
  }
}

Comment 39

17 years ago
Don't you want to use kNameSpaceID_None when fetching the attributes? Otherwise,
in XHTML, you won't find them, e.g., if...

  <html:img alt="blah" />
(Reporter)

Comment 40

17 years ago
Good catch by Chris. Also, we don't want to be looking at the 'value' attribute
if the element is not an HTML input.

Questions:
   1. Does (nsHTMLAtoms::input == aTag) only match HTML elements? i.e., would
      it match an XML element <input> that was in no namespace, for instance?
   2. Is nsFormControlHelper always available? (Is it a class or an object?
      My C++ knowledge is non-existant.)
   3. Is aAltText preinitialized by the caller of GetAlternateTextFor() ?
   4. In HTML4, are the attributes in kNameSpaceID_None ?
   5. Is the code I have pasted below worthy of an r=?

If all five questions get the reply 'yes' then I am ok with a checkin. :-)


static void
GetAlternateTextFor(nsIContent* aContent,
                    nsIAtom*    aTag,  // content object's tag
                    nsString&   aAltText)
{
  nsresult  rv;

  // The "alt" attribute specifies alternate text that is rendered
  // when the image can not be displayed
  rv = aContent->GetAttribute(kNameSpaceID_None, nsHTMLAtoms::alt, aAltText);

  // If there's no "alt" attribute, then use the value of the "title"
  // attribute. Note that this is not the same as a value of ""
  if (NS_CONTENT_ATTR_NOT_THERE == rv) {
    rv = aContent->GetAttribute(kNameSpaceID_None, nsHTMLAtoms::title, 
                                aAltText);

    // If there's no "alt" or "title" attribute, and aContent is an input    
    // element, then use the value of the "value" attribute
    if ((NS_CONTENT_ATTR_NOT_THERE == rv) && (nsHTMLAtoms::input == aTag)) {
      rv = aContent->GetAttribute(kNameSpaceID_None, nsHTMLAtoms::value,
                                  aAltText);

      // If there's no "value" attribute either, then use the localized string 
      // for "Submit" as the alternate text.
      if (NS_CONTENT_ATTR_NOT_THERE == rv) {
        nsFormControlHelper::GetLocalizedString("Submit", aAltText);      
      }
    }
  }
}
Do you want to use the localized string for "Submit" for an <input type=reset>?
(Reporter)

Comment 42

17 years ago
*** Bug 50699 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 43

17 years ago
dbaron: How would an <input type="reset"> ever go through this code path?
I accept your point though. We _could_ check the 'type' attribute and only
use the Submit string if it matches 'image' (case insensitive).

Comment 44

17 years ago
Ian, the answer to all five of your questions is yes.  I've checked in the patch    
that you pasted in your comment timestamped "2000-08-30 02:00".

Marking bug later.  We can implement the rest of the functionality Ian has 
proposed post rtm.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → LATER
(Reporter)

Comment 45

17 years ago
*** Bug 50198 has been marked as a duplicate of this bug. ***
py8ieh=bugzilla@bath.ac.uk - please could you tell me whether this bug should 
disappear from the MFB list, seeing as it's been Resolved LATER. 

AIUI, LATER is now deprecated in favour of Milestone "Future" - is there some 
reason why that has not happened to this bug?

Would it be easier to open a new bug for the remaining problems?

Gerv
(Reporter)

Comment 47

17 years ago
Gerv: no, it should stay on the MFB list. Why would LATER mean it is no longer
frequently reported??

This bug is LATER instead of Future because if it was Future then the [nsbeta3+]
would be messing up queries. Let's leave it as Future until we go past nsbeta3.

Yes, it might be easier to open a new bug. I may do this. Stealing QA.
I am NOT verifying LATER since doing so would remove it from my radar.
QA Contact: petersen → py8ieh=bugzilla
Whiteboard: [nsbeta2-][nsbeta3+][fixinhand] (py8ieh: reexamine test case) → [nsbeta2-][nsbeta3+] (py8ieh: reexamine test case)
(Reporter)

Comment 48

17 years ago
VERIFIED Win2K and Linux Comm M18 trunk builds 2000090609.

Comment 49

17 years ago
Verified what?

Meanwhile, here's a silly idea I've been thinking over for a while ... instead of 
showing the placeholder icon to the left of the replacement text, show it *above* 
the left edge of the replacement text (or the right edge of the replacement text, 
if in a RTL environment). This allows better use of alt text to replace images, 
because the placeholder icons do not disturb the flow of the text so much.

For example, if I have
|
| <p>Hickson is pronounced <span title="IPA symbols not present in ISO-8859-1
| are shown using images, or alternatively using Arpabet">/h<img src="ih.gif"
| alt="ih"/>k s<img src="ix.gif" alt="ix"/>n/</span>.</p>
|,
instead of appearing as
|                          _       _
| Hickson is pronounced /h[%]ihk s[%]ixn/.
|
it would appear as
|                          _     _
|                         [%]   [%]
| Hickson is pronounced /hih k six n/.
|
(which would be easier to read).

The downside of this idea is that it would require more in-line vertical space.

Comment 50

17 years ago
Later? This bug should remain open, on a Future milestone. 
Status: RESOLVED → REOPENED
Resolution: LATER → ---

Comment 51

17 years ago
Since this has nsbeta3+ in the status whiteboard, I'm leaving this reopened for 
triage.
Target Milestone: M18 → Future

Comment 52

17 years ago
Marking the bug beta3- so that it gets off the beta3+ radar.  The remaining work 
on this bug will not happen till post Netscape 6 rtm.
Status: REOPENED → ASSIGNED
Whiteboard: [nsbeta2-][nsbeta3+] (py8ieh: reexamine test case) → [nsbeta2-][nsbeta3-] (py8ieh: reexamine test case)

Comment 53

17 years ago
Nominating for mozilla0.9 milestone.
Keywords: mozilla0.9

Updated

17 years ago
Blocks: 58646

Comment 54

17 years ago
Setting to mozilla0.9. I think this is an important bug to fix.
Target Milestone: Future → mozilla0.9

Comment 55

17 years ago
IMHO researching the top-100 sites for commonly used names only is bit of a
methodical error. They are typically datebase driven and their text and images
are generated at least half-automaticaly, which results in filenames that are
not thought to be human readable.

But what about those handcoded bottom-1000000000 sites where image files have
names like 'green-arrow-left.gif' and 'susan.jpg'?

Go down to private people's sites and see that image names may be usefull as
emergency-replacement for missing alt attributes in many cases.

But except for the real ALT-attribute (that has to be designed to replace the
image fluently) the user should still see that this is not usual text-content
but "something replaced".
(Reporter)

Comment 56

16 years ago
*** Bug 55046 has been marked as a duplicate of this bug. ***
(Reporter)

Updated

16 years ago
Blocks: 62046

Updated

16 years ago
Blocks: 65747

Comment 57

16 years ago
Moving to 0.9.1...
Target Milestone: mozilla0.9 → mozilla0.9.1
(Reporter)

Updated

16 years ago
Whiteboard: [nsbeta2-][nsbeta3-] (py8ieh: reexamine test case) → [Hixie-P3] [nsbeta2-][nsbeta3-] (py8ieh: reexamine test case)

Comment 58

16 years ago
-> 0.9.2
Target Milestone: mozilla0.9.1 → mozilla0.9.2

Comment 59

16 years ago
*** Bug 82102 has been marked as a duplicate of this bug. ***

Comment 60

16 years ago
*** Bug 83233 has been marked as a duplicate of this bug. ***

Updated

16 years ago
Priority: P2 → P1

Comment 61

16 years ago
*** Bug 87590 has been marked as a duplicate of this bug. ***

Updated

16 years ago
Target Milestone: mozilla0.9.2 → mozilla0.9.3

Updated

16 years ago
Keywords: nsenterprise

Updated

16 years ago
Blocks: 87328

Comment 62

16 years ago
*** Bug 88722 has been marked as a duplicate of this bug. ***

Comment 63

16 years ago
*** Bug 89399 has been marked as a duplicate of this bug. ***

Comment 64

16 years ago
*** Bug 89577 has been marked as a duplicate of this bug. ***

Comment 65

16 years ago
*** Bug 89589 has been marked as a duplicate of this bug. ***

Comment 66

16 years ago
Doesn't look like this is getting fixed before the freeze tomorrow night. 
Pushing out a milestone.  Please correct if I'm mistaken.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
*** Bug 92871 has been marked as a duplicate of this bug. ***

Comment 68

16 years ago
*** Bug 95592 has been marked as a duplicate of this bug. ***

Comment 69

16 years ago
>------- Additional Comments From Simon Fraser 2000-11-02 13:04 -------
>
>Setting to mozilla0.9. I think this is an important bug to fix.

ok. that was 9 months ago. this bug has been reported at least 31 times in the
last 14 months. it was pushed on to the next milestone at least 3 times.
is anything going to be done about it?
(Reporter)

Comment 70

16 years ago
Here are the issues that must be fixed, in addition to the dependent bugs:

   1. Make the alternate text frames still have the image menu, and in 
      particular, have a "show image" item.
   2. Make sure that when images are disabled, they are replaced by the alt text
      and not by an empty placeholder frame.
   3. Add a new preference, like in Lynx, to deal with badly designed pages:
        [ ] Always show icons and alternate text when an image isn't
            displayed.
   4. Alternate text should be prefixed by an icon as described in the "Icons"
      section of the alt text spec. If there is no alternate text, then there
      should be no icon (unless the pref in step 3 is checked).
   5. Placeholder frames should make sure they are drawn as described in the
      last section of the spec.
   6. The content nodes should know how to replace their alternate text frames
      with image frames when the src attribute is changed.

The spec is at: http://www.hixie.ch/specs/alttext
No longer blocks: 8979, 58646, 62046, 65747, 87328
No longer depends on: 11011
Whiteboard: [Hixie-P3] [nsbeta2-][nsbeta3-] (py8ieh: reexamine test case) → [Hixie-P3] [Hixie-1.0] (py8ieh: reexamine test case)
(Reporter)

Updated

16 years ago

Comment 71

16 years ago
Most of the changes need to happen over in layout.  Sorry for keeping this bug
on my plate for so long.  Re-assigning to Marc Attinasi.
Assignee: nisheeth → attinasi
Status: ASSIGNED → NEW

Updated

16 years ago
Target Milestone: mozilla0.9.4 → mozilla1.0

Comment 72

16 years ago
Removing nsenterprise nomination.
Keywords: nsenterprise

Comment 73

16 years ago
Ummmm... I thought that no one removed the nsenterprise nomination. Its a +/-
keyword like nsbeta1.  If the nsenterprise team deems it to not be a enterprise
showstopper, it gets the nsenterprise- keyword.

Adding back nsenterprise keyword. (Since this really does fit the description)
If someone feels that this is inappropriate, please post why.
Keywords: nsenterprise

Updated

16 years ago
Blocks: 98561

Comment 74

16 years ago
> 3. Add a new preference, like in Lynx, to deal with badly designed pages:
>    [ ] Always show icons and alternate text when an image isn't displayed.

For such a pref to be useful, the pages frequented by one group of people would
have to (almost) always be well-designed, while the pages frequented by another
group of people would have to (almost) always be badly-designed. That doesn't
seem realistic to me; this checkbox seems more like a protest than a preference,
and protests should really be on Mozilla's Web site rather than in the prefs
dialog. (Note that the [IMAGE] in Lynx is considerably more annoying, especially
for screen readers, than an image icon in Mozilla would be.)

> 4. Alternate text should be prefixed by an icon as described in the "Icons"
>    section of the alt text spec. If there is no alternate text, then there
>    should be no icon (unless the pref in step 3 is checked).

By `there is no alternate text', do you mean alt="", or alt is not present? In
both cases, the fact that you have image loading turned off by default doesn't
necessarily mean that you never want to load the image -- especially if it is an
illustration of the surrounding text and therefore has alt="" or no alt at all.
So any unloaded image, IMO, needs an icon no matter what its alt status is.
(Reporter)

Comment 75

16 years ago
From http://www.hixie.ch/advocacy/alttext :

---8<---

This is why I had three prefs:

   1. You want images (graphical browser), 
   2. You want images, but only when you ask for them,
   3. You don't want the images at all (text browser).

There is no way we can have "show icons for all images" enabled by
default (and the only option) -- that would make pages literally
unreadable. If you don't believe me, try browsing the web with the
following in your html.css file:

   img[width="1"]  { padding: 0.5em !important; border: solid red !important; }
   img[width="2"]  { padding: 0.5em !important; border: solid red !important; }
   img[width="3"]  { padding: 0.5em !important; border: solid red !important; }
   img[width="4"]  { padding: 0.5em !important; border: solid red !important; }
   img[width="5"]  { padding: 0.5em !important; border: solid red !important; }
   img[height="1"] { padding: 0.5em !important; border: solid red !important; }
   img[height="2"] { padding: 0.5em !important; border: solid red !important; }
   img[height="3"] { padding: 0.5em !important; border: solid red !important; }
   img[height="4"] { padding: 0.5em !important; border: solid red !important; }
   img[height="5"] { padding: 0.5em !important; border: solid red !important; }

Try, for example, some of the following:
   http://home.netscape.com/ 
   http://www.microsoft.com/ 
   http://www.hp.com/ 
   http://www.ibm.com/
   http://www.bbc.com/

It is extremely nasty. Now, instead of the above lines, insert the following:

   img[width="1"] { display: none !important; }
   img[width="2"] { display: none !important; }
   img[width="3"] { display: none !important; }
   img[width="4"] { display: none !important; }
   img[width="5"] { display: none !important; }
   img[height="1"] { display: none !important; }
   img[height="2"] { display: none !important; }
   img[height="3"] { display: none !important; }
   img[height="4"] { display: none !important; }
   img[height="5"] { display: none !important; }

...and try those sites again.

(Note that the above is only a rough approximation of what it would
really feel like, so don't draw too many conclusions from this.)

---8<---

Also note that in Lynx, one can switch between spec-compliant mode and "always
show alt text" mode by hitting one key. (IMHO, ideally it would be the same in 
Mozilla, but for some reason we have an aversion to one-key accelerators.)

(By "alternate text" I mean whatever was found using the algorithm to find the
alternate text, as described above. The 'alt' attribute is only one of several
inputs to that algorithm.)

Comment 76

16 years ago
*** Bug 101898 has been marked as a duplicate of this bug. ***

Updated

16 years ago
Blocks: 101058

Comment 77

16 years ago
*** Bug 102568 has been marked as a duplicate of this bug. ***

Comment 78

16 years ago
*** Bug 102803 has been marked as a duplicate of this bug. ***

Updated

16 years ago
Blocks: 58662

Comment 79

16 years ago
marking nsenterprise-; will be reevaluated for nsenterprise in future release.

Keywords: nsenterprise-
(Reporter)

Updated

16 years ago
Blocks: 103709

Comment 80

16 years ago
This bug really hurts the Composer App. If an image is broken, we really need a 
small frame that represents the image tag so a user can look at the properties of 
that image. It may be a simple case that the image has moved or is mistyped and the 
user simply needs to change the URL in Composer's Image properties dialog.
With the current behavior, this is not possible in "Normal" mode, since there is 
no display object. Note that if user switches to "Show all tags" mode, designed
for advanced users, we load a style sheet that shows a small yellow image:
  background-image: url(chrome://editor/content/images/tag-img.gif);
That enables the user to click on and edit the properties. So using something like 
this rule or "before" CSS might work in Normal mode as well.

Comment 81

16 years ago
Moving up - alt text is my new crusade (along with floats). 
Status: NEW → ASSIGNED
Target Milestone: mozilla1.0 → mozilla0.9.7

Comment 82

16 years ago
Not to mention the troubles in Editor, I find it impossible to navigate through
image links if it is broken.... or simply when I disable image loading when I am
on a 33.6kpbs modem dialup to avoid loading of monster size images!

Updated

16 years ago
Blocks: 102281

Comment 83

16 years ago
My current plan is to take most of what Hixie and others wrote up (altspec.txt)
and implement it. Specifically, this will entail the following:

* Get the correct replacement text for the element (ALT attribute if present, or 
  TITLE   attribute if present, and Quirks mode may cause TITLE to be ignored)
* Create an inline box to hold an image-icon and the replacement text. This will 
  take the size of the IMG if provided, otherwise it will shrink-wrap the image 
  and replacement text. The inline box will have overflow:hidden.
* Create two image-icons, one for broken images and one for blocked images 
  (16px X 16px)

Currently we just create a text node and create a frame for it in
nsCSSFrameConstructor::ConstructAlternateFrame - Now, the idea is to create an
inline container with an image and the replacement text instead. This inline
container will be a new frame that is conceptually part of the ImageFrame, but
is used for OBJECT and APPLET elements that are inline too. (Too bad we don't
already have a sizeable inline frame that is not a form control - or do we and I
just don't know?)

The style of the replacement text's inline box will be specified by a pseudo tag
:-moz-replacement-text, so it can be altered pretty easily in html.css or
quirks.css.

One nagging question is the border - IE puts a border around the box with the
icon and ALT text, and even puts any CSS-specified border around that! So, for
Quirks mode it might be best to put a border - not sure yet.

Comment 84

16 years ago
Looks like imageFrame handles most of this already, it is just being bypassed by
a call to presShell->CantRenderReplacedElement. If we stop calling that then
there is already lots of the code needed to put the alt text into the 'box' of
the image frame - and it mostly works. There was once the ability to load icon
images too, and to show the broken / blocked image icons, but that was lost when
libPr0n was landed :( As a temporary hack I am using a background-image on the
IMG element to show the 'icon', but that has to be replaced with some c++ code
so the broken vs. blocked icon can be used (and to avoid interfering with legit
images). I think the images needed for the icons can be loaded during
initialization so they are always ready to draw...

There are also some problem when only the height or the width are specified, and
I still have to check the percentage width and height behaviors. I think that
these are general IMG problems, not just for ALT text.

Oh, and the FrameConstructor method GetAlternateTextFor needs to be made
available to the imageFrame so it does not have to duplicate the logic.

Updated

16 years ago
No longer blocks: 102281
(Reporter)

Comment 85

16 years ago
From reading the above it seems that you are saying that broken images with 
sizes will have the alt text placed in that size? If so that is very wrong... 
The only cases where the placeholder frame should be sized is for images that 
have not yet been downloaded but are about to be (i.e. for images that are not 
blocked and when images are enabled) and that explicit have "height" and 
"width" attributes (the height and width CSS properties are irrelevant here).

The box, when created, should be borderless and have a transparent background.
(Reporter)

Updated

16 years ago
Depends on: 53441

Comment 86

16 years ago
There are problems with the email and editor programs when a broken image is not
given a sized box - see the comments in this bug (Comments From Charles Manske
2001-10-23 11:56, Comments From percy@py.dhs.org 2001-10-25 06:58).

Also, if image loading is turned OFF, then most web pages look like total crap
unless we honor the sizes and thus keep the layout the same as if the image was
there.

If this causes a standards violation, then I have no problem differentiating
between standards and quirks mode for the sizing, but I don't know what spec it
is violating (except of course for the one on hixix.ch).

>From reading the above it seems that you are saying that broken images with 
>sizes will have the alt text placed in that size? If so that is very wrong... 
You are reading it correctly - why is it very wrong?


No longer depends on: 53441
(Reporter)

Updated

16 years ago
Depends on: 63916

Comment 87

16 years ago
>Also, if image loading is turned OFF, then most web pages look like total crap
>unless we honor the sizes and thus keep the layout the same as if the image was
>there.
I retract this hyperbolic statement. Some web pages rely on the image sizing for
the layout, and thsoe look bad when we do not honor the dimensions for blocked
images.

No longer depends on: 63916
(Reporter)

Updated

16 years ago
Depends on: 87673
(Reporter)

Comment 88

16 years ago
Those web pages look like crap anyway without the images, whatever layout they
have. :-)

regarding cmanske's comments, I agree that in the editor we should show image
frames, it is good feedback for the user, and allows him to edit the page before
he has the images ready, etc. However that should IMHO be implemented as a mode
that the editor can cause layout to go into, and should not affect what we do in
the browser itself.

Comment 89

16 years ago
We have such a mode - it is called Quirks Mode :) That is where all of those
pages that look like crap play anyway!

Seriously, I think we may be getting closer to agreement. I am leaning toward
using Quirks Mode to indicate that we should honor width and height of broken /
blocked images for two reasons: 1) current standard practive among browsers 2)
the mode already exists and is used by Composer and Mail. What say ye?

Updated

16 years ago
Depends on: 63916
(Reporter)

Comment 90

16 years ago
Quirks mode won't always be used by Composer (hopefully). And while I won't block
changes to quirks mode, I am getting more and more concerned as to the number of
differences (especially undocumented differences) between standard mode and
quirks mode. I personally think we should be reducing the differences, not
increasing them. Especially since in this case I personally believe that the
pages look _worse_ with the suggested change, whatever mode we're in.

Comment 91

16 years ago
Ian, are you going to update your 'altspec' proposal document with the new
thinking on the source of the ALT text (no TITLE attribute)? Also, what is being
done to get this adopted by a standards body?
Target Milestone: mozilla0.9.7 → mozilla0.9.6
(Reporter)

Comment 92

16 years ago
I'll update it (at some point). I am not intending to get this adopted by any
standards bodies, just like there is not going to be any attempt at getting our
UI specs adopted: This is specific to Mozilla.

HTML is not a layout language. Getting different browsers to render things like
this differently encourages people to understand this. Similarly, getting
alternate text to be inline encourages authors to think of alt text as a textual
alternative instead of as a caption.

Updated

16 years ago
Blocks: 106958

Comment 93

16 years ago
Moving to Moz 1.0
Assignee: attinasi → attinasi_layout
Status: ASSIGNED → NEW
Target Milestone: mozilla0.9.6 → mozilla1.0

Updated

16 years ago
Status: NEW → ASSIGNED

Comment 94

16 years ago
I submitted Bug 109090 when I saw Blocked images pop-up as broken.  I don't see
it here, but I would like the option to use the previous behaviour for blocked
images, where there is a blank spot where the image should be, the size of the
image.  No Alt text, no icon (maybe even remove it as a link...).

This would facilitate the anti-ad users, and not show ads as alt text either.

Comment 95

16 years ago
I agree with William 100%. You do not block images from advertisement sites to
see white rectangles with an icon instead. You just want not to be bothered with
their existence at all. Therefore the blocked images should be borderless and
have a transparent background. Like they used to have until recently. At least
give us, the advertisement blockers, a pref to restore that behavior.

You cannot underestimate the power of advertisement blocking in Mozilla
advocacy. This was the #1 argument for some people I convinced into a browser
switch. I understand that mozilla.org and netscape.com may have different
priorities here. That's why a pref with (possibly) different defaults would be
very helpful.

 

Comment 96

16 years ago
The change of displaying a "broken image" instead of alt text was done in bug
102281.

Comment 97

16 years ago
The behavior of displaying a bordered box with a "broken image" link for blocked
images is so ugly that I'm reverting to Mozilla 0.9.4 (because I also want
cnn.com to work again.)

I agree with the comments that the behavior of rendering blocked images should
be user-selectable.  I'd personally choose to have blocked images collapse to
zero size and no alternate text.  I realize that this may affect the layout of
poorly-designed, overly graphical sites but it's more than worth it to me to get
to the content I want to see, instead of the ads.  I would like the browser to
behave as if the image tags were never in the source to begin with.

   Some people may want a place holder for blocked images (just the blank
transparent rectangle that we had before) so that some poorly-designed sites are
still usable in the face of strange layout.

  This behavior should be the same in standards mode or quirks mode.  (I regard
the development of "quirks" mode as an unfortunate choice that adversely affects
the forward progress of the web and harnesses us to poor past decisions, akin to
the millions of person-hours lost by such historical tragedies as the QWERTY
keyboard, non-phonetically spelled languages, the segment-offset architecture of
the Intel 8086 processor, and MS-DOS.)   

Comment 98

16 years ago
> This behavior should be the same in standards mode or quirks mode. 

Yes, of course. The *blocking* of images has nothing to do with *broken* images
and therefore should not be doctype related.

Comment 99

16 years ago
In the original checkin, I added a pref so you could get the old behavior if you
wanted it. I posted this information to the newsgroups and it is in the other
bugs as well. Here, for reference, is the newsgroup thread with the information
you need to set the pref and get the old inline alt text behavior:
news://news.mozilla.org:119/3BEB024F.3070508@domain.nul

Comment 100

16 years ago
It seems that this bug must be related to bug 102281 ?
Note that to keep bug 109410 from opening again, I want to note here that
participants have agreed that if we are going to do boxes for alt text, as we do
in quirks at this time, these boxes should resize to fit the alt text within
them, and not be limited to their original height and width.  This behavior is
similar to IE, and has been agreed upon as the best solution to making alt text
accessible when it is displayed within boxes.  Creating boxes with fixed width
and height has been referred to numerous times as explicitly buggy behavior in
WAI mailing lists.

Comment 102

16 years ago
>...participants have agreed that if we are going to do boxes for alt text, as we 
>do in quirks at this time, these boxes should resize to fit the alt text within
>them, and not be limited to their original height and width.  This behavior is
>similar to IE...

From my testing of IE the last part of this statement is false (IE6 windows
version 6.0.2600.000). If a width and height are specified and the image is not
available, then the box is the size specified and the alt text is clipped if it
does not fit - I'll attach a screen shot.

Comment 103

16 years ago
Created attachment 58114 [details]
Screenshot of IE 6 clipping alt text (support for comment #102)

Comment 104

16 years ago
> From my testing of IE the last part of this statement is false (IE6 windows
> version 6.0.2600.000). If a width and height are specified and the image is not
> available, then the box is the size specified and the alt text is clipped if it
> does not fit - I'll attach a screen shot.

If you go to Tools > Internet Options > Advanced > Accessibility and check
'Always expand ALT text for images' then the alt text isn't clipped. I guess IE
has a pref so you can choose between viewing full alt texts and preserving
layouts created with images.

Comment 105

16 years ago
>If you go to Tools > Internet Options > Advanced > Accessibility and check
>'Always expand ALT text for images' then the alt text isn't clipped. 

That only applies if you have 'Show Pictures' turned OFF, or so it seems. If the
image is missing but you are showing images, then the ALT text is still clipped
even with that pref set.

Comment 106

16 years ago
>>If you go to Tools > Internet Options > Advanced > Accessibility and check
>>'Always expand ALT text for images' then the alt text isn't clipped. 

> That only applies if you have 'Show Pictures' turned OFF, or so it seems. If the
> image is missing but you are showing images, then the ALT text is still clipped
> even with that pref set.

Yeah, it looks like you're right. From the 'What's This?' help for the checkbox:

"Specifies whether the image size should expand to fit all of the alternate text
when the Show Pictures check box is cleared."
(Reporter)

Comment 107

16 years ago
I have updated the spec.

   http://www.hixie.ch/specs/alttext

It now takes into account our behaviour in quirks mode and suggests that we add
a preference similar to IE's (actually just a front-end to the existing
browser.display.force_inline_alttext pref).

Updated

16 years ago
Keywords: mozilla1.0

Comment 108

16 years ago
Created attachment 62318 [details]
Solution for clipped ALT text while allowing TITLE usage

This is a demonstration of how the full ALT text can be displayed when it
exceeds the size of its placeholder.

Comment 109

16 years ago
Attachment 62318 [details] is an example of the behavior I was trying to describe in bug
109410. Do not confuse the expanded ALT text for a tooltip--it will only be
displayed when the ALT text is clipped and not when the image properly loads.
The TITLE is displayed as a tooltip. We might first expand the ALT text, then
display the TITLE in a tooltip. They should both be displayed at the same time,
despite the way it is rendered in the demo.

I still support honoring the author's height/width styles regardless of
quirks/standard mode and think this is a reasonable solution to make ALT text
readable but not intrusive.
*** Bug 117383 has been marked as a duplicate of this bug. ***
Keywords: access
Keywords: nsbeta1
(Reporter)

Updated

15 years ago
Whiteboard: [Hixie-P3] [Hixie-1.0] (py8ieh: reexamine test case) → [Hixie-P2] (py8ieh: reexamine test case)
Marking nsbeta1-. Just not enough time to implement this.
Keywords: nsbeta1, nsbeta2, nsbeta3 → nsbeta1-

Updated

15 years ago
Target Milestone: mozilla1.0 → mozilla1.1
With regards to the Alt text on blocked images:

maybe a distinction needs to be drawn between images blocked from a site and 
overall mozilla image blocking.

If a particular site is blocked, don't show its alt text or an icon.

If the user has blocked all images (probably a low bandwidth situation) show alt 
text.

I'll look at implementing this.
(Reporter)

Comment 113

15 years ago
mkaply: we have got a spec that does basically what you describe, see:
   http://www.hixie.ch/specs/alttext
...which is what this bug is about.
Attachment #10214 - Attachment is obsolete: true
Created attachment 70860 [details] [diff] [review]
Fix for problem

OK, I have attached a fix for this problem. My goal is to get something in for
Mozilla 1.0.

What this fix does display Alt text if the pref is set to block ALL images. If
it is not set, it does not display Alt text for blocked images.

I think this should satisfy both camps (low bandwith people and ad blocking
people)

I'm not worrying about an icon right now.

Comment 115

15 years ago
Comment on attachment 70860 [details] [diff] [review]
Fix for problem

I think you should initialize intPref, and add a comment about the significance
of the magic number '2' - other than that it looks good!  SR=attinasi
Attachment #70860 - Flags: superreview+

Comment 116

15 years ago
Comment on attachment 70860 [details] [diff] [review]
Fix for problem

please move intPref to right before its use. this is c++ :)
Attachment #70860 - Flags: review+
Michael: When you throw in icons, I think you should also add a corrupted image
icon that is different for corrupted. Also, please don't close out the bug until
the icons have been worked on. See below:


Should this be done for <object> tags too?

On Hixie's alttext spec:

http://www.hixie.ch/specs/alttext

"UAs may use a different list or different criteria depending on their
feature set (for example UAs may also have a 'corrupted image' icon)."

- We should definately have a corrupted (invalid) image icon that is different
from a broken image icon.

We should also, I believe (Feel free to beat me over the head if anything I say
is stupid): 

- Put the words "[blocked]", "[corrupted]", "[broken]" after the alt text so
people are sure exactly what the problem is if they don't know the icons.

- Alt text should be wrapped until it is cut off by the bottom of the image.

- Alt text should be as small as possible without making it unreadable to fit
more. Maybe an Arial size 8 or 9 equivalent.

- Alt text should be dark grey, imho, as not to be imposing. If its not dark
grey, then I feel it should be black.

- Please don't turn on the "hide icons" by default

Comment 118

15 years ago
if [broken] [corrupted] [blocked] are to be visible to users, I'd suggest that
the first two be disambiguated. Joe sixpack won't know the difference between a
broken image or a corrupted image. Perhaps [not found] would be better?

-matt
Matt: Good Point.

For images that have not been downloaded, we can put a percentage "[##%]"
For images that are known to be unavailable, "[Unavailable]"
For images that have been blocked, "[Blocked]"
For images that are in a format not supported by the UA, "[Unsupported]"
For invalid or corrupted images, "[Invalid]"

Should (if implemented) this be compatible with the show icon preference?

Other options are show this in the tooltip, or show this when hovering over the
icon - though that might be hard to find. Although, the percentage might be nice
to see as its downloading. Unfortunately, this wouldn't be of any use if the
images eventually will be incrementally shown on the web page.

For instance: 
[ICON] [75%] - ALT Text

Hixie: Should something about the above things I mentioned in my previous
comment be added to the spec? (Such as text size, color, wrapping, readability,
and possibly if people agree with it, the [Invalid], etc?


<offtopic>
To explain more about the <object>, <embed> (deprecated?) tag etc, I noticed
that the spec said it doesn't describe these tags. 

Should a spec be thrown together for those, also?
</offtopic>

Comment 120

15 years ago
I don't really see the point of these "[Unavailable]", "[Blocked]" etc.
captions. Shouldn't that all be conveyed by the icon?

Comment 121

15 years ago
- Put the words "[blocked]", "[corrupted]", "[broken]" after the alt text so
people are sure exactly what the problem is if they don't know the icons.

I think this will be too much info to insert in the web page. Showing it as a 
tooltip on the image icon, or in the image properties dialog, or even in the 
status bar on hover would be better, IMO. We're showcasing the page, mind, not 
the loading statistics.

- Alt text should be as small as possible without making it unreadable to fit
more. Maybe an Arial size 8 or 9 equivalent.

font-size: small. x-small if necessary, but no smaller. And this should only 
affect alt text inside a missing-image box, not text inserted inline.

- Alt text should be dark grey, imho, as not to be imposing. If its not dark
grey, then I feel it should be black.

Suppose the page has a gray/black background. Will I still be able to read the 
text?

Updated

15 years ago
Keywords: mozilla1.0+

Updated

15 years ago
Keywords: mozilla1.0

Comment 122

15 years ago
I do not think this is necessary for Mozilla 1.0, at least not all of it.  Which
part of the full proposal (http://www.hixie.ch/specs/alttext) do we implement
for Mozilla 1.0 anyway?  Really, this was intended to be a tracker / discussion
bug more than anything else.  Besides, resources are already stretched too think
for 1.0, just fixing crashers and dataloss bugs.

I think Mozilla1.0+ is a bad call here...
fantasai: You have a good point. We should use a color for the text that 
stands out against the background (which might be tough and a waste of time to 
determine if the background is an image). We could also use a shade of grey 
that stands out against the background.

Marc: In my opinion, showing the icons and the alt text in small wrapping, 
contrasting text would be good for mozilla 1.0 - but I assume its up to 
whoever is implementing it. The idea for showing the [BROKEN] text would 
definately be something for the future. I agree with fantasai that the image 
area would not be a good place for this. Probably the tooltip would be best. 
If there was no title defined it would just say Broken, otherwise it would say 
Broken - title text when you moused over.

http://mozilla.netdemonz.com/?section=bugs&subsection=bug41924

You might want to see how IE renders this page as a comparison.

Here is a sample page. Notice that the slow-loading images (I made them slow 
with a CGI) cause the page not to appear until they are fully loaded, yet if 
you right click on them to view just the image, it shows an incremental render.

For images that are loading on the page - if incremental loading on a web page 
is ever implmented, what do you think the best thing to do would be? In 
Hixie's spec, it talks about images not loaded, but wouldn't showing them 
incrementally be the best? Perhaps if they are not the type of images that are 
loaded incrementally then we could put a box around them, and an icon, etc.

Comment 124

15 years ago
Marc: Comment 109 is something that ought to be fixed soon.

Comment 125

15 years ago
Brian, your sample is in standard mode, so we always show the alt text as inline
text - we only draw the boxes and icons in quirks mode.  One thing I did notice
though is that we do not honor the foreground color when rendering the box
around the image in Quirks mode (for sized images).

As for Skewer's idea in comment #109 - I do not like it, certainly not at this time.

Please understand that we are trying to get Mozilla 1.0 done.  We have much more
serious issues than this, at least I do.  If somebody wants to take a crack at
getting the image box to color correctly I'd be happy to review it, but I have
enough crashers and hangers to look into for the next 5 weeks that I will nto be
able to get to this relatively minor issue - sorry.

Comment 126

15 years ago
Unfortunately, all this discussion of how to display alt text etc is distracting
from what is *not* a minor issue for Composer:
If user enters an image with a bad src url, we display absolutely nothing.
In 4.x we displayed a "broken image" icon. That's all we are asking for.
Isn't that issue a compatability regression?
This issues was originally bug 55046, which was dupped to this one.

Comment 127

15 years ago
Charley, what you want, I believe, is for broken images to have a width and
height suitable for at least the display of the icon.  This has to be done in
the reflow, in case there is text around the image (it needs to take up real
layout space, in other words).  I can see that this is important for Composer -
thanks for restating this.  I think we really should open a bug on that, for
composer only, and see if we can get it accepted for nsbeta1
Yeah, let's not morph this bug into a specific 1.0-targeted composer one.

I'm completely with Marc on the low priority of this bug as stated, in the 0.9.9
and 1.0 milestones.  The fgcolor glitch could be patched by someone other than
Marc, if the patch looks small and safe to all concerned, and if it's done soon.
 The rest of this is 1.1 fodder -- so this bug as a whole is well-targeted.  If
we don't get the fgcolor problem fixed, we will not hold 1.0 waiting for a
solution to that minor bug.

/be

Updated

15 years ago
Keywords: mozilla1.0+, nsenterprise → mozilla1.0-
OK, now I am just getting annoyed.

I put together an easy patch to help the situation, submitted to drivers long 
before 0.9.9 branched and noone is interested?

Why do so many people in Mozilla have the "fix it right even if it takes 6 
months" attitude, rather than the "do what we can now" attitude.

It sucks.
mkaply, I lost track of your r=/sr='d patch in all the to and fro -- sorry.  I'm
wondering why that patch wasn't landed once it had review.  Also, some feel
icons are needed.  If the patch makes things better, it should go in -- mail
drivers for approval for 0.9.9, there's still (plenty) of time.

/be
Marc: Is it standards-compliant that the ALT text is shown inline even on a
sized image that is unable to load or not fully loaded? What does the standards
say about ALT text and unloaded images?

Also, afaik - Mkaply wants to work on this, so some decisions need to be made so
he knows what to do to implement this fully. We aren't asking for this to be
implemented now - instead just information on what would be the best to do. 

---

Bug 114760 explains why its important to give info even if you aren't planning
on working on a bug. The reason is because others might need the info if they
want to work on it.

Comment 132

15 years ago
The height and width attributes give user agents an idea of the size of an image 
or object so that they MAY reserve space for it and continue rendering the 
document while waiting for the image data.
     -- http://www.w3.org/TR/html401/struct/objects.html#h-13.7

Several non-textual elements (IMG, AREA, APPLET, and INPUT) let authors specify 
alternate text to serve as content when the element cannot be rendered normally. 
Specifying alternate text assists users without graphic display terminals, users 
whose browsers don't support forms, visually impaired users, those who use 
speech synthesizers, ___those who have configured their graphical user agents 
not to display images, etc.___

     -- http://www.w3.org/TR/html401/struct/objects.html#adef-alt

Emphasis mine
http://www.kaply.com/work/blocked-image.gif

Valiant attempt at a blocked image icon.

I only have 16x14 pels to work with.

Other suggestion has been to just have the "not" symbol and don't bother to have 
what might be an image in the background since this symbol will be in an area 
where an image would be.

Comment 134

15 years ago
Comment on attachment 70860 [details] [diff] [review]
Fix for problem

a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #70860 - Flags: approval+

Comment 135

15 years ago
Created attachment 73437 [details]
Alternate blocked image icon
Created attachment 75342 [details]
Another possibility

Comment 137

15 years ago
mkaply, did this land yet? if so, can you obsolete the patch? if not, can you
check it in. time is running out.
I landed my original patch. I have not landed the blocked image icon.

Do we want to try to get the blocked image icon for 1.0 or is what we have good 
enoug?

*** Bug 137424 has been marked as a duplicate of this bug. ***
still discussing what to show if image not there?

should be this:
<img/>
if alt="" exists show that text, and only the text. no border, no "this iamge is
broken" info. If it doesn't exist only add an [image] string.

<input type="image"/>
try alt="" or value="" or just [button]

esp. that "broken image" icon only takes up space and so makes the alt="" worse
to be read... 
Personally, I like the broken image icon, and I believe it could be used to show
what's broken about the image. If you don't want it, then there should be a pref
for that.

Comment 142

15 years ago
I think that it has been suggested before, but I will make the suggestion again:
It seems to me that the best fix would be the inclusion and implementation of
the following set of preferences (not phrased like I have):

Display "broken image icon" for "broken" images:
( ) Yes [default]
( ) No

Display alternate text for "broken" images:
( ) Yes [default]
( ) No

Dimensions of "broken" images:
( ) Collapse as much as possible [depending on whether broken image icon and alt
text are to be displayed; and regardless of whether WIDTH and HEIGHT are given]
( ) Defer to WIDTH and HEIGHT if specified, but otherwise collapse as much as
possible [would be nice to make _this_ default, per allegedly fixed Bug 102281]

For my suggestions on blocked image prefs, see Bug 62046.
In general, I think it would be nice to keep everyone happy (whether to display
those icons, the alt text, maybe even how to formulate the alt text if we want
to go crazy).  I don't see where this interferes with standards.  Although  
"Authors are in any case advised to avoid using images to format pages..."
(http://www.w3.org/TR/html4/struct/objects.html#adef-alt), I don't see why this
should prevent us from intelligently reserving space in the layout for an
unavailable image if we are given dimensions.  It's what any other respectable
(or not so respectable) browser would do  :)  (and it seems intuitive to me)
Any comments?  Death threats?  Love letters?
David: I would set no icon, if there's no given width or height, as this
normally takes up much more space then the alt="" text itself.

another problem is, if you don't have enough space for alt="" text AND icon...

Comment 144

15 years ago
Simplified GUI:

Broken images:
 [ ] Display alternate text
 [ ] Display "broken image icon"
 Collapsing: 
  ( ) Collapse as much as possible 
  ( ) Respect specified dimensions 

Comment 145

15 years ago
I think the keywords "pref", "pref+" and "pref-" should be added to bugzilla.  

Bugzillians nominate a feature for a spot in a pref panel by adding the keyword
"pref" to the bug.  Then a "Pref. Panel Triage Team" evaluates its merits and
gives the bug a "pref+" or "pref-".  (This bug, like MOST others, should be
"pref-" IMVHO)

Am I serious?  You decide because I can't make up my mind!  All I know is that
something has to be done about this infection of pref-maddness that is spreading
uncontrolled throughout this project.   If this bug were solely about the
preferences then I would be advocating the addition of a "WTF", "WTF+" and
"WTF-" keywords!
Those prefs won't work - see 62046.

The issue is that there are cases where you want alt text for some 
blocked images and not for others.

That is how the code works now.

If you have blocked ALL images (what people do when they are using 
dialup) you get alt text.

If you have blocked images from a particular server (what people do 
when they are trying to block an ad server) you get no alt text.

We probably need to summarize what issues are left right now.

I believe the major one is adding a unique blocked image icon and 
adding a UI for the pref as to whether alt text is inlined or not.
(Reporter)

Comment 147

15 years ago
people suggesting prefs: we have already got a spec that has been discussed to
death and represents the behaviour we have agreed to implement:
   http://www.hixie.ch/specs/alttext
There is no need to further discuss what we want to do, only how to do it (and
what remains to be done -- some of the spec is already implemented).

Comment 148

15 years ago
I know that _you all_ have had a chance to discuss it, Ian, and I respect the 
work you put into your specification.  Do what you think is appropriate, I'm 
just telling it how I think it should be :)

Comment 149

15 years ago
------- Additional Comment #147 From Ian 'Hixie' Hickson 2002-05-10 11:01 -------

> people suggesting prefs: we have already got a spec that has been discussed to
> death and represents the behaviour we have agreed to implement:
>    http://www.hixie.ch/specs/alttext
> There is no need to further discuss what we want to do, only how to do it (and
> what remains to be done -- some of the spec is already implemented).

Exactly who is "we" in this situation? You seem to be implying that EVERY
contributor to Mozilla has agreed that your specification is holy and perfect.

Comment 150

15 years ago
Continuing my opinion from the last post, even if this has somehow been "agreed
upon" by people who are "in charge" of Mozilla, it still appears to me that this
specification has a brash disregard for the principles of the CSS
recommendation. It encourages a pattern of user-agent behavior designed to
deliberately ignore an author's height/width styles and create a flowing mess
out of what would otherwise be a well formatted page. It calls following the
specification in these instances "legacy behaviour" and a "quirk." I fail to see
any justification for these radical propositions. It bothers me that such a
specification was accepted, as you say, without more consideration for its
implications to the browser's compatibility and usability.

These issues were in my bugs that got duped to this, and remain unaddressed.
Ian, can you explain your hostility towards the concept of author-controlled
height and width, even in the event of broken images? (Don't forget that I have
offered an adequate way to render ALT text that exceeds the size of the
placeholder, in comment 108).

Comment 151

15 years ago
I think some people are a little confused about exactly what the current spec says.
From the User Agent Accesability Guidlines:
Sec 2.3 (P1) - Example Technique #4  For an object (e.g., an image) with an
author-specified geometry that the user agent does not render, allow the user to
configure how the conditional content should be rendered. For example, within
the specified geometry, by ignoring the specified geometry altogether, etc. 

As I read the spec, this is provided for. When a user has the "Always expand
alternate text" option *unchecked* it will create a box the size of the image
and fill it with the alt text. The problem I see is that this only applies to
so-called "legacy" documents. This may eventually become a problem because some
pages may qualify as "standards compliant" in mozilla, and still rely on the
sized boxes of broken/blocked images to look correct.

HTML Standards compliant != Accessibility Standards Compliant (no matter how
much we wish it did.)

we may wish to expand the pref to three-way to read 
Expand alternate text: [ Always             |V]
                       | On Compliant Pages |
                       | Never              |
                       ----------------------

Personally, I don't think its that big of a deal... the current spec will
satisfy  almost everybody. And most pages render in "Quirks" mode anyway, so it
won't really matter. And if you really really want your broken images to take up
a specified width/height, I believe you can just specify a min/max width/height
in CSS and then mozilla won't override it. (I think)
(Reporter)

Comment 152

15 years ago
We = the CSS module owner, CSS module peers, and CSS module QA.

The spec is exactly within the CSS spec. If the <img> element has 'display:
block' then it should be a block and honour width and height regardless of
whether it is replaced or not, and if it has 'display: inline' then it should
only honour width and height if the element is a replaced element (i.e. if the
image is there).

I apologise if you think Mozilla is in some way a pure democracy, it's not.
(This should not be news to anyone -- mozilla.org has been very clear that the
module owner gets the final word.) While your comments are indeed welcome, the
result of hundreds of conflicting opinions on one bug is merely confusion and
lots of bugmail spam.

If you wish to discuss the spec, I encourage you to e-mail me directly, where I
will quite happily discuss the pros and cons of your suggestions in detail.
Should your suggestions be better than the current agreed spec, I am quite ready
to change the spec -- it has gone through many revisions over the last 3 years.

My e-mail address is: ian@hixie.ch
The current Mozilla spec for this bug is at: http://www.hixie.ch/specs/alttext
The FAQ that I would recommend you read is: http://www.hixie.ch/advocacy/alttext

Comment 153

15 years ago
I'd like to discuss this a bit here, since this bug seems to serve no other
purpose, posting here allows other contributors to help decide the best COA, and
I don't expect to accomplish much by e-mailing you. I encourage you not to be
evasive of my questions, even if doing so doesn't make you any less likely to
get your way with the Mozilla project. By avoiding the subject you're doing a
disservice to all the Mozilla, Netscape, and AOL users that will be stuck with
this functionality.

In your FAQ, argument #5, your logic doesn't seem to solve the argument. This
argument is one of my main beliefs, and basically Mozilla punishes users for
designing pages to the standards. It still seems very easy for a user to be
confused by the effect of ALT text washing into the document with the text. The
user is still perfectly able to get the information he wants by reading the ALT
text inside the placeholder frame. And you say images are content, but you don't
say what kind; very often they are supplemental content. On a software homepage
you might see a screenshot of the software alongside a paragraph describing its
features. A page showing all of a band's soundtracks might put a picture of the
CD cover next to a table of the album name and track list. The news might show a
picture of the MVP-of-the-moment hitting a homer in the middle of the sports
page. Images aren't usually meant to be read in sequence the way they appear in
the document's markup, they're meant to sort of lay in the user's peripheral
vision while he reads through the paragraph that is (should be) intact and whole
on its own. Now, you'll just tell me this is the way a voice-operated browser
works, but that's just irrelevant. Voice-operated browsers that behave that way,
in my opinion, need improvement--they should not read the ALT text aloud in most
cases. Just because you might be able to find me such a browser that stirs the
ALT text for images into a jumble with the paragraphs they sit with, doesn't
mean there's any good reason for Mozilla to do it. Bear in mind, also, that
putting the ALT text for an image into a placeholder isn't a style or layout
issue, so much as it is a meaning issue; images, as I said, are not designed to
blend in with the text in most cases (some authors might feel like using an
image for a symbal, a word, a letter, or some strange rebus effect). ALT text
should always be set in a box, aside, to keep it out of the way of the textual
("real") content. Why obey height/width styles? Why not? It's worked in the
past, it would make large or small images take up only the real estate they
would if the image loaded, it would preserve layout, and other stuff that you
generally don't like. You could use those same arguments against using the
height/width styles, but since images should be drawn in a box anyway, it makes
sense to retain those styles (and not doing so would mean we can't use the
system we already have for quirks).
(Reporter)

Comment 154

15 years ago
> I'd like to discuss this a bit here, since this bug seems to serve
> no other purpose,

This bug serves the purpose of discussing the code aspects of fixing
the issue. It's not a nowsgroup. Spamming this bug _will_ annoy the
people on the CC list.

I therefore apologise to all CCs for this 237 line comment. May the
record show that I did ask for this to be discussed in private e-mail.


> posting here allows other contributors to help decide the best
> course of action, and I don't expect to accomplish much by e-mailing
> you.

Why would you expect to be able to change my mind while irritating the
people who plan to implement this, but not while e-mailing me
directly? I don't see how the forum you pick is going to change the
strength of your points.


> I encourage you not to be evasive of my questions

If I find any, I will do my best to answer them directly.


> even if doing so doesn't make you any less likely to get your way
> with the Mozilla project.

I assume you meant the opposite. I would be lying if I said I was
totally objective here. After having spent 2 or more years defending
one position you get attached to it. However, I believe I can put
aside my subjectivity and argue this logically. Can you?


> In your FAQ, argument #5, your logic doesn't seem to solve the
> argument. This argument is one of my main beliefs, and basically
> Mozilla punishes users for designing pages to the standards.

To make sure we are talking about the same thing, let me just make
sure I understand this "main belief" of yours.

You believe that the height and width of an image is an integral part
of its semantic identity.

Is that correct?

Let's make sure we agree on the meaning of "semantic identity": I
interpet that phrase to mean "meaning conveyed to the reader".

Do you agree with this definition?

If so, disproving this point is easy. Take the following images:

   http://www.hixie.ch/resources/images/astrophy/200
   http://www.hixie.ch/resources/images/astrophy/128

They have *exactly* the same semantic identity, yet differ in size.


Further, you believe that a box whose size is defined by the height
and width attributes of the image provides a cue that the entire
content of the Web page is not at present available.

Is that correct?

If so, then an alternative cue, such as an icon in the flow of text,
next to the inline alternate text, as proposed in the spec, would be
an equally good cue, and thus your need is satisfied either way.


> It still seems very easy for a user to be confused by the effect of
> ALT text washing into the document with the text.

Please explain what there is to be confused about.


> The user is still perfectly able to get the information he wants by
> reading the ALT text inside the placeholder frame.

I refer you to the following part of the answer to argument #3:

   I would suggest that the best rendering is:

      The house is white, with green shutters on the windows. The house
      is in the middle of...

   ...and not the following:

      +---------------------------------+
      | The house is white, with green  |
      | shutters on the windows.        |
      |                                 |
      |                                 |
      |                                 |
      +---------------------------------+ The house is in the
      middle of...

I definitely know which the _user_ would find easiest to read.


> And you say images are content, but you don't say what kind;

At no point in that document do I describe images as content. I imply
that some images form a part of the page's content, but I don't think
anyone would argue with that.


> very often they are supplemental content. On a software homepage you
> might see a screenshot of the software alongside a paragraph
> describing its features.

This would be either a decorative image (alt="", the user isn't
missing any content if he has images disabled), or could be trying to
convey the UI of the application (descriptive alt="", with possibly an
even longer longdesc="").

In the first case, the space the image would have taken up is
irrelevant, and leaving it blank would merely take room away from the
page's real content.

In the second case, the space the image would have taken up is
meaningless, and trying to fit the text into the box would make little
to no sense. The box should adapt to fit the text (if it is floating)
or flow like a paragraph (if it is not) and that is exactly what the
spec suggests.


> A page showing all of a band's soundtracks might put a picture of
> the CD cover next to a table of the album name and track list.

Similarly, this is either decorative, in which case the user isn't
missing anything, or is trying to convey some additional information
about the CD, in which case useful alternate text would be appropriate
and the size of the image would not be important.


> The news might show a picture of the MVP-of-the-moment hitting a
> homer in the middle of the sports page.

Same again.


> Images aren't usually meant to be read in sequence the way they
> appear in the document's markup, they're meant to sort of lay in the
> user's peripheral vision while he reads through the paragraph that
> is (should be) intact and whole on its own.

But the case we're discussing is specifically that where the image is
not available, so what happons when the image *is* there really is not
important. Text, unlike images, _is_ meant to be read in sequence.


> [voice-operated browser]

I'll skip this part of your comments since we are not developing a
voice browser. (However, that doesn't mean I agree.)


> Just because you might be able to find me such a browser that stirs
> the ALT text for images into a jumble with the paragraphs they sit
> with, doesn't mean there's any good reason for Mozilla to do it.

No, you're absolutely right. Thankfully, that isn't the reason why I
am arguing this case.

And just because you might be able to find me a browser that places
the ALT text for images into a box the size the image would have been,
doesn't mean there's any good reason for Mozilla to do it.


> Bear in mind, also, that putting the ALT text for an image into a
> placeholder isn't a style or layout issue, so much as it is a
> meaning issue;

I think it's both, actually. And for both, I argue that alternate text
should not be placed into placeholders.


> images, as I said, are not designed to blend in with the text in
> most cases

See my comment above. We're specifically talking about when the image
is absent, not when the image is present.


> (some authors might feel like using an image for a symbol, a word, a
> letter, or some strange rebus effect).

And those cases are more than ever good reasons for using inline
alternate text. Take this example:

   <p>Hello <img alt="w" src="w.mng" height="64" width="128">orld!</p>

Which of the following would be the best rendering if images were
disabled?

   Hello World

...or:

         +------+
         |      |
   Hello |W     |orld
         +------+

Which do you think the user would find most readable?


> ALT text should always be set in a box, aside, to keep it out of the
> way of the textual ("real") content.

Why?


> It's worked in the past

No it hasn't. It's been broken for years. This is why we are finally
fixing it here.


> it would make large or small images take up only the real estate
> they would if the image loaded

Which is pointless, since the space is only relevant if the image _is_
loaded, as I have once again explained above.


> it would preserve layout

It would, but you have not given a single reason why this is a good
behaviour to have.


> and other stuff that you generally don't like.

Such as?

Comment 155

15 years ago
Okay, let's see if I understand what you are saying. You're saying that authors
should actually never be using ALT text unless they intend for it to flow into
the paragraphs the way Mozilla does? And anyone that actually does so deserves
to have their page bastardized in this way? So now it looks like you want to
punish authors who design pages to the standards and use ALT text.

Besides that, height/width isn't as important as setting ALT text in its own
box. As long as we do that, we've accomplished something. The best reason to
keep the height/width values is to keep from breaking apart tables set to a
certain pixel-width, a practice you may not approve of but which should not be
ruined every time an image is broken.

By the way, your examples are severely flawed. Nobody is going to make an ALT
text fit in so well with their paragraph, like you did in this example:

      The house is white, with green shutters on the windows. The house
      is in the middle of...

That that method of rendering would be acceptable. A more realistic example
would be this:

<IMG SRC="clouds.gif" ALT="Clouds"> Today's weather: Cloudy with a chance of
rain, high in the 60's.

I dare you to find appropriate ALT text for that image that wouldn't look as
dumb as this:

      Clouds Today's weather: Cloudy...

This is another example of what would NOT be realistic:

      Fluffy clouds adorn the report of Today's weather: Cloudy...

And yes, it would be better if the letter-as-an-image example were inlined, but
the placeholder isn't much worse, and we can't know which images are letters and
which really belong in placeholders. The few times it's better to inline the
text aren't worth it.
(Reporter)

Comment 156

15 years ago
First, an observation... You wrote:

> I encourage you not to be evasive of my questions,

...and then prompty ignored mine.


> You're saying that authors should actually never be using ALT text
> unless they intend for it to flow into the paragraphs the way
> Mozilla does?

Not necessarily. I'm saying that authors should use for the alt
attribute text that actually is alternate text, instead of titles,
descriptions, or other inappropriate text.


> And anyone that actually does so deserves to have their page
> bastardized in this way?

I assume you mean someone who uses inappropriate values for their alt
attributes? It isn't an issue of such authors "deserving" that their
pages be rendered differently from their (misguided) expectations,
it's simply that their pages are not standards compliant.

You'll note that we also "bastardise" pages that use incorrect CSS --
it's all part of our correct handling of standards.

Pages that are not authored in line with the standards but that are
instead targetted at legacy browsers should be triggering our quirks
mode (through the use of older DOCTYPEs, for instance) and thus will
not run into this issue. As we have already gone out of our way to
provide a solution to this issue, we should be free to do the right
thing when in standard mode.


> So now it looks like you want to punish authors who design pages to
> the standards and use ALT text.

Correct alternate text look fine when rendered as per CSS. It's only
inappropriate text that arguably looks better when shielded from the
rest of the content.


> Besides that, height/width isn't as important as setting ALT text in
> its own box.

I completely fail to understand why. Could you explain that?

Why does text that conveys the meaning of an image have to be in a
box? What purpose does the box have?

I can see plenty of reasons to *avoid* the use of a box, for example
it detracts from the content of the page, it breaks the layout of well
designed pages, and so forth.


> The best reason to keep the height/width values is to keep from
> breaking apart tables set to a certain pixel-width, a practice you
> may not approve of but which should not be ruined every time an
> image is broken.

Using HTML tables and HTML images for layout is a very deprecated
practice and belongs firmly in the land of quirks mode documents. We
should be doing everything in our power to discourage the use of such
practices in standard mode.

(Encouraging instead the use of decorative images and tables in CSS,
which do not have any of the accessibility problems associated with
the old layout-in-HTML practices.)


> By the way, your examples are severely flawed. Nobody is going to
> make an ALT text fit in so well with their paragraph

Not while browsers continue to incorrectly handle alternate text, you
are right about that. That's what we're trying to change here.

(If we weren't trying to make the world better, we might as well pack
up and go home, leaving IE to do the honours.)


> <IMG SRC="clouds.gif" ALT="Clouds"> Today's weather: Cloudy with a chance of
> rain, high in the 60's.

That would be an abuse of the alt attribute. The image doesn't convey
the same meaning as the word "clouds". In this case, the meaning of
the image is purely decorative, and so the correct alternate text
would be alt="".


> I dare you to find appropriate ALT text for that image that wouldn't look as
> dumb as this:
> 
>       Clouds Today's weather: Cloudy...

Easy. The empty string.

   Today's weather: Cloudy with a chance of rain, high in the 60's.


> This is another example of what would NOT be realistic:
> 
>       Fluffy clouds adorn the report of Today's weather: Cloudy...

Exactly -- *adorn* is the critical word here. That image is purely an
ornament to the page, and does not convey any additional meaning
itself. Thus, it's alternate text is nothing.


> And yes, it would be better if the letter-as-an-image example were inlined

Horrah, we are making progress!


> but the placeholder isn't much worse

If it is worse at all, then we are not doing our job.


> and we can't know which images are letters and which really belong
> in placeholders.

(Assuming you mean "which alternate texts..." and not "which images")
Sure we can. None of them belong in placeholders.


> The few times it's better to inline the text aren't worth it.

You have yet to give me a valid case where a placeholder would be
better, so I would say it _is_ worth it.

Comment 157

15 years ago
See also bug 136382, pref to hide placeholders while loading images.

Comment 158

15 years ago
> ...and then prompty ignored mine.

Since you're the one who's got control over Mozilla's handling of ALT text, it's
not up to me to answer every question. If I avoid questions (mostly because they
make no sense) it could only be assumed to harm me. I mostly avoid questions
that go down "Why did you murder your wife?" street (where there is no right
answer because it's a wrong question).

> Not necessarily. I'm saying that authors should use for the alt
> attribute text that actually is alternate text, instead of titles,
> descriptions, or other inappropriate text.

> It isn't an issue of such authors "deserving" that their
> pages be rendered differently from their (misguided) expectations,
> it's simply that their pages are not standards compliant.

What standard are you talking about? Your little alttext thingy is *not* a
standard, so don't even bring that up. The HTML and Accessibility Guidelines
standards have little to say about proper ALT text. What you call a standard is
mostly your own personal opinion about ALT text. This is what the HTML 4.01 spec
says:

While alternate text may be very helpful, it must be handled with care. Authors
should observe the following guidelines:

    * Do 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 (""). Authors are in
    any case advised to avoid using images to format pages; style sheets should
    be used instead.

This means my "cloud" example might not have been the best one, but let's say a
site relied on images to show the weather and didn't have any text.

  This week's weather: <IMG SRC="tue.gif" ALT="Tuesday"><IMG SRC="cloudy.gif"
  ALT="Cloudy"><IMG SRC="wed.gif" ALT="Wednesday"><IMG SRC="sunny.gif"
  ALT="Sunny">

This violates no standard. These images are not decorative, they are necessary.
Yet, this would be rendered by Mozilla similar to this in standards mode:

  This week's weather: TuesdayCloudyWednesdaySunny

IE would draw it this way:

                       +------------++-----------++--------------++----------+
  This week's weather: |[x] Tuesday ||[x] Cloudy ||[x] Wednesday ||[x] Sunny |
                       +------------++-----------++--------------++----------+

>> Besides that, height/width isn't as important as setting ALT text in
>> its own box.

> I completely fail to understand why. Could you explain that?

> Why does text that conveys the meaning of an image have to be in a
> box? What purpose does the box have?

It keeps the image information out of the document's paragraphs and body text.
Images do NOT mix in with the paragraph! They should never do this, except for
the special cases I mentioned.

> I can see plenty of reasons to *avoid* the use of a box, for example
> it detracts from the content of the page, it breaks the layout of well
> designed pages, and so forth.

Silly you. HTML isn't about page layout.

And whether it detracts from anything is a matter of opinion. It's obviously
better to detract a little than mess up a page.

> Using HTML tables and HTML images for layout is a very deprecated
> practice and belongs firmly in the land of quirks mode documents. We
> should be doing everything in our power to discourage the use of such
> practices in standard mode.

True, but the alternative is to pick our own size for the box and ignore the
styled height/width. It's better to go with the standard than be arbitrary.

>> By the way, your examples are severely flawed. Nobody is going to
>> make an ALT text fit in so well with their paragraph

> Not while browsers continue to incorrectly handle alternate text, you
> are right about that. That's what we're trying to change here.
>(If we weren't trying to make the world better, we might as well pack
>up and go home, leaving IE to do the honours.)

Your argument is that doing things the wrong way and making a mess of everything
will ultimately make authors adapt and do things the way you want. Since
Mozilla's use is so much lower than Netscape 4.x and IE, most authors won't
change anything. (Notice how many sites STILL totally block Netscape 6.) When
these little messes add up to a bad user experience, Mozilla's use will get
lower and lower. The end result is nobody left using Mozilla and authors still
doing the same thing they always did. It would be different if you had a
standard (again, some little text file Ian Hickson drew up is NOT a standard) to
back yourself up, but you just don't. As far as the average web designer is
concerned, the expectation is that ALT text will not wash into the paragraph.

>If it is worse at all, then we are not doing our job.

Don't make me dig up all the WONTFIXed bugs because the developers didn't feel
like a bug was worth fixing because they wanted to save time. (One example is a
bug for insert key -> overwrite which was WONTFIXed on sight, even though not
implementing that is much worse.) And being worse in special cases, and better
in most cases, ultimately is better.

Comment 159

15 years ago
>   This week's weather: <IMG SRC="tue.gif" ALT="Tuesday"><IMG SRC="cloudy.gif"
>   ALT="Cloudy"><IMG SRC="wed.gif" ALT="Wednesday"><IMG SRC="sunny.gif"
>   ALT="Sunny">
> 
> This violates no standard. These images are not decorative, they are necessary.
> Yet, this would be rendered by Mozilla similar to this in standards mode:
> 
>   This week's weather: TuesdayCloudyWednesdaySunny

Just use this:

   This week's weather: <IMG SRC="tue.gif" ALT="Tuesday:"> <IMG SRC="cloudy.gif"
   ALT="Cloudy."> <IMG SRC="wed.gif" ALT="Wednesday:"> <IMG SRC="sunny.gif"
   ALT="Sunny.">
(Reporter)

Comment 160

15 years ago
> Since you're the one who's got control over Mozilla's handling of
> ALT text, it's not up to me to answer every question.

If you want to convince me, then ignoring my questions is not a good
way to go about it. I have no obligation to listen to you.


>> It isn't an issue of such authors "deserving" that their pages be
>> rendered differently from their (misguided) expectations, it's
>> simply that their pages are not standards compliant.
> 
> What standard are you talking about?

HTML4, specifically the bit you quoted:

# While alternate text may be very helpful, it must be handled with
# care. Authors should observe the following guidelines:
#
#   * Do 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 (""). Authors are in any case advised to
#     avoid using images to format pages; style sheets should be used
#     instead.
  -- http://www.w3.org/TR/html4/struct/objects.html#h-13.8

The WCAG also cover this issue. From the definitions:

# Content is "equivalent" to other content when both fulfill
# essentially the same function or purpose upon presentation to the
# user. [...] Note that equivalent information focuses on fulfilling
# the same function.
 -- http://www.w3.org/TR/WCAG10-TECHS/#def-equivalent

From the CORE techniques:

# When a text equivalent is presented to the user, it fulfills
# essentially the same function (to the extent possible) as the
# original content. For simple content, a text equivalent may need
# only describe the function or purpose of content. For complex
# content (charts, graphs, etc.), the text equivalent may be longer
# and include descriptive information.
#
# Quicktest! A good test to determine if a text equivalent is useful
# is to imagine reading the document aloud over the telephone. What
# would you say upon encountering this image to make the page
# comprehensible to the listener?"
  -- http://www.w3.org/TR/WCAG10-CORE-TECHS/#text-equivalent

From the HTML techniques (note the colons in the alt attribute):

# |  <DL>
# |   <DD><IMG src="red.gif" alt="New:">Roth IRA</DD>
# |   <DD><IMG src="yellow.gif" alt="Old:">401(k)</DD>
# |  </DL>
  -- http://www.w3.org/TR/WCAG10-HTML-TECHS/#list-images

# When an image is used as the content of a link, specify a text
# equivalent for the image.
# 
# | Example.
# | 
# |  <A href="routes.html">
# |     <IMG src="topo.html" 
# |          alt="Current routes at Boulders Climbing Gym">
# |  </A>
  -- http://www.w3.org/TR/WCAG10-HTML-TECHS/#link-text-images

The UAAG guidelines also speak of this:

# 2.3 Render conditional content (P1)
#
# [...] If [the piece of unrendered conditional content] C is a
# summary, title, alternative, description, or expansion of another
# piece of content D, provide access through at least one of the
# following mechanisms:
#     o (1a) render C in place of D; [...]
#
# Note: For instance, an HTML user agent might [...] allow
# configuration so that the value of the "alt" attribute is rendered
# in place of all IMG elements (while other conditional content might
# be made available through another mechanism).
  -- http://www.w3.org/TR/UAAG10-TECHS/guidelines.html#tech-conditional-content


> The HTML and Accessibility Guidelines standards have little to say
> about proper ALT text.

See above.


> let's say a site relied on images to show the weather and didn't
> have any text.
> 
>   This week's weather: <IMG SRC="tue.gif" ALT="Tuesday"><IMG SRC="cloudy.gif"
>   ALT="Cloudy"><IMG SRC="wed.gif" ALT="Wednesday"><IMG SRC="sunny.gif"
>   ALT="Sunny">
> 
> This violates no standard.

It's certainly better than what your cloud example. However, as Jonas
pointed out, it is not the best alternate text you could have picked.
Use of punctuation, as suggested in the WCAG guidelines, improves
matters, making the page more readable.


> Yet, this would be rendered by Mozilla similar to this in standards mode:
> 
>   This week's weather: TuesdayCloudyWednesdaySunny
> 
> IE would draw it this way:
> 
>                        +------------++-----------++--------------++----------+
>   This week's weather: |[x] Tuesday ||[x] Cloudy ||[x] Wednesday ||[x] Sunny |
>                        +------------++-----------++--------------++----------+

Now if you correct the markup, e.g.:

   <p>
    This week's weather:
    <img src="tue.gif" alt="Tuesday:">
    <img src="cloudy.gif" alt="Cloudy.">
    <img src="wed.gif" alt="Wednesday:">
    <img src="sunny.gif" alt="Sunny.">
   </p>

...then you get:

   This week's weather: Tuesday: Cloudy. Wednesday: Sunny.

...or, if you have the little icons enabled:

   This week's weather: [@] Tuesday: [@] Cloudy. [@] Wednesday: [@] Sunny.


>> Why does text that conveys the meaning of an image have to be in a
>> box? What purpose does the box have?
> 
> It keeps the image information out of the document's paragraphs and
> body text. Images do NOT mix in with the paragraph! They should
> never do this, except for the special cases I mentioned.

But you have not given a _reason_ why this is good. You have told us
what it does ("It keeps the image information out of the document's
paragraphs and body text."), you have asserted an irrelevant and
actually incorrect statement regarding the behaviour of images in a
similar situation ("Images do NOT mix in with the paragraph!") and
then you have repeated your opinion without a logical backing ("They
should never do this, except for the special cases I mentioned.").

Can you give us a reason _why_ text that conveys the meaning of an
image has to be in a box? What purpose the box has?


>> I can see plenty of reasons to *avoid* the use of a box, for
>> example it detracts from the content of the page, it breaks the
>> layout of well designed pages, and so forth.
> 
> Silly you. HTML isn't about page layout.

Indeed, HTML has nothing to do with page layout. That's why I didn't
mention HTML when I mentioned layout. I'll reiterate, more explicitly:

I can see plenty of reasons to *avoid* the use of a box to hold the
alternate text, for example it detracts from the content of the page,
it breaks the layout described using CSS, and so forth.


> And whether it detracts from anything is a matter of opinion. It's
> obviously better to detract a little than mess up a page.

But a well designed page would not mess up. If it does that means it
has poor accessibility, would be hard to read for anyone using Lynx,
screen readers or voice browsers, and will be poorly indexed by search
engines, and would be violating the guidelines I mentioned above.

 
>> Using HTML tables and HTML images for layout is a very deprecated
>> practice and belongs firmly in the land of quirks mode documents. We
>> should be doing everything in our power to discourage the use of such
>> practices in standard mode.
> 
> True, but the alternative is to pick our own size for the box and
> ignore the styled height/width.

Eh? The alternative to what? The alternative to using HTML tables and
HTML images for layout is to use CSS tables and CSS images for layout.
That has nothing to do with picking your own size for the box.


> It's better to go with the standard than be arbitrary.

Totally. The standards (CSS and HTML, as well as the accessibility
guidelines for authors and user agents) support my position.


> Your argument is that doing things the wrong way and making a mess
> of everything will ultimately make authors adapt and do things the
> way you want.

No, my argument is that doing things the right way will convince
Microsoft to change their browser to start doing things the right way,
just as they have done with their CSS standards compliance in IE6.


>> If it is worse at all, then we are not doing our job.
> 
> Don't make me dig up all the WONTFIXed bugs because the developers
> didn't feel like a bug was worth fixing because they wanted to save
> time.

Actually, please do. I am not aware of any bugs that have been
WONTFIXed without good reason (lack of time is not a good reason).

This bug is not an appropriate forum, but if you e-mail me the list of
bugs you are talking about, I will ensure the issues are not ignored.
(Reporter)

Comment 161

15 years ago
*** Bug 62046 has been marked as a duplicate of this bug. ***

Comment 162

15 years ago
reassign to low-priority address: what a lot of noise lately.
Assignee: attinasi_layout → attinasi
Status: ASSIGNED → NEW

Comment 163

15 years ago
Standards: This is the only one you posted that even remotely suggests to
authors that they should punctuate their ALT text:

> From the HTML techniques (note the colons in the alt attribute):
# |  <DL>
# |   <DD><IMG src="red.gif" alt="New:">Roth IRA</DD>
# |   <DD><IMG src="yellow.gif" alt="Old:">401(k)</DD>
# |  </DL>
  -- http://www.w3.org/TR/WCAG10-HTML-TECHS/#list-images

I barely think an insignificant bit like that is enough to create a standard for
web designers to punctuate their ALT texts like this. Note that this sample
code, taken from the HTML 4.01 specification, doesn't punctuate the ALT text:

  <MAP name="map1">
   <AREA href="guide.html" 
          alt="Access Guide" 
          shape="rect" 
          coords="0,0,118,28">
   <AREA href="search.html" 
          alt="Search" 
          shape="rect" 
          coords="184,0,276,28">
   <AREA href="shortcut.html" 
          alt="Go" 
          shape="circle"
          coords="184,200,60">
   <AREA href="top10.html" 
          alt="Top Ten" 
          shape="poly" 
          coords="276,0,276,28,100,200,50,50,276,0">
  </MAP>

Since it's not clearly stated anywhere whether or not ALT text should be
punctuated, typical webmasters would follow this example, along with the code on
most websites out there, and not punctuate anything. The expectation, as I've
said, is that the image's replacement will *somehow* be separated from the body
text. If everyone used ALT text the way you want them to, the way Mozilla
handles it would work fine for everyone. However, this just is not backed by
standards -- the punctuation issue is a large one, since without punctuation the
document runs together even worse than it does in your examples where everything
is punctuated.

> Use of punctuation, as suggested in the WCAG guidelines

Where, exactly? It might have been used in an example but it's a stretch to say
it was ever exaggerated. And WCAG are guidelines, while HTML 4.01 is an actual
specification. I would be much more inclined to accept this behavior if
punctuation was mentioned there.

> improves matters, making the page more readable.


> Now if you correct the markup, e.g.:

   <p>
    This week's weather:
    <img src="tue.gif" alt="Tuesday:">
    <img src="cloudy.gif" alt="Cloudy.">
    <img src="wed.gif" alt="Wednesday:">
    <img src="sunny.gif" alt="Sunny.">
   </p>

> ...then you get:

>   This week's weather: Tuesday: Cloudy. Wednesday: Sunny.

Note that doing it that way puts ugly whitespace between the images, an effect I
usually try very hard to avoid (it could be accomplished with CSS, sure, but as
a rule of thumb a line break means a space character). In order to get that
effect, I would have to put trailing whitespace IN the ALT text.

>> Why does text that conveys the meaning of an image have to be in a
>> box? What purpose does the box have?
> 
> It keeps the image information out of the document's paragraphs and
> body text. Images do NOT mix in with the paragraph! They should
> never do this, except for the special cases I mentioned.

> But you have not given a _reason_ why this is good. You have told us
> what it does ("It keeps the image information out of the document's
> paragraphs and body text."), you have asserted an irrelevant and
> actually incorrect statement regarding the behaviour of images in a
> similar situation ("Images do NOT mix in with the paragraph!") and
> then you have repeated your opinion without a logical backing ("They
> should never do this, except for the special cases I mentioned.").

> Can you give us a reason _why_ text that conveys the meaning of an
> image has to be in a box? What purpose the box has?

The "box," which could really be an invisible container for the text, would set
the text aside the way the image would be set aside. Think of it as the
difference between having an image in the background or setting it apart from
the text, like this:


==== +-----+
==== | IMG |
==== +-----+
====
===========
===========

Having the image on the side keeps it separate and out of the flow of text. Note
that an image's location in the document code does not imply that it belongs in
that location in the flow of text; theoretically I could have the image anywhere
with CSS positioning. For example, you can choose between...
                                                   
 The toy market is giving in to merchandising. This blah blah blah blah blah.
Blah blah blah blah blah. Toys are looking more and more like our favorite
icons from children's movies, particularly Disney-of-the-moment.

 The movies are a prominent place to start new     +-------------------+
merchandising blah blah blah blah blah blah.       |[x] Spider-man toy.|
                                                   +-------------------+

-or...

 The toy market is giving in to merchandising. This blah blah blah blah blah.
Blah blah blah blah blah. Toys are looking more and more like our favorite
icons from children's movies, particularly Disney-of-the-moment.

 Spider-man toy. The movies are a prominent place to start new merchandising
blah blah blah blah blah blah.


Try and pretend that's not purely a decorative image, because I know there are
situations like this where it won't be. It's really hard to believe anyone
wouldn't find that awkward, even with punctuation and spacing.

> But a well designed page would not mess up. If it does that means it
> has poor accessibility, would be hard to read for anyone using Lynx,
> screen readers or voice browsers, and will be poorly indexed by search
> engines, and would be violating the guidelines I mentioned above.

Voice browsers, which I just told you are irrelevant, should know well enough to
punctuate ALT text automatically, and Lynx is really a thing of the past. I
don't feel like dredging up the percent usage of these browsers but I assure
you, it's minimal. Authors should be designing their pages to work well on any
browser, but it's their job to worry about doing that. If they want to alienate
a percentage of their market, however small, that's their own problem. Mozilla
is a new, standards-compliant browser, not a legacy testing system. For that
matter, people designing their pages to strict HTML 4 and CSS standards aren't
doing it to impress Lynx users.
 
>> True, but the alternative is to pick our own size for the box and
>> ignore the styled height/width.
>> It's better to go with the standard than be arbitrary.

> Eh? The alternative to what? The alternative to using HTML tables and
> HTML images for layout is to use CSS tables and CSS images for layout.
> That has nothing to do with picking your own size for the box.

Well, assuming we do draw a box (which is what I'm trying to justify), it's
better to make that box the size of the image it replaces than just pick our own
size for the box.


>> Your argument is that doing things the wrong way and making a mess
>> of everything will ultimately make authors adapt and do things the
>> way you want.

> No, my argument is that doing things the right way will convince
> Microsoft to change their browser to start doing things the right way,
> just as they have done with their CSS standards compliance in IE6.

If I've ever heard a far-fetched statement, that was it.

Microsoft has followed relatively few of Mozilla's cues when it comes to
changing their browser. The standard/quirks mode was one of them. But its
compliance for things like PNG, HTML 4.0, etc. is still lacking, and IE has
stuck with a lot of its old tricks to favor user convenience over standards
(like rendering application/octet-stream *.jpg as a JPEG image). And if their
trend continues, they will favor the general webmastering population over a way
of doing things that's guaranteed to break bunches of pages.

Comment 164

15 years ago
Errata.

> Where, exactly? It might have been used in an example but it's a stretch to say
- it was ever exaggerated.
+ it was ever stressed.
(Reporter)

Comment 165

15 years ago
Note: I received e-mail requesting that I move this discussion out of
this bug. I would like to. I urge Skewer to continue this discussion
by e-mail so that we do not need to spam all this bug's ccs.


> Standards: This is the only one you posted that even remotely
> suggests to authors that they should punctuate their ALT text

I was not only defending my position regarding punctuation, but also
regarding the other points I have been making.


> I barely think an insignificant bit like that is enough to create a
> standard for web designers to punctuate their ALT texts like this.

There is more than just the example:

# Content is "equivalent" to other content when both fulfill
# essentially the same function or purpose upon presentation to the
# user.
  -- http://www.w3.org/TR/WCAG10-TECHS/#def-equivalent

Without punctuation, the same function is not fulfilled.


> Note that this sample code, taken from the HTML 4.01 specification,
> doesn't punctuate the ALT text:

The alternate text of <area> elements in a <map> are handled
differently than alternate texts on <img> elements. Let's not get
side-tracked with that issue. (See bug 8131.)


> Since it's not clearly stated anywhere whether or not ALT text
> should be punctuated, typical webmasters would follow this example,
> along with the code on most websites out there, and not punctuate
> anything.

Actually typical webmasters won't be following examples from the spec
at all. They'll follow authoring guidelines like

   http://www.htmlhelp.com/feature/art3.htm
   http://www.htmlhelp.com/feature/alt-table.html
   http://ppewww.ph.gla.ac.uk/%7Eflavell/alt/alt-text.html
   http://catcode.com/imgguide/alt.html
   http://www.pemberley.com/janeinfo/htnimglt.html

...and so on. (And yes, there are plenty of badly written HTML
tutorials out there that give totally incorrect guidelines for 'alt'
attributes. Such is the effect of freedom of speech.)


> The expectation, as I've said, is that the image's replacement will
> *somehow* be separated from the body text.

That appears to be your expectation. It is not everyone's expectation.
It is not the expectation of the authors of the WAI specifications. It
is not my expectation.

Authors who have this expectation are welcome to write documents in
quirks mode, where your expectation is in fact implemented.


> If everyone used ALT text the way you want them to, the way Mozilla
> handles it would work fine for everyone. However, this just is not
> backed by standards -- 

It is backed by HTML4.01, XHTML 1.1, WCAG 1.0 CORE, WCAG 1.0 HTML, and
UAAG 1.0. This would seem to disprove your point.


> Where, exactly? It might have been used in an example but it's a
> stretch to say it was ever stressed. And WCAG are guidelines, while
> HTML 4.01 is an actual specification. I would be much more inclined
> to accept this behavior if punctuation was mentioned there.

The WCAG are guidelines to which the HTML 4.01 specification refers
normatively, and should therefore be considered a part of the
specification. (Note: The WCAG guidelines were published after HTML
4.01, so HTML 4.01 refers generically to all WAI documents intended
for authors. The effect is, however, the same.)


> And WCAG are guidelines

If you want to quibble semantics, W3C HTML 4.01 is only a
recommendation. When I say "standards" in a Web context I am referring
to all normative W3C documents, which includes the WAI documents.

I apologise for the ambiguity.


> HTML 4.01 is an actual specification. I would be much more inclined
> to accept this behavior if punctuation was mentioned there.

I will contact the HTML working group and ask them to ensure that
XHTML 2.0 includes the text you require to be convinced. However, that
will not be published for many months.


>> Can you give us a reason _why_ text that conveys the meaning of an
>> image has to be in a box? What purpose the box has?
> 
> The "box," which could really be an invisible container for the
> text, would set the text aside the way the image would be set aside.

Yes, you have now stated this approximately three times. However, what
you still fail to give is a reason _why_ this is wanted.


> Think of it as the difference between having an image in the
> background or setting it apart from the text, like this: [...]

That is irrelevant since the image is actually not there.

Also, it is irrelevant since in the case of the image being flowed to
the left, the alternate text would _also_ be flowed to the left, as
the alternate text would still obey the CSS 'float' property.


> For example, you can choose between...
>                                                    
>  The toy market is giving in to merchandising. This blah blah blah blah blah.
>  Blah blah blah blah blah. Toys are looking more and more like our favorite
>  icons from children's movies, particularly Disney-of-the-moment.
> 
>  The movies are a prominent place to start new     +-------------------+
>  merchandising blah blah blah blah blah blah.      |[x] Spider-man toy.|
>                                                    +-------------------+
>

The picture almost certainly does not convey "Spider-man toy". It
probably conveys "The spider-man toy is about 5cm tall, is blue with a
red cape and is made of plastic.". That would therefore be appropriate
alternate text, while "Spider-man toy." would be better as a value of
the "title" attribute.

And to re-iterate, if the <img> element is floated, then, per CSS, the
alternate text will also be floated. This is qutie clearly stated in
the alt text specification we are using.


[skipping past the voice browser discussion since you said it was
irrelevant]


> I don't feel like dredging up the percent usage [of Lynx] of these
> browsers but I assure you, it's minimal.

So is Mozilla's, so I fail to see why the usage is relevant.


> Authors should be designing their pages to work well on any browser,
> but it's their job to worry about doing that. If they want to
> alienate a percentage of their market, however small, that's their
> own problem.

Indeed. If they wish to alienate the Mozilla market, that is their
problem too. Especially since simply removing their DOCTYPE is all
that is needed to get the legacy behaviour.


>> No, my argument is that doing things the right way will convince
>> Microsoft to change their browser to start doing things the right
>> way, just as they have done with their CSS standards compliance in
>> IE6.
> 
> If I've ever heard a far-fetched statement, that was it.

In that case you deny the existing evidence.

Compare IE5.5 to IE6 in terms of: CSS parsing, CSS box model,
:first-line and :first-letter support. Quirks mode handling. There was
a huge step in our direction (the standard-compliant direction).


> But its compliance for things like PNG, HTML 4.0, etc. is still
> lacking and IE has stuck with a lot of its old tricks [...]

Sure, they still have bugs. So do we. One step at a time.
(Reporter)

Comment 166

15 years ago
I wrote:
> The WCAG are guidelines to which the HTML 4.01 specification refers
> normatively, [...]

My bad. It's actually an informative reference, not a normative reference.
(Reporter)

Comment 167

15 years ago
I assume from the lack of response that Skewer has changed his mind.


Returning to the problem at hand. mkaply asked me to tell him what remained to
be done for this bug. If we look at the current (recently updated) spec:

   http://www.hixie.ch/specs/alttext

...then what needs doing is:

   1. the small images need introducing.
   2. the context menus need to be hooked up to the images.
   3. bug 11011 needs fixing.
   4. the placeholder boxes need to have their borders removed (always, not
      just pref controlled -- preferably done using bug 11011).

The settings, alternate text and blocked image handling sections are, I believe,
completely implemented.

Comment 168

15 years ago
The only thing I've changed my mind about is trying to change your mind.

We still need to fix the problem of ALT text being cut short in the placeholder
for quirks mode. There's no excuse for making part of the ALT text inaccessible.
I still think my suggestion in Comment 109 is the best way to handle this. Since
this is quirks mode, it's already been decided that we won't try to flow the
text in with the document the way standard mode does.
(Reporter)

Comment 169

15 years ago
> The only thing I've changed my mind about is trying to change your mind.

Uh, ok... I'm just arguing using logic here. If you can't convince me using
logic then it's likely that your position is illogical...


> We still need to fix the problem of ALT text being cut short in the 
> placeholder for quirks mode.

Please file a separate bug for this.

Comment 170

15 years ago
I tried. Remember bug 109410?
(Reporter)

Comment 171

15 years ago
Yep. It would be a non-issue if it wasn't for bug 102281. Since we can't
implement both 102281 and bug 109410, one of them has to be a WONTFIX. The
module owner picked 102281.

Comment 172

15 years ago
Are you suggesting I open yet another bug solely for the purpose of implementing
an ALT text expansion for quirks mode only?

It seems you're making this very difficult for me, first WONTFIXing my bug, then
telling me to file one very similar to it.
(Reporter)

Comment 173

15 years ago
Bug 109410 is the bug. I should have been clearer when I said "Please file a
separate bug for this" -- all I meant was that this is not the appropriate forum
for discussing that issue. I had, at the time, forgotten that there already
existed a bug for the issue in question. Let's keep discussion of alt text
expansion in quirks mode out of this bug.
Whiteboard: [Hixie-P2] (py8ieh: reexamine test case) → [Hixie-P2] TODO: see comment 167 (py8ieh: reexamine test case)

Comment 174

15 years ago
*** Bug 151801 has been marked as a duplicate of this bug. ***

Updated

15 years ago
Alias: alttext

Updated

15 years ago
Blocks: 163993

Comment 175

15 years ago
Should this behaviour be documented in some form of Mozilla / Netscape web
developers documentation? It seems that collapsing broken images could
potentially 'break' a lot of layouts, especially since the use of 'spacer'
images is still encouraged by e.g. Dreamweaver. It is quite possible to write a
page that triggers standards mode and validates, but responds poorly to this
behaviour. I would also suggest that very few web authours will check for
imageless browsing layouts.
Also, the broken image behaviour is inconsistent with that of most browsers and
so, in the short term, could actually prove an accessability hinderance for
cases where the alt text has been designed for NN4/IE. I doubt that many authors
ever read the accessability guidelines.
If this does deserve some web developer documentation, I will open a new bug for it.
*** Bug 170345 has been marked as a duplicate of this bug. ***
*** Bug 174350 has been marked as a duplicate of this bug. ***
*** Bug 174782 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 179

15 years ago
I recently noticed that a bug appears to have introduced itself with our
handling of images when they are disabled. We are not replacing them with the
alt text, but with a box. So if we look at the current spec:

   http://www.hixie.ch/specs/alttext

...then what needs doing is:

   1. the conditions for when to show a placeholder need fixing.
   2. the small images need introducing.
   3. the context menus need to be hooked up to the images.
   4. bug 11011 needs fixing.
   5. the placeholder boxes need to have their borders removed (always, not
      just pref controlled -- preferably done using bug 11011).

The setting, alternate text and blocked image handling sections are, I believe,
completely implemented.
Assignee: attinasi → other
Whiteboard: [Hixie-P2] TODO: see comment 167 (py8ieh: reexamine test case) → [Hixie-P1] TODO: see comment 179 (py8ieh: reexamine test case)
Target Milestone: mozilla1.1alpha → ---
(Reporter)

Updated

15 years ago
Depends on: 180620
(Reporter)

Updated

15 years ago
Depends on: 180622
(Reporter)

Comment 180

15 years ago
Point 1 is now covered by bug 180620. Points 2 and 3 are covered by bug 180622.
(Reporter)

Updated

15 years ago
Depends on: 125983

Updated

15 years ago
Target Milestone: --- → Future
(Reporter)

Comment 181

15 years ago
*** Bug 169913 has been marked as a duplicate of this bug. ***

Comment 182

14 years ago
*** Bug 169161 has been marked as a duplicate of this bug. ***

Updated

14 years ago
Keywords: mozilla1.0-

Updated

14 years ago
Attachment #70860 - Attachment is obsolete: true
Blocks: 98554

Comment 183

14 years ago
*** Bug 180337 has been marked as a duplicate of this bug. ***
I was reviewing all the comments in bug 25537 and was reminded this bug has not
yet been fixed. Is there any progress?

Mozilla should handle ALT better for accessibility issues and also to better
support our decision to not show ALT as tooltips.
I don't see any point in showing the title or id/name as an replacement. The
title is typically to long for an replacement and id/name are VERY often
something like img1, img2, etc
(Reporter)

Comment 186

14 years ago
Neither do we anymore, see our spec:
   http://www.hixie.ch/specs/alttext
The alternate-text is an important information at icons and should be displayed.
Mozilla 1.4 Release Candidate 1 still doesn't do it. May I remember you, to
implement this feature in 1.4?

Greetings from a Netscape/ Mozilla-fan
we display the alt=""-Text (as this stands for "alternate" aka "if the image
itself can not be displayed".
"alt"-text:

"alt"-text as a property of images is a defacto-standard today. HTML-Editors
like Macromedia Dreamweaver treat it inside ther image properties-pane. A
"title" property _cannot_ be edited inline.

Therefore it is my opinion that mozilla should provide a solution for alt-texts
not only for the case if an image could not be displayed properly. 

E.g. alt-text will be displaied when a title is missing. An entry in Preferences
("Compatibility" [new]) could also be possibly a choice.

Comment 190

14 years ago
Siegfried - showing the alt text when the image is displayed is nothing to do
with this bug - that issue is bug 25537.

Updated

14 years ago
Blocks: 186409

Comment 191

14 years ago
*** Bug 209719 has been marked as a duplicate of this bug. ***
->Image: Layout
Assignee: other → jdunn
Component: Layout → Image: Layout
QA Contact: ian → tpreston

Comment 193

14 years ago
*** Bug 215223 has been marked as a duplicate of this bug. ***

Comment 194

14 years ago
*** Bug 180991 has been marked as a duplicate of this bug. ***

Comment 195

14 years ago
With images disabled, there is a problem with images inside links (<a href>) 
which contain alt="". The images are not shown at all and therefore they can't 
be clicked on. Or maybe they can, but I can't see where on the page they are 
hidden? Does this belong here or should that be a separate bug? They would 
deserve some icon or something...

Besides this, I like the new behaviour of images. At least the change between 
1.3 and 1.5. Some pages now look much better, because irrelevant images aren't 
taking space.

Updated

13 years ago
QA Contact: tpreston → ian
Blocks: 220927
Blocks: 245360
(Reporter)

Comment 196

13 years ago
*** Bug 248340 has been marked as a duplicate of this bug. ***

Comment 197

13 years ago
*** Bug 261752 has been marked as a duplicate of this bug. ***
(Reporter)

Updated

13 years ago
Depends on: 263244
No longer depends on: 263244

Comment 198

12 years ago
*** Bug 234656 has been marked as a duplicate of this bug. ***
(Reporter)

Updated

12 years ago
Depends on: 288064

Comment 199

12 years ago
*** Bug 295555 has been marked as a duplicate of this bug. ***

Updated

12 years ago
No longer blocks: 163993

Comment 200

12 years ago
*** Bug 299025 has been marked as a duplicate of this bug. ***
*** Bug 305141 has been marked as a duplicate of this bug. ***
*** Bug 312327 has been marked as a duplicate of this bug. ***

Comment 203

12 years ago
*** Bug 313156 has been marked as a duplicate of this bug. ***
*** Bug 328744 has been marked as a duplicate of this bug. ***

Comment 205

11 years ago
When a webpage includes a DOCTYPE declaration for XHTML 1.0 (Transitional or Strict) or HTML 4.01 (Transitional or Strict), NOTHING is displayed in place of an invalid image, even though the img tag has width and height and alt parameters.  (If the image is on a remote server and the network is slow, the placeholder can be seen for a split-second, but once FF determines that the file cannot be found, the placeholder disappears and the space is totally closed up.)

For example, the following displays correctly as  ABC[]DEF  where [] is a 100x100 placeholder with the alt text "xyz" overlaid:

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>Missing image test without DOCTYPE declaration</title>
</head>
<body>
<p>ABC<img src="image.jpg" alt="xyz" name="qrs" width="100" height="100" id="qrs" />DEF</p>
</body>
</html>



On the other hand, the following displays incorrectly as   ABCDEF   with no indication of the missing image (or, worse, as    ABCxyzDEF    with "xyz" as simple in-line plain text with no graphical or typographic indication that "xyz" is a replacement for a missing image or even that an image is missing at all):

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>Missing image test with DOCTYPE declaration</title>
</head>
<body>
<p>ABC<img src="image.jpg" alt="xyz" name="qrs" width="100" height="100" id="qrs" />DEF</p>
</body>
</html>



Opera 8.54 and IE6 do not exhibit this behavior; they both display the placeholder regardless of the DOCTYPE declaration.

Comment 206

11 years ago
Another test merely involves going to Reuters/Yahoo news at <http://news.yahoo.com/news?tmpl=index&cid=578>.  

If the preference for images is set to load all images, the images are seen to the left of the related news summary text.  While the images are loading, the alt text may be seen in the space reserved for the images, with excess alt text truncated.  

If the preference is set to load only images from the same server, the complete alt text is above the news summary text.  

While this does not involve broken images, it does demonstrate the problem with blocked images -- the problem with the size and positioning of the image space.  

I first observed this behavior when I upgraded from Mozilla Suite 1.7.12 to SeaMonkey 1.0.  Before then, space was reserved for images.  If the images were blocked, that space remained blank without any alt text.  

Updated

10 years ago
Blocks: 169161
Assignee: jdunn → nobody
QA Contact: ian → layout.images

Comment 207

9 years ago
Created attachment 291087 [details]
Example from Yahoo-Reuters

PDF file

Comment 208

9 years ago
The mail Reuters/Yahoo news page was recently redesigned.  It no longer behaves
as described in my comment #206.  However, it still shows a problem with
displaying ALT text when images are not displayed.  Now, the ALT text continues
well beyond the area reserved for the image by HEIGHT and WIDTH attributes,
sometimes impinging on content text and often overlaying the ALT text of the
next image.  

I have added an attachment that is a PDF file containing an example of the
problem.  In this example, the ALT text overlaps content text.  This was seen
only in a print-out.  On-screen, the ALT text only overlaps the ALT text of
other images.  

Comment 209

9 years ago
If I suppress CSS by setting [View > Use Style > None] in SeaMonkey, the problem at Yahoo/Reuters goes away.  But then so does all styling.  

Typo at the beginning of my immediately previous comment.  It should begin:  
   "The Reuters/Yahoo news page . . . "

Comment 210

9 years ago
This bug needs more attention. Firefox 1, 2, and 3 have come and gone, and everything has been changed except the pathetic way Firefox handles broken images.

I long for the old days with IE4 and Netscape, when I could easily see when an image doesn't load... now, I have to do some freakin' diagnostic bug-testing to see if the image actually ended up on, say, a web forum... or if it's just not loading. Not only that, but this causes the compounded problem that there is NO WAY to actually right click the nonexistent box and tell it to "view image"!

I'd've thought a bug from 2002 would have been fixed by now, honestly...

Updated

8 years ago
Flags: wanted1.9.2?
Flags: blocking1.9.2?
There are a large number of bugs that are marked duplicates of this bug that do not look like duplicates to me.  (In fact, given how broad this bug is, I'm not sure it makes sense to mark *anything* as a duplicate of it.)

It's hard to know which of the many problems described here the "blocking1.9.2?" nomination is for, which makes it almost certain to be minused.

Comment 212

8 years ago
The example in my comment #206 (three years ago) and the specific problem with Yahoo news described in my comment #208 (19 months ago) have been overcome by events, Yahoo having redesigned the page.  This does not negate the problem but merely eliminates an easy test for it.
Flags: wanted1.9.2?
Flags: wanted1.9.2-
Flags: blocking1.9.2?
Flags: blocking1.9.2-

Updated

7 years ago
Duplicate of this bug: 391862

Comment 214

7 years ago
Why are there no placeholders for not loaded images which don't contain alt-text?

Updated

7 years ago
Depends on: 580003

Comment 215

5 years ago
In bug 726919 I vent emotion upon discovering the years of images I was missing out on for one reason or the other.
Depends on: 726919

Comment 216

5 years ago
Please do not collapse the height=... width=... for missing images.

Case in point:
My http://www.couchsurfing.org/people/jidanni/ makes extensive use of
images from sites prohibited in China.

When Chinese users use Firefox to browse the page, they will not detect
anything is wrong. They will assume I write such boring web pages. They
will not suspect it is the Chinese government showing them the ALT
messages instead of the box representing the structure of the page... I
have now made the ALT messages say "[VIDEO]" to compensate as best I can
for this. Normally the ALT message might just say "Charlie Chaplin's
greatest hits."

Please view my page in both Chromium and Firefox with the automatic
image loading preference off. I don't know what IE does.

My ALT codes are short enough to not trigger the Chromium bug.

Comment 217

5 years ago
Most users just glance at pages and don't read through all the text.
Hence making sure they see the rectangle where an image was is the only way to alert them that something is wrong.

Comment 218

5 years ago
(In reply to jidanni from comment #216)
> My ALT codes are short enough to not trigger the Chromium bug.
http://code.google.com/p/chromium/issues/detail?id=773#c64
Duplicate of this bug: 753363

Comment 220

5 years ago
Is anyone ever going to fix this?
(In reply to obik from comment #220)
> Is anyone ever going to fix this?

You're welcome to try; but notice that this bug still depends on three other ones.

Otherwise, please read https://bugzilla.mozilla.org/page.cgi?id=etiquette.html and especially §§ 1.1 and 1.2.
You need to log in before you can comment on or make changes to this bug.