34981 - Change how layout handle broken images

Status: VERIFIED DUPLICATE of bug 41924

(Core :: Layout, defect, P2)

Description

[ari zweiman]

these gifs show up with the words 'clear' and 'bolt'

Comment 1

[Hixie (not reading bugmail)]

ari: Which page, exactly?
The http://www.flexmind.com/ page does not mention "clear.gif" nor "bolt.gif".

Note that the problem is probably that the page is referring to some non-
existant files, so we are (correctly) showing the alt text instead.

Comment 2

[Jesse Ruderman]

This is like bug 32351.

py8ieh, it's "IMO correctly", not "correctly".  Lots of people (including me) 
disagree with you on which font should be used, whether a border should be 
drawn around the text, and whether the page's width= and height= should take 
precedence over the length of the text.

Comment 3

[Hixie (not reading bugmail)]

If you want it drawn in some other way, then that is what CSS is for. Given
no styles (the default) then the alt text should, per HTML4 and CSS2, be drawn
inline just like if it was in a SPAN.

Comment 4

[Jesse Ruderman]

You really can't expect all website authors to go out and learn CSS, and then 
apply it to all of their old broken pages (and pages on slashdot-effect-prone 
servers, and pages that might be displayed by people who have images turned 
off). 

Also, old browsers followed old standards by displaying broken images in a 
rational way.  I don't mind if ALTs get displayed as normal text on pages that 
specify dtd as strict 4.0, but they shouldn't be on pages where the exact 
standard can't be determined.

Comment 5

[Hixie (not reading bugmail)]

If those pages render fine in Lynx, then our rendering will be fine too (in fact
our alt text handling is better than Lynx's right now). If the page does not
render well in Lynx, then the page is already broken for the many people who,
for whatever reason, cannot use the more common graphical browsers. It is about
time that authors realised that this actually _is_ an issue.

You don't have to learn CSS to do the right thing -- just provide relevant text 
for the "alt" attribute. Relevant is very often going to simply be "".

See also:
   http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/alttext.txt

Comment 6

[Jesse Ruderman]

ok. that alt="" stuff is reasonable.  but when there isn't alt text or some non-
empty alt text is given, does the alt text _have_ to be displayed as normal 
text? i think the confusion generated by displaying it as nromal text far 
outweighs the benefit of complying with one specific, old version (4.00) of the 
HTML spec without using conditional-branching to only displays it in a box 
unless the page specifies HTML 4.00.

Comment 7

[Hixie (not reading bugmail)]

> but when there isn't alt text 

I'm going to be investigating that particular case soon. We may change our 
behaviour in the case of no alt text being specified at all.

> or some non-empty alt text is given, does the alt text _have_ to be displayed 
> as normal text?

That's the idea. The image is not available, so a textual equivalent is used
instead. The reader should not even know that the image is missing.

> i think the confusion generated by displaying it as normal text far 
> outweighs the benefit of complying with one specific, old version (4.00) of 
> the HTML spec without using conditional-branching to only displays it in a 
> box unless the page specifies HTML 4.00.

Given that the benefit is that the page is readable without empty boxes and 
truncated descriptions everywhere, I would disagree. Again, I point you to Lynx.
If the page is written with anything even remotely resembling an effort, then
there should be no problems with displaying the alternative text inline. By
design, that's what it's there to do.

Please read http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/alttext.txt if
you haven't already...

Comment 8

[Jesse Ruderman]

> The reader should not even know that the image is missing.
(also replying to your argument #5 on 
http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/alttext.txt)

Okay.  That's one of the main points we disagree on.  I think the reader should 
know when an image can't display because:
- The page author is much more likely to notice some boxed text than inline 
text before she uploads her site, after she uploads it, and when she visits it.
- Visitors can tell webpage authors that images are missing, and the site can 
be FIXED so that all of the information intended to be available is available.


I hope you wouldn't say things to users of open-source software similar to you 
say to readers of webpages: "If it doesn't work properly, the author made a 
mistake.  You shouldn't be informed of the problem, but instead the output 
should adapt to contain as much useful information as possible."  The user has 
about as much chance of getting the problem fixed in both cases.  Some users 
have the time and knowledge to fix an open-source software package, just as 
maintainers of software packages (and of websites) sometimes fix the problem 
quickly.


How's this for a compromise?  Add some prefs that let users control how mozilla 
handles broken images.  Right clicking on a broken-image box or inline alt text 
would give an option to go to that area of prefs.

[checkbox] show alt text while page is loading in addition to on broken images.

[radio with four choices]
(1) display alt text inline (preserve meaning if well-alted)
(2) display alt text inline and italicize it (preserve meaning and hint at 
broken image)
(3) display alt text in a box, giving precedence to the dimensions of the alt 
text.  (preserve meaning and unambiguously indicate a broken image)
(4) display alt text in a box, giving precedence to the dimensions of the 
image. (preserve layout, sometimes sacrificing ability to see whole alt text 
without moving the mouse)

Perhaps the prefs page could show one or two examples next to each of the 
radioed items so they can figure out what they're going ot see.

Comment 9

[Hixie (not reading bugmail)]

Those are all very good ideas, and can all be easily implemented if bug 11011 is
fixed. That will probably happen in the 5.1 release.

Comment 10

[Jesse Ruderman]

Don't you think it would hurt Netscape for a non-beta release to display a 
large number of webpages ambiguously (and confusingly) when they are slow, or 
when the user has images turned off?  I'd really like to see this fixed 
sooner.  

How about making the css identifier something like "moz50only-alttext" to 
discourage people from using it in their own style sheets, allowing it to be 
changed quickly to match the CSS3 standard later?

Comment 11

[Hixie (not reading bugmail)]

I strongly agree (although for other reasons) that it would be great for bug 
11011 to be fixed for 5.0's FCS (First Customer Ship). However, I certainly
don't have the time to do it, and Netscape doesn't have the resources to throw
at that particular problem. So unless you are willing to do the work (of find
someone else to do it) then there is not much we can do about _that_.

I still disagree, BTW, that it is _confusing_ to display alt text as it was
intended. Have you ever browsed the web using Lynx? 
   http://lynx.browser.org/

Comment 12

[Doron Rosenberg (IBM)]

back to the bug - I am not seeing this on m16 ngihtly and win98. Can anyone see
this?

Comment 13

[Jesse Ruderman]

Still visible on http://babelfish.altavista.digital.com/

Comment 14

[Doron Rosenberg (IBM)]

so, what shall we do with this bug. Is this a imagelib bug perhaps?

Comment 15

[Hixie (not reading bugmail)]

I'll deal with it. I've got a bunch of these on my plate pending my ALT text 
retargetting work.

Comment 16

[timeless]

changing platform & os [pc/w2000], severity [normal], summary [problems with 
clear.gif and bolt.gif], adding to cc [if you have gripes, use bugzilla].

IMO if you want to check for bad links you should use composer, and one of its 
views should show you that the image file is not found.

Comment 17

[Hixie (not reading bugmail)]

Hm, reopening... Not sure why it was marked REMIND!

From bug 24778, comment by Eric Krock <[e-mail]>:
> Nominating nsbeta2. Supporting ALT well is important for accessibility. There 
> is also legal exposure for AOL under ADA for lack of accessibility. Therefore 
> we should try to do as well as possible for FC for both reasons.

I need to spec the behaviour before all the ALT bugs can be fixed, and to do 
that I need some free time, and that won't happen before June 1st. So, I'll do
it as a top priority on June 1st.

[cc'ing Eric.]

Comment 18

[Michael La Guardia]

putting on nsbeta2+ radar.  Will become minus on 6/15.  We won't be holding the
beta for this.

Comment 19

[Matthew T (active 1999-2002)]

Ok, since Ian hasn't responded by 06-03, I'll just summarize what I've come up 
with, and if Ian hasn't time to do anything more detailed he can just say `yay' 
or `nay' to what I've got.

We need an image placeholder icon of *some* sort, for all sorts of reasons which 
I described in bug 23691 on 04/28. The placeholder should be the traditional
shapes-on-a-page for an unloaded image, a red-cross-on-a-page for an unavailable 
image, and a black-crossed-circle-on-a-page for a blocked/hidden image. (Hiding 
images, as opposed to blocking them, is bug 10723.) However, the icon does not 
need to be as large (32*32) as that traditionally used in Mozilla -- 16*16 is 
probably large enough.

The choice, then, is between an unsized placeholder (an icon with no frame) and a 
sized placeholder (in icon inside a sized bevelled frame, as in 4.x). An unsized 
placeholder would have alt text (or if there was no ALT attribute, filename *with 
suffix*, because we don't know what might or might not be considered a `suffix' 
in future filesystems) shown in-line to the right of the icon. A sized 
placeholder would expand to fit the alt text if it was too small.

Advantages of unsized placeholder (with no frame)
-------------------------------------------------
* Encourages better writing of alt text, as alt text would run directly into
  following content as it should. As I wrote in bug 23691, it would prevent
  authors from `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)'.
* More consistent (between images) display of alt text if the image fails.
  Expanding the frame to show alt text, where necessary, could do even weirder
  stuff to layouts than having no frame at all would. Confining the alt text in a
  rectangular frame would also prevent long alt text from wrapping nicely around
  adjacent boxes -- especially when, one day, we do contoured text around
  non-rectangular objects.
* More consistent (between images) display of alt text while an image is loading,
  for the same reasons as given above.
* Better space conservation. Presumably, half the reason to hide/block images is
  to take back their screen real estate, as well as their bandwidth.
* Helps prevent authors from making the mistake of thinking that they can rely on
  image dimensions for text layout purposes.
* Minimum acceptable size for an image placeholder (so as to get at its context
  menu, or click to load it) would be about 16*16 pixels -- it should never be
  smaller. So for all those 1*1-pixel graphics, the placeholder won't be the same
  size as the image anyway; and if we used the image's size for all images except
  those smaller than 16 pixels in either dimension, we could give a false
  impression about how large those small images were.

Advantages of sized placeholder (with frame)
--------------------------------------------
* Better incremental display if the image loads, which it usually will. We could
  just use a sized placeholder during the loading, and revert to an unsized
  placeholder if the image fails (this is the behavior complained about in bug
  40623); but that could mean a sudden reflow a couple of minutes (!) after
  everything else on the page had completed, when Mozilla gave up on getting any
  response from the image's server. That would be unacceptable. Or we could give
  the image /n/ seconds to show itself in the sized frame, and then revert to an
  unsized frame until/unless the image started to load; but that would probably
  be too messy and force lots of jumpy reflows when an image took a bit longer
  than /n/ seconds to start loading.
* Scrooge scenario: I load a page without images, and see all their sized frames.
  I use the context menu to hide/block those images which, based on their size,
  look Unlikely To Be Useful, and then click the Images button. This scenario
  only works if the frame is sized in the first place.
* Better visual structure, particularly for consistency across a range of pages
  where a graphic in a consistent position on those pages is loaded on some cases
  but not loaded (for whatever reason) in others.
* Better visual differentiation between an unloaded image and a blocked/hidden
  image.

So they both have their advantages, but my pick of the best choice for the Web as 
a whole is for the placeholder with no frame. Standard NISBAP disclaimer (`No, It 
Shouldn't Be A Pref') applies because this is far too obscure for a pref to 
provide any value.

... Ian?

Comment 20

[Hixie (not reading bugmail)]

Thanks for the summary Matthew, I'm now working on my recommended spec.

Comment 21

[Hixie (not reading bugmail)]

Ok, here is my first proposal for the final ALT text implementation's
specification. I would appreciate any comments so that we can iron out any
flaws before we pass this on to the programmers.


Image Settings
--------------

Legacy browsers have offered two options: to download images, or not
to download images.

This proposal suggests the following three modes:

  Always Load Images
    Always downloads and displays images used on web pages, if the
    images are available.

  Load Images On Demand
    Does not download images used on web pages, but reserves some
    space for them. Click on images to download them.

  Don't Load Images
    Does not download images and does not reserve room for them. You
    can still cause important images to be displayed by right-clicking
    on their icon and selecting "Show Image".

For first release, the second mode can be forgotten if that is too
much work. Thus we are left with the first and last modes, as we
already have planned.

There should also be a preference, just like in Lynx, to deal with
badly designed pages:

   [ ] Show icons for _all_ images.

See below for a description of the _implementation_ of this preference. 

Extra time needed: time required to add to the prefs UI, add a new
pref to the preference system, and make Layout aware of the setting.


Alt Texts
---------

If the IMG or INPUT element has an "alt" attribute, then the contents
of that attribute should be used as the alternate text.

Failing that, if either the "height" or "width" attributes equal
either "0" or "1", then the alternate text should be taken to be the
empty string, "".

Otherwise, the alternate text should be the contents of the first of
the following attributes that is present on the IMG or INPUT element:

   title
   name
   id

Experience has shown that the filename is considerably less useful
than would be first thought, and therefore we should ignore it when
inventing the alternate text.

In Mozilla, this has to be implemented in the function called
GetAlternateTextFor.

   http://lxr.mozilla.org/seamonkey/search?string=GetAlternateTextFor

Estimated time for implementation: 2 hours. Should be relatively easy
for a contributor not very familiar with the code to write.


Icons
-----

Alternative text will be prefixed by an icon (as described below). The
icon is chosen from the following list:

  For images that have not been downloaded, use a generic image or
  object icon.

  For images that are known to be broken, use the broken image or
  broken object icon.

In future releases this proposal will introduce:

  For images that have been blocked, a blocked image icon.

  For images that are in a format not supported by Mozilla, an unknown
  format icon.

In the next section, when referring to "an icon", the icon should be
chosen from the list above.


Placeholders
------------

If an image cannot or will not be shown, then:

  For images that have not been downloaded but are about to be, in
  "Always Load Images" (and "Load Images On Demand") mode(s):

    If the "height" and "width" attributes are given, create a
    borderless box with the height and width given (interpret the
    height and width attributes as pixel lengths).

    If there is any alternative text, or if the "show icons for all
    images" pref is enabled, then insert an image icon inside the
    placeholder.

    If there is any alternative text, then insert it after the image
    icon in the placeholder frame.

    If the frame is too small for the icon and/or the alternative text
    then they will be clipped, just like with the CSS declaration
    "overflow:hidden". However, if the "show icons for all images"
    option is selected, then the frame should be enlarged so that the
    image icon is visible.

  For ALL other cases (blocked images, images not downloaded in "Don't
  Load Images" mode, broken images, and unrecognised images):

    Replace the IMG or INPUT frame with an empty inline element.

    If there is any alternative text, or if the "show icons for all
    images" pref is enabled, then insert a text frame containing an
    image icon inside the IMG or INPUT element.

    If there is any alternative text, then insert it after the image
    icon in the text frame.

These IMG and INPUT frames should be treated just like any other frame as far as
style resolution is concerned.

Note that broken and blocked images never take up their size as given
in HTML, and if they are unimportant according to the author (i.e.,
alt="") then they will in fact not be shown at all, unless the "show
icons for all images" pref is selected.

The image-followed-by-alternative-text is equivalent to the
pseudo-CSS3: "content: url(icon) alternative-text;". This is why I say
the image icon should go in the _text_frame_ (internally it very
probably does not in fact).

The icons should be relatively small so as not to disrupt most text
but be easily clickable, for instance 16 pixels by 16 pixels square.

There should never be a sized placeholder frame for an image where we
do not know the size.



Given that, here are some replies to Matthew's comments (which I largely 
agree with):

> * Minimum acceptable size for an image placeholder (so as to get at
> its context menu, or click to load it) would be about 16*16 pixels
> -- it should never be smaller. So for all those 1*1-pixel graphics,
> the placeholder won't be the same size as the image anyway; and if
> we used the image's size for all images except those smaller than 16
> pixels in either dimension, we could give a false impression about
> how large those small images were.

I don't know that we actually _want_ the user to be able to get to
those particular images in the first place... have you thought of the
mess some pages would turn into, if every 1x1 transparent pixel GIF
turned into a 16x16 icon???


> * Better incremental display if the image loads, which it usually
> will. We could just use a sized placeholder during the loading, and
> revert to an unsized placeholder if the image fails (this is the
> behavior complained about in bug 40623); but that could mean a
> sudden reflow a couple of minutes (!) after everything else on the
> page had completed, when Mozilla gave up on getting any response
> from the image's server.

We have that problem anyway with going in the other direction. However
we do it, there is no way we can reliably get the placeholder frame
the right size initially without the "height" and "width" attributes
being known to us.

Might as well go for the solution which gives the least difference
each time. (Sized if we know the size in advance, inline if we don't.)


> * Scrooge scenario: I load a page without images, and see all their
> sized frames. I use the context menu to hide/block those images
> which, based on their size, look Unlikely To Be Useful, and then
> click the Images button. This scenario only works if the frame is
> sized in the first place.

Hopefully my "Load Images On Demand" mode allows this while still leaving the 
option of disabling images completely.

Comment 22

[Hixie (not reading bugmail)]

BTW, this should _not_ be that difficult to implement. 1 or 2 days, spread
over a week or so, should be enough by my own very rough estimation. (I say
spread over a week because it will need QA feedback.)

Comment 23

[Hixie (not reading bugmail)]

Reassigning to default component owner. The spec now exists, see above.
Matthew, please tell me what you think of it as soon as possible...

Comment 24

[Matthew T (active 1999-2002)]

Programmers: go with this, hurry, implement it, we're running out of time for 
nsbeta2. The only *major* objection I have to it is a subtraction, not an 
addition, and subtraction will (I assume) be much easier to do later than 
addition will.

Having said that, Ian, here are my objections ...

* I think offering three modes is a large mistake, because it will have an
  *extremely* low usefulness-to-confusion ratio. As far as image layout is
  concerned (not to be confused with image loading, e.g. blocking), users only
  care about `images off' and `images on'. I can't imagine anyone -- apart from
  Web weenies such as yourself, Alan J Flavell, and (possibly) Tim Berners-Lee --
  being interested in more fine-grained control than that.

  Whether the pref is set to sized (`Load Images on Demand') or unsized (`Don't
  Load Images') frames, it's going to produce undesirable results on some pages.
  We know that. The choice your pref offers (and the choice I was trying to make
  earlier), is whether pages designed around the HTML specs stuff up, or whether
  pages designed around legacy browsers stuff up.

  But if providing a pref (as opposed to just choosing a behavior and running
  with it) is to be worth it, the following series of steps has to regularly
  happen:
  * user sees undesirable layout on a page
  * user knows that layout on pages can be affected by this pref
  * user recognizes that changing the pref will help with the layout on this page
    (a non-trivial cognitive task in itself)
  * user has enough motivation to change the pref (rather than just coping with
    the odd layout, or going to another page)
  * user opens the pref dialog, opens the relevant category, opens the relevant
    subcategory, finds the pref, and changes it
  * user changes pref back to its original setting after leaving page/sub-site/
    /site.

  And I really don't think that's going to happen, not even if the pref is put in
  a highly prominent place in the prefs dialog, with bucketloads of explanatory
  text and bright flashing colors.

  An indication of how useless such a pref would be can be gleaned from your
  difficulty in giving the options appropriate names: `Load Images On Demand' and
  `Don't Load Images' implies that in `Don't Load Images' mode you can't load
  images at all, which is not the case. The simplest accurate and understandable
  labels I could think of would be `Don't load images, but leave space for them
  on the page' and `Don't load images, just show them as an icon', but even that
  is still pretty gobbledygooky.

* I can see the point of `Show icons for _all_ images' in Lynx, but I can't see
  the point of it in Mozilla. In Mozilla showing icons for all unloaded images is
  an order of magnitude more important than it is in Lynx, because Mozilla can't
  get away with assuming that all you want to do with images is show their alt
  text (and occasionally open them in an external viewer).

* Having a special ALT case for images measuring 0 or 1 in one dimension is only
  useful, under your spec, if those same images also happen to have a TITLE,
  NAME, or ID value (in which case those attributes would be ignored instead of
  used). But it's hardly likely that any of these attributes will be present for
  such graphics anyway, is it? Why would I, as a page author, want to give a
  TITLE to a graphic that was practically impossible to hover over anyway? And
  why would I want to manipulate a pixel graphic with JavaScript?

* In deriving alt text from non-ALT attributes, I think ID should come before
  NAME, rather than the other way around, because ID is the standard element
  attribute -- I assume NAME will be deprecated eventually. (Yeah I know, it's a
  trivial point, given that images are unlikely to have both attributes set
  simultaneously ...)

* The reason I said images smaller than 16*16 should still have a 16*16 icon was
  because they fall into the class of images which are Unlikely To Be Useful, so
  the user would often want to get at their icon to block them or hide them. But
  on thinking about it some more, I guess these images are more likely to be
  blocked with a generic rule (based on image dimensions) than on a case-by-case
  basis, so I was wrong there. I guess I wouldn't want a blocked 1*1 image being
  even more annoying (because it had a 16*16 icon) than an unblocked one.

* I still think that image frames should be unsized until they start loading,
  even if we know their WIDTH and HEIGHT; because it is far more acceptable for
  layout to jump around five seconds after the page begins loading (when the
  image starts loading and we give it a sized frame), than it is for the layout
  to stabilize after ten seconds but then jump around two minutes after the page
  begins loading (when the image server times out and we turn its sized frame
  into in-line alt text).

Comment 25

[Jesse Ruderman]

> ... because Mozilla can't get away with assuming that all you want to do with 
> images is show their alt text (and occasionally open them in an external
> viewer).

right on.

> I still think that image frames should be unsized until they start loading,
> even if we know their WIDTH and HEIGHT; because it is far more acceptable for
> layout to jump around five seconds after the page begins loading (when the
> image starts loading and we give it a sized frame), than it is for the layout
> to stabilize after ten seconds but then jump around two minutes after the page
> begins loading (when the image server times out and we turn its sized frame
> into in-line alt text).

I disagree with this point on grounds that images working is much more common 
than images not working, which is in turn more common than images timing out.  
Also, layout would be likely to jump several times as the images load (assuming 
unsized image frames), but it should only jump once when they time out 
(assuming sized image frames).

Comment 26

[Matthew T (active 1999-2002)]

Jesse, I think most of your disagreement would disappear if the suggestion I made 
in bug 17325 (on 1999-11-19) was implemented. But I could be persuaded otherwise.

Comment 27

[Hixie (not reading bugmail)]

> I think offering three modes is a large mistake, because it will
> have an *extremely* low usefulness-to-confusion ratio.

Agreed. I was `forced' into suggesting this pref because of a conflict
between your previous statements and my own views. Since your views
have basically changed (see below), this can be removed altogether.


> `Don't Load Images' [...] The choice your pref offers [...] is
> whether pages designed around the HTML specs stuff up, or whether
> pages designed around legacy browsers stuff up.

It was actually included so that you could use your "Scrooge
scenario": loading a page without images, and then, based on all their
sized frames, using the context menu to hide/block those images which
look Unlikely To Be Useful.

If that is not a high priority, then I am happy to remove the
possibility of doing this since it simplifies everything.

 
> `Show icons for _all_ images' [...] In Mozilla showing icons for all
> unloaded images is an order of magnitude more important than it is
> in Lynx, [...].

This is why I had three prefs:

   1. You want images (graphical browser), 
   2. You want images, but only when you ask for them,
   3. You don't want the images at all (text browser).

There is no way we can have "show icons for all images" enabled by
default (and the only option) -- that would make pages literally
unreadable. If you don't believe me, try browsing the web with the
following in your html.css file:

   img[width="1"]  { padding: 0.5em !important; border: solid red !important; }
   img[width="2"]  { padding: 0.5em !important; border: solid red !important; }
   img[width="3"]  { padding: 0.5em !important; border: solid red !important; }
   img[width="4"]  { padding: 0.5em !important; border: solid red !important; }
   img[width="5"]  { padding: 0.5em !important; border: solid red !important; }
   img[height="1"] { padding: 0.5em !important; border: solid red !important; }
   img[height="2"] { padding: 0.5em !important; border: solid red !important; }
   img[height="3"] { padding: 0.5em !important; border: solid red !important; }
   img[height="4"] { padding: 0.5em !important; border: solid red !important; }
   img[height="5"] { padding: 0.5em !important; border: solid red !important; }

Try, for example, some of the following:
   http://home.netscape.com/ 
   http://www.microsoft.com/ 
   http://www.hp.com/ 
   http://www.ibm.com/
   http://www.bbc.com/

It is extremely nasty. Now, instead of the above lines, insert the following:

   img[width="1"]  { display: none !important; }
   img[width="2"]  { display: none !important; }
   img[width="3"]  { display: none !important; }
   img[width="4"]  { display: none !important; }
   img[width="5"]  { display: none !important; }
   img[height="1"] { display: none !important; }
   img[height="2"] { display: none !important; }
   img[height="3"] { display: none !important; }
   img[height="4"] { display: none !important; }
   img[height="5"] { display: none !important; }

...and try those sites again.

(Note that the above is only a rough approximation of what it would
really feel like, so don't draw too many conclusions from this.)


> Having a special ALT case for images measuring 0 or 1 [should be removed].

Agreed. That was a relic of my spec at a time where I was still
thinking of using the filename to generate the alternate text.

 
> In deriving alt text from non-ALT attributes, I think ID should come
> before NAME, 

Ok.


> I still think that image frames should be unsized until they start
> loading, even if we know their WIDTH and HEIGHT [...].

As David R said, working images are a _lot_ more common than those
that time out. Your way, the page is *guaranteed* to be reflowed. If
we size as much as possible while loading, then only broken and
unsized images will reflow. In fact, doing it this way will encourage
good authoring practice: if authors include height and width on all
their images and make sure they have no broken images, we will have no
reflows whatsoever!

Updated spec coming up...

Comment 28

[Hixie (not reading bugmail)]

New spec for perusal -- please criticise ASAP:
   http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/altspec.txt

Comment 29

[Matthew T (active 1999-2002)]

> There is no way we can have "show icons for all images" enabled by default (and
> the only option) -- that would make pages literally unreadable.

No it wouldn't. Not if, as you suggested in your spec, and as I (eventually) 
agreed, the icons were clipped if the image was less than 16 pixels in either 
direction.

>                                                                 If you don't
> believe me, try browsing the web with the following in your html.css file:

I can't -- see bug 36928. :-/

> As David R said, working images are a _lot_ more common than those that time
> out. Your way, the page is *guaranteed* to be reflowed. If we size as much as
> possible while loading, then only broken and unsized images will reflow. In
> fact, doing it this way will encourage good authoring practice: if authors
> include height and width on all their images and make sure they have no broken
> images, we will have no reflows whatsoever!

Broken images are often not the fault of the author at all: they may be the 
result of server overload (e.g. the Slashdot Effect), unscheduled downtime for an 
external image server, or whatever. And I still don't like the idea of a page 
reflowing minutes after I've loaded it.

A way around this would be to assume that `well, the user wasn't expecting to get 
the alt text for this image anyway', and do a refined legacy-browser-like display 
of alt text (effectively showing it in a scrollable IFRAME in the sized image 
frame) for broken/timed-out images.

But I suspect you'd grate your teeth at the extent to which this broke the HTML 
spec's original intent for ALT text; and since I can't think of a better 
solution, I guess you can have it your way. :-)

Comment 30

[Hixie (not reading bugmail)]

>> There is no way we can have "show icons for all images" enabled by
>> default (and the only option) -- that would make pages literally
>> unreadable.
> No it wouldn't. Not if, as you suggested in your spec, and as I
> (eventually) agreed, the icons were clipped if the image was less
> than 16 pixels in either direction.

According to my spec, that is what will happen when "show icons for
all images" is _disabled_. When it is enabled, I am proposing that
icons be NOT clipped. That's ok, right?


Regarding the case of pages reflowing "minutes" after the original load:
 1. Images timing out is orders of magnitude less likely than images being
    found in good health.
 2. A couple of reflows two minutes after initial load on the occasional page
    is a lot less annoying than a reflow on almost every page, three seconds
    after initial load.
 3. Your refined idea thingy is inconsistent with what would happen if the 
    image was found to be broken straight away, rather than several minutes
    later, and may therefore confuse users even more than a reflow.

My standard IANAUW disclaimer applies (I Am Not A Usability Weenie). :-)

Comment 31

[Hixie (not reading bugmail)]

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

Comment 32

[Hixie (not reading bugmail)]

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

Comment 33

[leger]

Marking Verified as a dup.