23691 - Inline IMGs with no explicit size should not have a placeholder box

Status: VERIFIED DUPLICATE of bug 41924

(Core :: Layout, defect, P3)

Description

[Hixie (not reading bugmail)]

Images that are still downloading but have no explicit width=/height= are
currently given placeholders.

This means that pages will almost certainly have to be reflowed, and in the
meantime, they can be difficult to read (frames all over the place). If instead
we assume that images without dimensions will fail until proven otherwise, and
thus use the alt text in the meantime, then if the image is broken, a reflow
will not be needed, and if the image is ok, then the reader will be pleased
that the page has suddenly improved (and there will be no more reflows than
there are now).

The only reason to use placeholders that I can see -- that they provide
feedback on how much of the page has loaded -- is not IMHO particularly
important as feedback is already being given by our "remaining items to
download" status line and the throbber.

I therefore suggest that we assume that images without dimensions will fail
until proven otherwise, and thus use the alt text in the meantime.

This of course does not apply to images that _do_ have height/width set, as
they will almost certainly not reflow when the image is eventually downloaded.

Comment 1

[troy]

I seem to remember we discussed this and I thought there was an existing bug but
I can't find it.

I don't remember Kipp's rational for giving the placeholder a minimum size
anymore. Maybe it was backwards compatibility.

You raise a good point, but regardless, this isn't something we're going to
revisit now

Comment 2

[Hixie (not reading bugmail)]

Agreed. The place where we discussed it was bug 1994 -- and my comments above
are almost a direct cut and paste. Just thought it was worth keeping this issue
alive. Marking VERIFIED LATER, we can reopen this for 5.1.

Comment 3

[Matthew T (active 1999-2002)]

Sorry to be such a wet blanket, but I actually think images which are either 
broken, or yet to be downloaded, *should* have a placeholder -- whether or not 
they have width and height, and whether or not they have alt text.

Several reasons:
* Without a placeholder, I can't use the context menu to block the image before
  it loads.
* Without a placeholder, I can't copy the image location.
* Without a placeholder, I can't save the (as-yet-unloaded) image to disk.
* Without a placeholder, I can't drag the (as-yet-unloaded) image and drop it
  into my bookmarks, or into a Composer document, or into an e-mail message,
  or ...
* Without a placeholder, I can't use the context menu to open the
  (as-yet-unloaded) image by itself in the window.
* A broken image may not be the fault of the author, but of a tenuous Internet
  connection. Without a placeholder, I can't use the context menu to choose `Load
  Image' and have another go at loading it.
* An array of broken image icons provides considerable semantic value, in telling
  me that the page is poorly maintained and thus likely to be out of date.

Comment 4

[Hixie (not reading bugmail)]

All but the last point are not necessarily true if the alt text frame also
supports the context menu et al. If bug 11011 is implemented, then the 
stylesheet could easily make the alt text frame stand out a little -- e.g.,
with a little icon after the text or whatnot.

The last one would also be solved by a custom stylesheet and also requires 
bug 11011 to be fixed.

However, I will bear these in mind when doing the spec for bug 34981.

Comment 5

[Hixie (not reading bugmail)]

Reassigning to buster...

Comment 6

[Matthew T (active 1999-2002)]

No Ian, ordinary text -- which alt text, when properly displayed, is -- has its 
own behaviors and its own context menu. For example, on Windows I expect to be 
able to click in some plain-text part of a non-frontmost window to bring that 
window to the front without anything else happening. I also expect to be able to 
click on an unloaded image's icon to load that image.

If unloaded images with alt text had no icon, then these two behaviors would 
clash -- I'd click on something which looked like text, and it would start 
loading an image. Or I'd start dragging through what looked like plain text, in 
order to select it, and find that I was actually dragging an image. And so on.

W.r.t. custom style sheets, I don't really care how this is implemented -- just 
that it should be default behavior (if not compulsory behavior) to have an icon 
representing the unloaded graphic, in addition to the alt text.

Comment 7

[Hixie (not reading bugmail)]

That's fair enough. So would just an icon, inline, be a satisfactory compromise
between having just the alt text and having the entire placeholder?

Comment 8

[Matthew T (active 1999-2002)]

Yes -- a little (16*16?) icon, followed by the alt text (if any). That would be 
perfect.

Comment 9

[Jesse Ruderman]

How do you tell where the alt text ends if there's an image before it?

Why is having an image before the alt text preferable to enclosing the alt text 
in a box?

Should the icon always be 16x16, or should its size depend on the font size of 
the alt text?

Comment 10

[Matthew T (active 1999-2002)]

> How do you tell where the alt text ends if there's an image before it?

You can't tell, and you shouldn't have any need to tell. Remember, alt text is a 
replacement for the image.

> Why is having an image before the alt text preferable to enclosing the alt text
> in a box?

Because enclosing the alt text in a box misleads page authors into thinking that
<a href="1.html"><img alt="previous"></a><a href="3.html"><img alt="next"></a> is 
sufficiently distinct, when it's not (it would come out as `previousnext' in Lynx 
or voice browsers).

> Should the icon always be 16x16, or should its size depend on the font size of
> the alt text?

As long as it's always big enough to hit, I don't mind. So I guess it should 
generally follow the font size, but have a minimum width and height as well.

Comment 11

[Hixie (not reading bugmail)]

Would character U+FFFC be acceptable instead of an actual picture? That would
be easier for us to resize with text.
   http://charts.unicode.org/PDF/UFEFF.pdf (sorry, no HTML version right now)
I have a feeling that if we don't use a character, then we will end up using a 
fixed size image, namely the broken image glyph, and it won't resize at all.
Would that be ok until we support SVG?

Comment 12

[Matthew T (active 1999-2002)]

I think having a non-resizable image would be greatly preferable to using an 
obscure Unicode symbol which might not be present in a particular font.

Comment 13

[Hixie (not reading bugmail)]

*** This bug has been marked as a duplicate of 41924 ***

Comment 14

[Matt Perry]

Verified duplicate.