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
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.
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.
INVALID, this whole bug is based on a ludicrous misreading of the UAAG spec.
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.
Created attachment 57983 [details] Same test, but now CSS2's overflow property is used (and I fixed the left/right goof)
"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.
> "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.
*** Bug 109410 has been marked as a duplicate of this bug. ***
Scott Tran thinks it's better to combine two different problems into one bug. Therefore, changing summary.
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
> 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.
Reopening bug and removing a certain troublesome user from CC list. I want to hear what email@example.com has to say about this.
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.
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.
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)
verified as per previous comments thanks marc.