Closed Bug 32351 Opened 25 years ago Closed 25 years ago

www.napster.com layout problem

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Platform:
x86
Windows 98
Type:
defect

Tracking

()

Status:
VERIFIED WONTFIX

People

(Reporter: jruderman, Assigned: troy)

References

(
URL
)

Details

(Keywords: compat)

http://napster.com looks fine as it loads, but once it finished loading, the dark gray bar near the top of the page gets slightly mangled.
Assignee: karnaze → troy
Component: HTMLTables → Layout
QA Contact: chrisd → petersen
That's because there's supposed to be a spacer gif next to the little napster banner underneath the navigation bar. There file name is "clear.gif" instead of "images/clear.gif". NS 4.7 just puts a blank box of specified height and width there, but Mozilla says "clear" in lieu of an ALT text. Since "clear" is wider than the specified 6px the left column gets screwed up. The question is: is it good policy to display the file name of an image which can't be loaded? How does NS 4.x handle this? Sometimes you get the broken image icon, sometimes (when no width or height is specified?) not. Anyway, I'll email the webmaster. I'll reassign to Layout. Troy, what do you think should happen with images? When should the LAT text/filename be displayed if the image can't be loaded?
Same thing happens at http://www.babelfish.altavista.com .
I think thats more the problem reported in bug 31873 and 32094.
I take that back. The document.write problem prevented me from seeing the "clear"'s all over.
We're doing what the HTML 4 spec says should happen and when an image can't be rendered we display the alternate text instead. I don't think people should be using GIF images as spacers. We have received many of these bugs and refused to fix them before so I'm marking this WONTFIX. We can revisit this issue if necessary BTW, Ian Hickson is the person to talk with about this issue. Ian is the one who persuaded us to do the correct thing
Status: UNCONFIRMED → RESOLVED
Closed: 25 years ago
Resolution: --- → WONTFIX
I'm all for displaying ALT text, and I'm all against using GIFs as spacers. Here it's not ALT text though, but the filename that's being displayed (The HTML spec doesn't say that in the absence of an ALT text, the filename should be displayed). I wonder if it would be worthwhile to think about a compromise which would preserve layout of pages with broken images (or when the user has image display turned off). In particular, if width and height are given for the IMG, that should be used (especially if there's no ALT text). Anyway, where would one discuss this? n.p.m.general?
Yes, actually it does say to use the filename minus extension if no ALT text is specified. The HTML 4 spec says that anyway: http://www.w3.org/TR/1998/REC-html40-19980424/appendix/notes.html#altgen Probably the "layout" newsgroup on mozilla.org is the best place to discuss this. Make sure to discuss it with Ian Hickson
Be careful with those new specs. You don't want to break old pages that are likely to comply to old standards but not to new ones. See the discussion on bug #6211. In some ways it's _more_ important not to break old webpages than to stick to new specifications that may or may not apply to the page in question: people making new webpages will test their code with each browser, and fiddle with things (or even add strict dtd definitions!) until the page works, but old pages aren't going to be changed just so they display correctly in mozilla. Should this bug be marked with the "compat" keyword? Is there a better bug for this general discussion?
The HTML 4.01 spec actually doesn't say that anymore. I've posted to n.p.m.layout. I don't know Ian Hickson or know his email, so maybe you could be so kind and point him to the thread?
cc'ing ian
See http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/alttext.txt Particularly relevant to this bug is "Argument Number #6". VERIFIED wontfix. What we are doing is correct.
Status: RESOLVED → VERIFIED
Keywords: compat
I've replied to the post in the ng. While I'm at it... stealing QA. :-)
QA Contact: petersen → py8ieh=bugzilla
> In any case, using images to control layout is deprecated in HTML. > CSS should be used instead. I don't understand these "deprecated" arguments. It was the only real way to do it in old versions of HTML, which browsers are supposed to remain compatible with. > Well then fix the page so that it points to a real spacer GIF! Some people browse with images off. I hope you're not going to tell people living in the third world that 14.4 modems are deprecated :) Also, while Netscape has established itself as the best porn browser (with "close all"), we shouldn't forget the oppsosite end of the market, people who are so paranoid that they turn images off. And then there's the slashdot effect :) You wouldn't want 10000 people e- mailing a webmaster asking why they wrote "clear" somewhere, would you? Anyway, I think the best place for the alt= information for small images is in hover (even if that means we have to display both alt= and title= for broken images) and in the list of page errors (bug 6211).
> Anyway, I think the best place for the alt= information for small images [...] But we can't know that the image is small because *the page author made a mistake and thus we cannot download the image to check*!
> But we can't know that the image is small [...] Oops, I meant for images with height and width given in the webpage. If the author didn't put those in, he/she couldn't expect the page to display nicely while loading (although this isn't a great argument for displaying it poorly, there's no real way around the problem in this case). Clear.gif is usually used with a specific height and width. I think that it's fair for webpage authors to assume that their images, especially ones with width= and height=, won't be displayed with totally different dimensions. The intent of the image doesn't even have to be spacing in order for dumping alt text to become a problem.
Ian, I know you're adamant about us doing exactly what the spec says, and I admire that. However, if we end up breaking too many pages and we can't convince content authors to see the light and do things the proper way then we're going to have a compatibility issue. Is our behavior when handling images that can't be rendered somthing we can vary say by compatibility mode?
Well, I was thinking about this, and David R's suggestion that IMG tags with no "alt" attribute, no "title" attribute, and no "name" attribute and a small "height" or "width" attributes be given empty alt text may in fact be quite a good idea. Shall I look into this when I look into bug 24125?
Yes, I think we need to do something about this problem.
*** Bug 32533 has been marked as a duplicate of this bug. ***
If HTML 4.01 doesn't actually say to use the filename minus extension as a fallback for the alternate text, then maybe we should stop using it. If we check ALT, NAME, and TITLE and if none of them have values then we just use "" instead That would seem preferable to me than trying to conditionally decide whether to use it based on the specified width and height. It's tricky to decide what constitutes small, and it won't be that obvious to users what we're doing
I think there are really two issues here. One is what to do with images that can't be loaded. The other one is what, if anything, to display in situations where no ALT text is given for an IMG. ALT is an accessibilty issue: the aim is to provide access to content where the primary format (in this case, images) can't be viewed for various reasons. If an image can't be loaded, however, there can be no issue of alternative access to the content, since there is no content. In this case, I think, the UA should deal with the page in a way that breaks as little of the rest. This would mean to just display a transparent rectangle where the image would be (if width and height are specified) and/or a broken image icon, to alert the viewer that there is a problem with the page. The second issue is a real one, even for a graphical UA. Technological limitations may prevent the user from browsing with image loading enabled, and there might even be situations where visually impaired people would use Mozilla instead of a text-based browser. or these situations, we should provide the best possible access to the content, and that includes doing something intelligent when the ALT text is missing. I added a comment with suggestions from the Web Accessibility Initiative to bug 24125. Here, less can often be more. Accessibilty is *not* increased if we display the filename for every spacer and bullet. On the other hand, browsing with image loading turned off is pointless if you don't give ALT strings to images that likely contain content (in particular, linked images and image maps). For the case of linked images, the WAI suggests using the HTTP header title of the target file, or the filename part of the target URL, instead of the filename of the image. In any case, size heuristics are something that shouldn't be dismissed out of hand, I think.
As far as your first point goes I don't agree. If the image can't be loaded then yes there is alternate content and the alternate content should be used instead. That is very clear from the HTML 4.01 spec. From 13.2: "The alt attribute specifies alternate text that is rendered when the image cannot be displayed..." Yes it is there for the other issues you mention (users without graphic terminals, visually impaired users, those who have turned off image display), but the spec does say the alternate content should be used if the image can not be rendered
>As far as your first point goes I don't agree. If the image can't be loaded >then yes there is alternate content and the alternate content should be used >instead. But does it have to be displayed as normal text?
That's what the HTML4 spec says
So you destroy all kinds of old pages, slashdotted pages, and pages viewed with images off until the website author learns CSS and fixes it? That's a solution that not many website authors are going to like, especially ones whose servers get slashdotted (CSS is going to slow it down even more, and I don't think I want to know what happens if a user hits reload on a slashdotted server until the page comes up but isn't able to get the style sheet). I say go with the HTML 4.0 spec only if the page says "I want to be interpreted under HTML 4.0" with its doctype. (Note: this is also being discussed in bug 34981.)
> So you destroy all kinds of old pages, slashdotted pages, and pages viewed > with images off until the website author learns CSS and fixes it? What are all these mythical pages that get completely destroyed by us rendering them with the textual equivalent of their images inline instead of using placeholder boxes??? I'd hate to see them in Lynx, or listen to what blind browsers must hear when viewing those sites. Please point me to them, so that I can start evangelising! > CSS is going to slow it down even more CSS actually reduces the total bandwidth required. That, however, is another issue (contact me by e-mail if you wish to challenge it). > and I don't think I want to know what happens if a user hits reload on a > slashdotted server until the page comes up but isn't able to get the style > sheet). I don't understand this -- please explain it to me (by e-mail, unless it is very pertinent to this bug).
How about if we did, like now, display ALT text (and if there is none, name, label, or filename), but always in a box the size of the image (if WIDTH and HEIGHT attributes are given). That way: (1) we'd always be displaying ALT text (maybe make sure that the entire text is visible by adding tooltips), (2) wouldn't have to worry about special cases, and (3) wouldn't break any page layout (if images can't load or image loading is turned off).
This misses the fundamental point: that HTML is *NOT* about "page layout". If the page doesn't look like the author intended, then THAT IS WHAT IS HAPPENING ANYWAY if, e.g., fonts have been changed, there is a user stylesheet, author colours have been disabled, the browser is not graphical, the page is going through a sadistic firewall, or any number of other possibilities. If the image is a decorative graphic, then we can drop it altogether (this should be the alt="" case, but some heuristics may be needed to work out when an image is just decorative or used for layout). If the image is not decorative, and is in fact informative, then it should have a textual equivalent in the form of its alt text, and that is what we should show (or a synthesised version, e.g. from the filename or the title attribute). As I have previously mentioned, the important aspect of the page is not its layout, it is its content. Please try to see this. If images are disabled, then if the page relies on images for layout, then that's ok: forget the layout altogether, and simply draw the remaining text. Why is this such a problem?
>As I have previously mentioned, the important aspect of the page is >not its layout, it is its content. At least inform that user that you've ****** the layout by drawing a box around the alt text, or at least by italicizing it. Better yet, give the user some options so he can decide how he wants to trade off layout and content for the page he's viewing (see my 2000-04-07 23:44 comments on bug 34981). (side question: if an image precedes the text in a paragraph, are the words describing it supposed to have a period at the end?)
> (side question: if an image precedes the text in a paragraph, are the words > describing it supposed to have a period at the end?) Yes. However, the alt text is NOT supposed to be a DESCRIPTION of the image, it is supposed to be an alternative representation of the MEANING of the image. For example: <p> <img src="house.png" height="110" width="320" alt="The house is white, with green shutters on the windows. " title="The house as seen from the west." /> The house is in the middle of... </p> ...and NOT: <p> <img src="house.png" height="110" width="320" alt="A white house with green shutters on the windows. " title="The house as seen from the west." /> The house is in the middle of... </p> This is quite an important distinction, which I fear may be difficult to explain to all the authors who still think the web is WYSISYG. Look at the first of those snippets, however, and think about how you would like it rendered in Lynx, or in Mozilla if images are disabled (i.e. if the user has stated he does not want to see any images). 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... ...however if we use the height/width then it would look like this: +---------------------------------+ | The house is white, with green | | shutters on the windows. | | | | | | | +---------------------------------+ The house is in the middle of... I think the first is definitely the best.
I think the first is definately the worst :) Mostly because it doesn't inform the user that the image isn't there, but also because not many webpage authors take the time to get alt text right. Don't forget that a sentence often can't convey all of the information to the user -- for example, an image is much more likely to allow the person to recognize a person or a house in a different context than some alt text. If it's a picture of a face, some users might decide to download the image if they can tell it's an image. <i>The house is white, with green shutters on the windows.</i> The house is in the middle of... isn't too bad though, and in my mind is almost on par with +---------------------------------+ | The house is white, with green | | shutters on the windows. | +---------------------------------+ The house is in the middle of... Of course, the user should get to choose (my comments in bug 34981).
Depends on: 34981
You need to log in before you can comment on or make changes to this bug.