This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
See https://bugzilla.mozilla.org/show_bug.cgi?id=922931 for details.
In particular, if you have <img src="whetever" width=1 height=1> then displaying that as a non-replaced inline with any sort of visible indicator child will affect things like line heights and vertical alignment in ways that the actual image would not. I don't believe there is any UA today that does that sort of thing right now: Gecko shows an empty non-replaced element, and other UAs use a replaced element. We plan to move Gecko to using a replaced element in this specific case as well.
This is intentionally quirks-mode only, specifically modeled after Firefox. It would be really sad if we had to break this. Can you elaborate on why this isn't Web-compatible in no-quirks mode?
(In reply to Ian 'Hixie' Hickson from comment #2) > This is intentionally quirks-mode only Hm, but the actual spec doesn't say so. http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#the-img-element > If the src attribute is set and the alt attribute is not > > The image might be a key part of the content, and there is no textual > equivalent of the image available. http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#rendering > When an img element might be a key part of the content, but neither the > image nor any kind of alternative text is available, and the user agent > does not expect this to change, the element is expected to be treated as > a non-replaced phrasing element whose content is an icon indicating that > an image is missing. No spec text is saying about the rendering mode in this case. Also, it (displaying a non-replaced inline with visible indicator child) is not what Gecko was doing in no-quirks mode (displaying an empty non-replaced element) or in quirks mode (displaying a replaced element).
> This is intentionally quirks-mode only, specifically modeled after Firefox. No, the spec text being quoted here is about standards mode. Specifically, about the behavior of <img src> with no "alt" set at all and a broken image in standards mode.
Right, what I mean is that the behaviour depends on the mode. In quirks mode we have the old-style behaviour of being an inline-block and generally putting the image first. In the no-quirks mode we have the better behaviour of putting the text first, on the assumption that this will encourage more accessible design.
My point is that the spec's requirement for the case I described in comment 1 gives it a height a lot larger than 1px in standards mode. No UA implements that (Gecko treats it as an empty non-replaced element, while others treat it as a replaced element with height 1px), and I expect it would break web pages to do so. Gecko's current plan is to switch to the rendering other UAs have, which is using a replaced element, for this specific case (src set, alt not set at all, image broken) in standards mode.
(In reply to Masatoshi Kimura from comment #3) > (In reply to Ian 'Hixie' Hickson from comment #2) > > This is intentionally quirks-mode only > > Hm, but the actual spec doesn't say so. It's not super clear, you're right, but in the Images rendering section the second paragraph describes the behaviour for quirks mode. Everything else is for the no-quirks (and limited-quirks) mode(s). I should make that clearer. (In reply to Boris Zbarsky from comment #6) > My point is that the spec's requirement for the case I described in comment > 1 gives it a height a lot larger than 1px in standards mode. No UA > implements that (Gecko treats it as an empty non-replaced element, while > others treat it as a replaced element with height 1px), and I expect it > would break web pages to do so. I don't understand. If Gecko treats it as an empty non-replaced element, why is that less height than what the spec gives it? The only difference is that the spec also includes an icon, right? But that doesn't change the height of the element. Is it the width you are concerned about?
> But that doesn't change the height of the element. Unfortunately, it does. Compare the layout of these two divs: <!DOCTYPE html> <style>div { border: 1px solid green }</style> <div><span> </span></div> <hr> <div><span> <span style="display: inline-block; height: 10px; width: 10px"></span> </span></div>
Oh, because there's nothing in the rest of the line box, so the inline gets collapsed away, ok. Rather than breaking all the cases, how about limiting this behaviour specifically to these cases?
That would be a huge PITA to implement: you would need to change your box type based on what other boxes are in your line box. That's not a reasonable thing to do, I believe. I don't think using a sized box for the "no alt attribute" case would break anything, honestly. The usual argument for not doing that, which is that the alt text won't be readable, is clearly not relevant in this case...
Yeah, if we limit this to the case where there's no alt="" in the first place, then I guess it's not so bad...
Checked in as WHATWG revision r8280. Check-in comment: Reframe the <img> rendering section for clarity http://html5.org/tools/web-apps-tracker?from=8279&to=8280
Checked in as WHATWG revision r8281. Check-in comment: Adjust the rules on rendering images without 'alt' attributes. http://html5.org/tools/web-apps-tracker?from=8280&to=8281