Closed
Bug 110212
Opened 23 years ago
Closed 23 years ago
Draw image placeholder even when there is no height/width
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: SkewerMZ, Assigned: ian)
Details
(Keywords: qawanted, Whiteboard: INVALID/WONTFIX/DUPLICATE of bug 41924)
Attachments
(1 file)
298 bytes,
text/html
|
Details |
Procedure: See testcase. (This may also be a problem in cases where height/width is set in CSS - I may make a testcase for this later.) Expected: Last test is drawn in a placeholder. Actual: Last test is drawn as plain text (which is confusing and goes against W3C's user agent accessibility guidelines at <http://www.w3.org/TR/UAAG10/>). Testcase: Attachment 56728 [details] Build: 2001111403 W2k
Comment 1•23 years ago
|
||
Regardless of how much you love this little misfeature, there is *nothing* in the UAAG that says we should do this. (I can only conceive that you've arrived at this conclusion by glancing over the table of contents and assuming section 4 means "the user should be able to configure everything".) Closing WONTFIX, and if you're going to promote bozosities like this, don't try to pretend they're spec-mandated, OK?
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
Comment 2•23 years ago
|
||
I'm sorry, I flamed too soon; just found section 2.3 based on your comments in the next bug. I'm not sure the spec says quite what you think it says, but I'll have to examine it. Apologies for getting pissy.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Comment 3•23 years ago
|
||
OK, impression from a quick skim: "placeholder" does not mean "a box the size of the image". Showing the alt text inline is a perfectly conformant placeholder per these specs. While you may prefer that rendering, my impression is that boxes are, in fact, worse placeholders on pages with well-written alt text, and that, if we do them at all, they should be quirks-mode only.
Comment 4•23 years ago
|
||
Layout, not parser. The parser does not care whether an image has a width.
Assignee: harishd → attinasi
Status: REOPENED → NEW
Component: Parser → Layout
QA Contact: moied → petersen
Assignee | ||
Comment 5•23 years ago
|
||
Part of this bug is a duplicate of bug 41924. The other part is INVALID -- none of the arguments mentioned on bug 102281 in any way apply when the HEIGHT and WIDTH attributes are _not_ given.
Assignee: attinasi → ian
Whiteboard: INVALID/WONTFIX
Comment 6•23 years ago
|
||
Marking INVALID on grounds of impossibility and/or stupidity; it's clearly impossible for us to determine height and width attributes for an element we can't download, and doing so for images-disabled mode would involve downloading the entire element, laying it out to determine height and width (but not displaying it), and *then* reflowing to give the correct size to the box, which is stupid and defeats the point of images-disabled mode.
Status: NEW → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → INVALID
Image size is not what I'm arguing for. I'm arguing for behavior similar to IE (don't even say it, I don't care). The ALT text should be drawn in a placeholder as a block element--similar to the way it would be in a table or DIV with border. I'll reopen this--there is nothing invalid about it; at worst it is a dup of bug 41924. Don't let your personal opinions make you too hasty to mark a valid bug WONTFIX. Doing so detracts from the progress of Mozilla. It may sound silly, but it is true. Again, we need to do this in order to separate an image's ALT text from the content of a site. With the possible exception of an elaborate rebus made out of images, the ALT text should not blend in with the rest of the body text. And quirks-mode only is stupid. There is no standard saying we shouldn't do this, and it could be argued that UAAG recommends it.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Assignee | ||
Comment 8•23 years ago
|
||
don't even say it, I don't care
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WONTFIX
Reporter | ||
Comment 10•23 years ago
|
||
Gerv, this is becoming a problem. Please referee?
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
Comment 11•23 years ago
|
||
Me? Why me? You need the module owner for layout, who I believe is attinasi. Gerv
Comment 12•23 years ago
|
||
> The ALT text should be drawn in a placeholder as a block element > the ALT text should not blend in with the rest of the body text. OK. Sorry, but this is incorrect (or more to the point not always correct). There are two types of sites out there: 1) Glitzy commercial user interfaces 2) Documents that have real content. While the first of these indeed fits in with what you have said, the second tends to use images in one of two ways: a) illustrations (generally with a caption) b) inline images to handle display of content that HTML does not handle (eg math) In both cases, inline alt text is much preferable to block (block alt test in case (b) would be a disaster). In case (a) the illustration is already offset from the main text by being in a separate paragraph or floated div, as a result replacing the image with text does _nothing_ to decrease readability. Don't impose alt rendering suitable only for toy documents on people who are trying to get real work done.
Comment 13•23 years ago
|
||
Removing harishd, who also doesn't need to be privy to this. >Image size is not what I'm arguing for. I'm arguing for behavior similar to IE >(don't even say it, I don't care). Yeah, we should do what's best, and ignored those eeeevil standards. Unless we think we can misinterpret and twist them to make our point, in which case they're not so bad. (Incidentally, I didn't initially object to the change in quirks mode, until you spun off these faux standards bugs asking us to break things further.) >The ALT text should be drawn in a placeholder >as a block element--similar to the way it would be in a table or DIV with >border. I'll reopen this--there is nothing invalid about it; at worst it is a >dup of bug 41924. I didn't mark it invalid because I thought placeholders were stupid. (That was for bug 110213.) I marked it INVALID because IT IS IMPOSSIBLE to determine the size of such a placeholder box in some cases, and ridiculously inefficent in others. Period. Completely above and beyond my personal tastes about this feature. I'm sorry you didn't read the comment when I closed the bug, but reading is clearly not one of your strong suits, anyway. >Don't let your personal opinions make you too hasty to mark a valid bug > WONTFIX. I haven't done that so far as I can see. Will you also get mad at me if I WONTFIX a bug requesting that Mozilla lay out a page before it arrives? >Doing so detracts from the progress of Mozilla. It may sound silly, Wow, just like 90% of everything you've said in this discussion. What are the odds of that? >but it is true. It is. Too bad it hasn't happened. >Again, we need to do this in order to separate an image's ALT text from the >content of a site. Ah ah ah ah ah...I thought it was layout information that was important? That *was* the justification for having these boxes in the page, right? If all we're doing is making alt text stand out as alt text, I'd suggest we use the new alt pseudoclass attinasi should be developing as part of this cleanup to draw some sort of text decoration or outline around alt text. In fact, I did suggest this. The fact that you didn't read *that*, either is, fortunately, no surprise. >With the possible exception of an elaborate rebus made out of >images, the ALT text should not blend in with the rest of the body text. Fair enough, see above. >And quirks-mode only is stupid. There is no standard saying we shouldn't do >this, and it could be argued that UAAG recommends it. "There is no standard saying we shouldn't do this"--the last refuge of the desparate. There's no standard to say we shouldn't crash the browser and wipe the user's hard drive when we hit a page with invalid HTML, but I think we can agree that would be poor UA behavior. As for the UAAG, your interpretation does not agree with that of anyone of any authority whatsoever; my challenge for you to discover such an authority still stands. Look, make up your mind: Do we show these boxes because the height and width attributes convey crucial layout information, or because we should show that a given passage of text is replaced? If the first, we're just going to have to show the text inline, because we can't reasonably (or sometimes possibly) generate height and width for the boxes. If the second, then we should set a default style on the alt pseudoclass so that there's a little outline or some kind of text-decoration to indicate that, and display the text inline. If you support the second proposal, I would be happy to set up a bug (this or another one), dependent on the bug to create the pseudoclass, for creating such a decoration. Furthermore, I would enthusiastically support such a proposal. Ball's in your court.
Reporter | ||
Comment 14•23 years ago
|
||
> Yeah, we should do what's best, and ignored those eeeevil standards. For crying out loud, **what standards**? You *must* cite a URL or something! Show me these standards that you are always talking about. I'd like to see your mysterious standard that says "Blend the ALT text of images into the body text, and never put it into a placeholder frame." >>The ALT text should be drawn in a placeholder >>as a block element--similar to the way it would be in a table or DIV with >>border. I'll reopen this--there is nothing invalid about it; at worst it is a >>dup of bug 41924. > I didn't mark it invalid because I thought placeholders were stupid. (That was > for bug 110213.) I marked it INVALID because IT IS IMPOSSIBLE to determine the > size of such a placeholder box in some cases, and ridiculously inefficent in > others. Period. Completely above and beyond my personal tastes about this > feature. I'm sorry you didn't read the comment when I closed the bug, but > reading is clearly not one of your strong suits, anyway. Impossible? Just draw it the same way we would draw a DIV with the ALT text as its content. It has nothing to do with the image's size--what we should do is put the text in some sort of container. The placeholder's size would be determined by the size of the contained ALT text. It's hardly impossible; I mean, even Microsoft managed to figure it out. What, don't tell me you thought we were going to try to pick the dimensions out of whatever image data we managed to get... > Will you also get mad at me if I > WONTFIX a bug requesting that Mozilla lay out a page before it arrives? Read more carefully, that's not what's being proposed here. >Again, we need to do this in order to separate an image's ALT text from the >content of a site. > Ah ah ah ah ah...I thought it was layout information that was important? That > *was* the justification for having these boxes in the page, right? If all > we're doing is making alt text stand out as alt text, I'd suggest we use the > new alt pseudoclass attinasi should be developing as part of this cleanup to > draw some sort of text decoration or outline around alt text. In fact, I did > suggest this. The fact that you didn't read *that*, either is, fortunately, > no surprise. That's exactly what I'm suggesting. Did you just now figure that out? [Saving this part for a different argument] > Look, make up your mind: > Do we show these boxes because the height and width attributes convey crucial > layout information, or because we should show that a given passage of text is > replaced? If the first, we're just going to have to show the text inline, > because we can't reasonably (or sometimes possibly) generate height and width > for the boxes. If the second, then we should set a default style on the alt > pseudoclass so that there's a little outline or some kind of text-decoration to > indicate that, and display the text inline. My mind was made up all along. You just decided to wait until after you'd closed the bug WONTFIX and called what you thought was my proposal a "bozosity" before you found that out. Obviously, my suggestion was never to (try to) make assumptions on image size. That would make about as much sense as the word "bozosity." > If you support the second proposal, I would be happy to set up a bug (this or > another one), dependent on the bug to create the pseudoclass, for creating such > a decoration. Furthermore, I would enthusiastically support such a proposal. Be my guest.
Comment 15•23 years ago
|
||
[not trying to quote previous content] Okay, I think we're reaching some common ground here. I think I have confused some of your comments in bug 102281 with other people arguing in that bug, who said that the reason we should respect "width" and "height" attributes was that they conveyed layout information, which was on a par for consideration with the item displayed in the content. If you are, in fact, expanding the box containing the alt text as per IE (the method I was hinting about), that layout information is lost, which makes me question why we have the box in the first place. If, on the other hand, the box is just there to designate the fact that alt text seems to be replaced content (which is what you are saying, and which, yes, I have only just figured out), I question why we need to break the inline flow to put it there. I cannot quote a direct spec reference that says "Alt text is to be rendered directly into the inline flow"; if I could, we wouldn't have needed to have this discussion. My main points of argument are as follows: 1) We're supposed to render the contents of the alt attribute as a replacement for the image when it can't be loaded. The spec doesn't specify that replaced content like alt text is supposed to be handled differently than an ordinary inline because box content might be rendered there in certain situations. Does it explicitly bar doing so? No. Does doing so require adding one's own behavior to the spec (and not pursuing a simpler interpretation)? Yes. 2) I can also point to the informed opinions of Those Who Should Know: Alan J. Flavell, who's written what as best I can make out is the document defining best current practices (in the informal sense) for using alt texts <ppewww.ph.gla.ac.uk/~flavell/alt/alt-text.html> has expressed both on W3C mailing lists <http://lists.w3.org/Archives/Public/w3c-wai-gl/2000OctDec/0484.html> and in private correspondence his support for the display of alt text as a seamless inline. Not to get things going again, but he also refers to Hixie's bit of advocacy as an excellent resource for these issues. Reading over the back accessibility mailing lists suggests that: a) People are mostly irritated at non-resizable image boxes concealing alt text. b) A few people have said that displaying alt texts inline is good. c) IE's behavior has been said to be better only in comparison to non-resizing boxes. To sum up here, I don't think that we get any advantage from reading into the spec what isn't there and rendering these boxes. Several people have pointed out here, in the other bugs (102281, bug 41924, etc.) that the boxes can look unpleasant, particularly when images are blocked from ad servers. I agree that it would be nice to have some way to differentiate alt text from the inline content without breaking the inline flow; I envision something like what links look like in text, except outline intead of underline, or something like that. (We should probably get mpt's advice on the best way of making the text stand out). Is there any aesthetic advantages to placeholder boxes that you feel I've overlooked, or do you think that some type of text-decoration would suffice? If so, the best thing to do would probably be to close this and 110213 and start a new bug for it, which I'd be happy to do. I'm happy to hear that we more or less want the same behavior, and I'm sorry I didn't realize what exactly you were proposing earlier; when you said "similar to IE", I thought you were advocating the current behavior (which is similar, but not identical) to IE, + tooltips. Trying to work between expanding placeholder boxes and inline text-decoration is a lot easier.
Assignee | ||
Comment 16•23 years ago
|
||
Bug 41924 already requests a way to highlight alt text, namely a little inline image. See my spec in that bug. That has already been approved by one of the Mozilla's UI people.
Whiteboard: INVALID/WONTFIX → INVALID/WONTFIX/DUPLICATE of bug 41924
Comment 17•23 years ago
|
||
I just thought of something, as a passer-by: if you come to the conclusion about adding alt-text info, may I suggest a solution: Why not create the alt-text as a popup tooltip not add it to rendering.. that way if a user wants to know.. they can mouse over it. -Dennis
Comment 18•23 years ago
|
||
My opinion was asked on this bug - wearing my W3C rep/UAAG/accessibility hat: I believe the guidelines can be read either way. You could argue that drawing a box around the text makes it more accessible for some people, and less for others. From what I can see, it comes out as a wash. The UAAG doesn't require boxes in placeholders at all, at least in their definition for placeholder (this was pointed out by Christopher Hoess in comment #8). So, completely removing the UAAG from this argument, which is more accessible? I don't believe that drawing a box around the text or not is a significant issue for accessibility. If there are reasons for doing it, they are asthetic, not accessibility. Some other rationale must be used in order to incur the work required here, especially if it is significant work.
Comment 19•23 years ago
|
||
> If there are reasons for doing it, they are asthetic, not accessibility
Actually this impacts usability. Drawing some sort of distinctive box around
inline alt text serves to keep the user informed that the source for the text
was an image. This is especially important when the image doesn't load because
1) it's broken or 2) the user has image loading disabled for speed, but may
want to load specific images. If there's no way to tell alt text from regular
text, that's a problem. This assumes that you can load specific images even
when automatic loading is turned off, as with netscape 4.
Reporter | ||
Comment 20•23 years ago
|
||
> Actually this impacts usability. Drawing some sort of distinctive box around
> inline alt text serves to keep the user informed that the source for the text
> was an image.
Agreed. It's ridiculous not to set images apart. Repeat:
Again, we need to do this in order to separate an image's ALT text from the
content of a site. With the possible exception of an elaborate rebus made out of
images, the ALT text should not blend in with the rest of the body text.
Comment 21•23 years ago
|
||
> I agree that it would be nice to have some way to differentiate alt text from
> the inline content ... We should probably get mpt's advice on the best way of
> making the text stand out
I would regard any differentiation between ALT text and the text surrounding
it, *other than* that specified by the author (punctuation, HTML markup, or
CSS), as a bug. ALT text should be used to make a page usable (understandable
and informative) for people who can't or won't see images, not to make such
people feel guilty or frustrated that the images are not present. Making any
sort of distinction between alt text and the surrounding text would naturally
encourage the latter situation, by leading authors to write ALT text assuming
that some sort of demarcation was in place when (for speech or text-only
browsers) that is not the case. That would severely hamper the accessibility of
the Web, and I could not condone it.
In my opinion, this bug is invalid.
Assignee | ||
Comment 22•23 years ago
|
||
Given that one of Mozilla's most prolific UI people thinks this bug should be invalid, that Mozilla's accessibility expert thinks this should be WONTFIXed unless good reasons can be found to do the work, that the area's QA contact thinks this bug should be invalid, that several hard working regular Mozilla triagers think this bug is invalid, and that the spec on bug 41924 specifically provides a way to target images that are not being shown (using a small proxy icon), I believe that the issues in this bug are INVALID, WONTFIXable and DUPLICATE all at the same time. Picking WONTFIX and resolving as such.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WONTFIX
Reporter | ||
Comment 23•23 years ago
|
||
I want to hear what attinasi has to say about this. He's the component owner, he will render the final decision. I figure he won't let his personal opinion cloud his judgment and common sense the way some of us do. For the moment I will leave this alone, even though the resolution is still as incorrect as it ever was. I still say it's wrong to render a page like this: <IMG ALIGN="right" ALT="Picture of trees" SRC="...broken...">We at Safety Petroleum care about our environment. As this: We at Safety Petroleum carePicture of trees about our environment. The example is *still* a perfectly valid use of HTML, *still* does nothing wrong according to W3C, and is *still* mistreated by Mozilla. Even aural browsers probably render this better than Mozilla does. Apparently you have an objection to having a browser that *WORKS*. I'm waiting for attinassi's decision. Whatever he says, I will agree with.
Reporter | ||
Comment 24•23 years ago
|
||
Actually, an aural browser would separate the ALT text for that image and read it as its own entity, and it would do so based on the object's position in the document, not its formatted location. That would be read as "Picture of trees. We at Safety Petroleum care about our environment." Much more correct than what we do.
Reporter | ||
Comment 25•23 years ago
|
||
Assignee | ||
Comment 26•23 years ago
|
||
Are you saying Lynx, Emacs/W3, and the EmacsSpeak (an aural browser) are all buggy? And could you point to a single place in the spec that says aural browsers are allowed to render a document out of order?
Reporter | ||
Comment 27•23 years ago
|
||
I'm saying that if we're going to simulate them, we should do so *accurately*. AIUI aural browsers insert a hard stop before and after ALT text. We do not. And we *do* render ALT text into the layout where the image would be placed, not in its location in the flow of the document. *PLEASE PAY ATTENTION* especially when handling things as reckless as WONTFIX.
Assignee | ||
Comment 28•23 years ago
|
||
> AIUI aural browsers insert a hard stop before and after ALT text.
You are mistaken.
You need to log in
before you can comment on or make changes to this bug.
Description
•