Closed
Bug 23691
Opened 25 years ago
Closed 24 years ago
Inline IMGs with no explicit size should not have a placeholder box
Categories
(Core :: Layout, defect, P3)
Core
Layout
Tracking
()
Future
People
(Reporter: ian, Assigned: buster)
References
()
Details
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.
Reporter | ||
Updated•25 years ago
|
QA Contact: petersen → py8ieh=bugzilla
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
Reporter | ||
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Reporter | ||
Comment 2•25 years ago
|
||
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•25 years ago
|
||
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.
Reporter | ||
Comment 4•25 years ago
|
||
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.
Status: VERIFIED → REOPENED
Depends on: moz-broken, 34981
Resolution: LATER → ---
Target Milestone: --- → Future
Reporter | ||
Comment 5•25 years ago
|
||
Reassigning to buster...
Assignee: troy → buster
Status: REOPENED → NEW
Comment 6•25 years ago
|
||
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.
Reporter | ||
Comment 7•25 years ago
|
||
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•25 years ago
|
||
Yes -- a little (16*16?) icon, followed by the alt text (if any). That would be perfect.
OS: Windows 98 → All
Hardware: PC → All
Comment 9•25 years ago
|
||
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•25 years ago
|
||
> 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.
Reporter | ||
Comment 11•25 years ago
|
||
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•24 years ago
|
||
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.
Reporter | ||
Comment 13•24 years ago
|
||
*** This bug has been marked as a duplicate of 41924 ***
Status: NEW → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•