110213 - Draw appropriately sized placeholder regardless of standard/quirks mode and expand the ALT text if it is obscured

Status: VERIFIED WONTFIX

(Core :: Layout, defect)

Description

[Skewer]

Procedure: Load a page in standard mode where an image fails to load.

Expected: An image placeholder should be drawn and the ALT text trimmed to fit
that placeholder (as it currently works in quirks mode). This behavior is
standardized by W3C in its user agent accessibility guidelines document
(<http://www.w3.org/TR/UAAG10/>). For example, it is suggested that we "allow
the user to 'toggle' between placeholder and the associated content [alternate
text]."

Actual: Placeholders are not drawn. The extremists that want to have all the ALT
text transformed into real text have that option available to them as a pref.
The rest of us need a solution that meets W3C guidelines and preserves layout
without sacrificing ALT text's effectiveness.

Testcases: Attachment 56728 [details] (expected), attachment 57881 [details] (actual)

See also: Bug 102281, bug 109410, bug 110212

Comment 1

[Christopher Hoess (gone)]

The placeholders referred to in the UAAG can be an inline alt text just as well
as an inline box.  See my comments in bug 110212.

Comment 2

[Hixie (not reading bugmail)]

The whole point of our standards mode is to encourage the best possible 
practice. Having quirks mode do the legacy behaviour is reasonable to some
degree because so many legacy pages (those that trigger quirks mode) are very
badly designed and do not adapt well when alt text is placed inline (as would
happen with lynx or an aural browser).

However there is no reason to encourage bad behaviour (by giving authors the
impression that alt text is a simply the title that goes in the box) in
standards mode. Therefore I think this bug should be marked WONTFIX.

Comment 3

[Christopher Hoess (gone)]

INVALID, this whole bug is based on a ludicrous misreading of the UAAG spec.

Comment 4

[Skewer]

I'm one step away from asking you two to just leave my bugs alone. Your
arguments are based on personal opinion and not supported by any standard or
even analysis of costs/benefits. If you are going to say that we should change
the behavior to something which is more likely to cause a problem (by breaking
layouts and creating a blend between the ALT text of an object and the
surrounding body text), you need to provide good reason for doing so. It's not
enough to say that there is a potential for misuse--if anything we're making the
mistake by disobeying style attributes set on an object. If an object is styled
to be exactly 200x200 pixels and we change its size we're violating CSS. My
argument may be weak but no more so than yours.

By wantonly taking all the bugs that are assigned to the component owners I get
the feeling you don't think they will make the decision you like. I notice that
not once have you had the etiquette of CCing the component owner before you
reassign the bug. If you have a problem with the way placeholders are used, cry
about it to W3C, who currently has nothing to say against the proper behavior
being used in quirks mode. Since there is no respectable standard that
criticizes the behavior suggested in this bug, this is still very much a valid
issue.

Comment 5

[Skewer]

Attachment: Placeholder test page (first test uses W/H, second uses CSS)

Comment 6

[Skewer]

Attachment: Same test, but now CSS2's overflow property is used (and I fixed the left/right goof)

Comment 7

[Christopher Hoess (gone)]

"Placeholder"!  You keep using that word.  I do not think you understand what it
means.  Had you read the UAAG glossary, you would find that  "A placeholder is
content generated by the user agent to replace author-supplied content."  The
definition does *not* say anything about having the same intrinsic dimensions as
the author-supplied content.  In other words, your interpretation of the spec
does not hold water.  Period.  You have imparted meaning to "placeholder" that
does not exist in the spec, and no matter how much you whine about how there's
many ways to interpret this, it is not possible to interpret it to say that
having boxes is better than having alt text inline, anymore that 2 + 2 = 4 can
be interpreted to say "Two plus two is five."

My arguments are not weak; your opinion on the interpretation of UAAG I have
just disproven, and the fact that a member of the W3C Style Working Group has
dismissed your suggestion says what I need to know about "supported by CSS".

I'm not quite sure why you suggest I "cry to the W3C"; you've brought forth an
interpretation of the standard which (as I've pointed out elsewhere) appears to
be unique to you.  It is, therefore, YOUR job to prove that this is a reasonable
interpretation and that this bug is valid.  This can, of course, easily be done
by bringing forth a member of an accessibility working group (on the publically
accessible W3C mailing lists, if you wish) who will endorse your interpretation.

Good luck.

Comment 8

[Skewer]

> "Placeholder"!  You keep using that word.  I do not think you understand what
> it means.  Had you read the UAAG glossary, you would find that  "A placeholder
> is content generated by the user agent to replace author-supplied content."

Er, never mind that. Even though definitions are used fairly well throughout
that document I misconstrued their use of "author-supplied content" since the
alternate text is also considered content (at least, if I've learned anything
from you guys). As a result that document doesn't prove anything either way
(according to it both quirks and standard modes are correct)

However, we should still be rendering the alternate text for IMG elements based
on the width and height properties (note how badly this behaves in the CSS
testcases). While we're at it we might as well do this for the old WIDTH/HEIGHT
attributes. We could at least treat it as a block-level element with the default
overflow set to "visible" (stretching the size of the placeholder as necessary
to fit the text), although I think it would be safer to make the default
overflow "hidden" in both modes (and expand the ALT text as suggested in bug
109410). And as mentioned in bug 110212, the placeholder should be set apart
somehow (maybe with a border and icon).

Gee, this behavior sounds a lot like what we do in quirks, doesn't it?

It's not like I'm suggesting we do something that's totally wrong. I'm just
suggesting a better, safer, more CSS-friendly way of handling alternate text.
Basically, all I'm recommending are default values which could be overridden if
necessary (how we would go about that, I'm not sure, unless there ends up being
an ALT pseudo-class). Note the two testcases I linked to in the first comment
and how the quirks behavior improves the appearance (while not totally
destroying the alternate content assuming we can expand it).

Current behavior: Alternate text is displayed without any rhyme or reason--it is
just spilled into the document.
Expected behavior: Alternate text is displayed at (or at least close to) the
image's specified width and height and set apart from the rest of the document.

Comment 9

[Scott Tran (Wildcard)]

*** Bug 109410 has been marked as a duplicate of this bug. ***

Comment 10

[Skewer]

Scott Tran thinks it's better to combine two different problems into one bug.
Therefore, changing summary.

Comment 11

[Scott Tran (Wildcard)]

Skewer just so you know, Constant changing of the Summary is a bad idea. It
makes bugs like this very hard to follow. The only reason you should change the
Summary is to clarify the bug, morphing bugs isnt a good idea

Comment 12

[Hixie (not reading bugmail)]

> Draw appropriately sized placeholder regardless of standard/quirks mode

This is a valid bug (our "placeholders" should be inline in both modes) but it
has been decided to make a compromise in quirks mode and be more backwards-
compatible (at the expense of not encouraging authors to write good pages, but
apparently that is a sacrifice we are ready to make to become more popular).

Therefore (unfortunately) WONTFIX or DUPLICATE of the uber alt text bug.


> and expand the ALT text if it is obscured

There is a pref that people can use if they need to read the whole alt text, it
cause us to use the inline behaviour for all broken images. There may need to be
UI for this as in IE. If UI is so required it can be requested in a bug assigned
to the prefs people.

Therefore INVALID.

Comment 13

[Skewer]

Reopening bug and removing a certain troublesome user from CC list. I want to
hear what [e-mail] has to say about this.

Comment 14

[Skewer]

Reassigned to attinasi (I don't care about etiquette anymore... WONTFIXing bugs
like this is about as low as you can go) for final decision.

Comment 15

[Scott Tran (Wildcard)]

Skewer... You have already shown great disrespect for the Mozilla community, by
relentlessly reopening this bug and removing a user, even though it has already
been Resolved. I think that even if attinasi was on your side before, he aint
going be now because of all the spam that you are sending him and the rest of
the people on the CC list. Do us all a favor and do a little research before you
post again.

Comment 16

[Marc Attinasi]

Sorry, but I think that this bug is WONTFIX. The way we handle ALT text in
Quirks mode is strictly legacy behavior, and was implemented just to make users
of IE and Nav happy, pretty much.

In standards mode we can do a lot better, both in terms of accessability and
support for low-bandwidth / image-blocking situations. Bug 41924 is tracking our
standard mode alt text presentation, and it has a lot of well-thought-out ideas
in it. At the risk of being flamed for all eternity, I'm marking this WFM. My
hope is that the reporter will collaborate constructively to the refinement of
bug 41924 and the specification being developed therein.  (now if you will
excuse me, I have to find a place to hide)

Comment 17

[Hixie (not reading bugmail)]

verified as per previous comments

thanks marc.