Closed
Bug 41924
(alttext)
Opened 25 years ago
Closed 5 years ago
Change how layout handles broken images (alt text) [meta]
Categories
(Core :: Layout: Images, Video, and HTML Frames, defect, P1)
Core
Layout: Images, Video, and HTML Frames
Tracking
()
RESOLVED
WORKSFORME
Future
People
(Reporter: ian, Unassigned)
References
(Depends on 1 open bug, Blocks 1 open bug, )
Details
(Keywords: access, meta, top100, Whiteboard: [Hixie-P1] TODO: see comment 179 (py8ieh: reexamine test case))
Attachments
(5 files, 2 obsolete files)
Screenshot of IE 6 clipping alt text (support for comment #102)
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•25 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.
|
||
Comment 6•25 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•25 years ago
|
||
Re-assigning to myself for further investigation...
Assignee: clayton → nisheeth
|
|
||
Comment 8•25 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•25 years ago
|
||
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•25 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.
|
|
Reporter | |
Comment 13•25 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•25 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•25 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)
|
||
Updated•25 years ago
|
Keywords: 4xp,
correctness
|
|
Reporter | |
Updated•24 years ago
|
Blocks: 8979
Depends on: moz-broken
Summary: Change how layout handles broken images → Change how layout handles broken images (alt text)
|
|
||
Comment 28•24 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•24 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 31•24 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)
|
||
Comment 32•24 years ago
|
||
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 35•24 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•24 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•24 years ago
|
Whiteboard: [nsbeta2-][nsbeta3+](py8ieh: reexamine test case) → [nsbeta2-][nsbeta3+][fixinhand](py8ieh: reexamine test case)
|
|
Reporter | |
Comment 37•24 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•24 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•24 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•24 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 43•24 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•24 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
Closed: 24 years ago
Resolution: --- → LATER
|
||
Comment 46•24 years ago
|
||
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•24 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)
|
||
Comment 49•24 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•24 years ago
|
||
Later? This bug should remain open, on a Future milestone.
Status: RESOLVED → REOPENED
Resolution: LATER → ---
|
|
||
Comment 51•24 years ago
|
||
Since this has nsbeta3+ in the status whiteboard, I'm leaving this reopened for triage.
Target Milestone: M18 → Future
|
|
||
Comment 52•24 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 54•24 years ago
|
||
Setting to mozilla0.9. I think this is an important bug to fix.
Target Milestone: Future → mozilla0.9
|
||
Comment 55•24 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 | |
Updated•24 years ago
|
Whiteboard: [nsbeta2-][nsbeta3-] (py8ieh: reexamine test case) → [Hixie-P3] [nsbeta2-][nsbeta3-] (py8ieh: reexamine test case)
|
|
||
Updated•24 years ago
|
Priority: P2 → P1
|
|
||
Updated•24 years ago
|
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Keywords: nsenterprise
|
|
||
Comment 66•24 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
|
||
Comment 69•23 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•23 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|
|
Reporter | |
Updated•23 years ago
|
|
|
||
Comment 71•23 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•23 years ago
|
Target Milestone: mozilla0.9.4 → mozilla1.0
|
||
Comment 73•23 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
|
|
||
Comment 74•23 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•23 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 79•23 years ago
|
||
marking nsenterprise-; will be reevaluated for nsenterprise in future release.
Keywords: nsenterprise-
|
||
Comment 80•23 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•23 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•23 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!
|
|
||
Comment 83•23 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•23 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.
|
|
Reporter | |
Comment 85•23 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.
|
|
||
Comment 86•23 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
|
|
||
Comment 87•23 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 | |
Comment 88•23 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•23 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?
|
|
Reporter | |
Comment 90•23 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•23 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•23 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.
|
|
||
Comment 93•23 years ago
|
||
Moving to Moz 1.0
Assignee: attinasi → attinasi_layout
Status: ASSIGNED → NEW
Target Milestone: mozilla0.9.6 → mozilla1.0
|
|
||
Updated•23 years ago
|
Status: NEW → ASSIGNED
|
||
Comment 94•23 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•23 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•23 years ago
|
||
The change of displaying a "broken image" instead of alt text was done in bug 102281.
|
||
Comment 97•23 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•23 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•23 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 101•23 years ago
|
||
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•23 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•23 years ago
|
||
|
||
Comment 104•23 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•23 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•23 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•23 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•23 years ago
|
Keywords: mozilla1.0
|
||
Comment 108•23 years ago
|
||
This is a demonstration of how the full ALT text can be displayed when it exceeds the size of its placeholder.
|
|
||
Comment 109•23 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.
|
|
Reporter | |
Updated•23 years ago
|
Whiteboard: [Hixie-P3] [Hixie-1.0] (py8ieh: reexamine test case) → [Hixie-P2] (py8ieh: reexamine test case)
|
||
Updated•23 years ago
|
Target Milestone: mozilla1.0 → mozilla1.1
|
||
Comment 112•23 years ago
|
||
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•23 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.
|
|
||
Updated•23 years ago
|
Attachment #10214 -
Attachment is obsolete: true
|
|
||
Comment 114•23 years ago
|
||
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•23 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•23 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+
|
||
Comment 117•23 years ago
|
||
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•23 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
|
|
||
Comment 119•23 years ago
|
||
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•23 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•23 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•23 years ago
|
Keywords: mozilla1.0+
|
|
||
Updated•23 years ago
|
Keywords: mozilla1.0
|
|
||
Comment 122•23 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...
|
|
||
Comment 123•23 years ago
|
||
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 125•23 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•23 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•23 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
|
||
Comment 128•23 years ago
|
||
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•23 years ago
|
|
|
||
Comment 129•23 years ago
|
||
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.
|
|
||
Comment 130•23 years ago
|
||
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
|
|
||
Comment 131•23 years ago
|
||
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•23 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|
|
||
Comment 133•23 years ago
|
||
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•23 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•23 years ago
|
||
|
|
||
Comment 136•23 years ago
|
||
|
|
||
Comment 137•23 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.
|
|
||
Comment 138•23 years ago
|
||
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?
|
||
Comment 140•23 years ago
|
||
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...
|
|
||
Comment 141•23 years ago
|
||
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•23 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?
|
|
||
Comment 143•23 years ago
|
||
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•23 years ago
|
||
Simplified GUI: Broken images: [ ] Display alternate text [ ] Display "broken image icon" Collapsing: ( ) Collapse as much as possible ( ) Respect specified dimensions
|
||
Comment 145•23 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!
|
|
||
Comment 146•23 years ago
|
||
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•23 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•23 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•23 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•23 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•23 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•23 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•23 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•23 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•23 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•23 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 158•23 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•23 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•23 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.
|
|
||
Comment 162•23 years ago
|
||
reassign to low-priority address: what a lot of noise lately.
Assignee: attinasi_layout → attinasi
Status: ASSIGNED → NEW
|
|
||
Comment 163•23 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•23 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•23 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•23 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•23 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•23 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•23 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.
|
|
Reporter | |
Comment 171•23 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•23 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•23 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)
|
|
||
Updated•22 years ago
|
Alias: alttext
|
||
Comment 175•22 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.
|
|
Reporter | |
Comment 179•22 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 | |
Comment 180•22 years ago
|
||
Point 1 is now covered by bug 180620. Points 2 and 3 are covered by bug 180622.
|
|
||
Updated•22 years ago
|
Target Milestone: --- → Future
|
|
||
Updated•22 years ago
|
Keywords: mozilla1.0-
Attachment #70860 -
Attachment is obsolete: true
|
|
||
Comment 184•22 years ago
|
||
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.
|
|
||
Comment 185•22 years ago
|
||
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•22 years ago
|
||
Neither do we anymore, see our spec: http://www.hixie.ch/specs/alttext
|
||
Comment 187•22 years ago
|
||
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
|
|
||
Comment 188•22 years ago
|
||
we display the alt=""-Text (as this stands for "alternate" aka "if the image itself can not be displayed".
|
|
||
Comment 189•22 years ago
|
||
"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•22 years ago
|
||
Siegfried - showing the alt text when the image is displayed is nothing to do with this bug - that issue is bug 25537.
|
|
||
Comment 192•21 years ago
|
||
->Image: Layout
Assignee: other → jdunn
Component: Layout → Image: Layout
QA Contact: ian → tpreston
|
||
Comment 195•21 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•21 years ago
|
QA Contact: tpreston → ian
|
||
Comment 205•19 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•19 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.
Assignee: jdunn → nobody
QA Contact: ian → layout.images
|
|
||
Comment 208•17 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•17 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•16 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...
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•15 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-
|
||
Comment 214•15 years ago
|
||
Why are there no placeholders for not loaded images which don't contain alt-text?
|
||
Comment 215•13 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.
|
|
||
Comment 216•13 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•13 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•13 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
|
||
Comment 221•12 years ago
|
||
(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.
|
||
Updated•6 years ago
|
Product: Core → Core Graveyard
|
|
||
Updated•6 years ago
|
Product: Core Graveyard → Core
|
||
Comment 222•5 years ago
|
||
Do metas get P1?
Flags: needinfo?(svoisen)
Keywords: meta
Summary: Change how layout handles broken images (alt text) → Change how layout handles broken images (alt text) [meta]
|
||
Comment 223•5 years ago
|
||
We've changed quite a lot here over the years. Is there any remaining thing that you think we should change? Otherwise definitely not P1.
Flags: needinfo?(svoisen)
|
|
||
Comment 224•5 years ago
|
||
Taking the liberty of resolving this WORKSFORME as most of this has been fixed.
Status: NEW → RESOLVED
Closed: 24 years ago → 5 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•