110212 - Draw image placeholder even when there is no height/width

Status: RESOLVED WONTFIX

(Core :: Layout, defect)

Description

[Skewer]

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

[Christopher Hoess (gone)]

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?

Comment 2

[Christopher Hoess (gone)]

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.

Comment 3

[Christopher Hoess (gone)]

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

[Boris Zbarsky [:bzbarsky]]

Layout, not parser.  The parser does not care whether an image has a width.

Comment 5

[Hixie (not reading bugmail)]

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.

Comment 6

[Christopher Hoess (gone)]

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.

Comment 7

[Skewer]

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.

Comment 8

[Hixie (not reading bugmail)]

don't even say it, I don't care

Comment 9

[Christopher Aillon (sabbatical, not receiving bugmail)]

v

Comment 10

[Skewer]

Gerv, this is becoming a problem. Please referee?

Comment 11

[Gervase Markham [:gerv]]

Me? Why me? You need the module owner for layout, who I believe is attinasi.

Gerv

Comment 12

[Boris Zbarsky [:bzbarsky]]

> 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

[Christopher Hoess (gone)]

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.

Comment 14

[Skewer]

> 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

[Christopher Hoess (gone)]

[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.

Comment 16

[Hixie (not reading bugmail)]

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.

Comment 17

[[not reading bugmail]]

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

[Aaron Leventhal]

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

[Tim Powell]

> 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.

Comment 20

[Skewer]

> 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

[Matthew T (active 1999-2002)]

> 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.

Comment 22

[Hixie (not reading bugmail)]

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.

Comment 23

[Skewer]

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.

Comment 24

[Skewer]

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.

Comment 25

[Skewer]

Attachment: Testcase (run in a small window)

Comment 26

[Hixie (not reading bugmail)]

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?

Comment 27

[Skewer]

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.

Comment 28

[Hixie (not reading bugmail)]

> AIUI aural browsers insert a hard stop before and after ALT text.

You are mistaken.