[FIX]WRMB: preserve the dimensions of a broken image and do not render |title| attribute as alternative text

VERIFIED FIXED in mozilla0.9.6

Status

()

defect
P3
normal
VERIFIED FIXED
18 years ago
15 years ago

People

(Reporter: waterson, Assigned: attinasi_layout)

Tracking

({compat, testcase, topembed})

Trunk
mozilla0.9.6
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [bugscape: 8601]INVALID/WONTFIX?)

Attachments

(13 attachments, 3 obsolete attachments)

112 bytes, text/html
Details
2.27 KB, patch
Details | Diff | Splinter Review
561 bytes, text/html
Details
4.12 KB, text/html
Details
42.96 KB, text/html
Details
291.18 KB, image/png
Details
101.18 KB, image/jpeg
Details
48.32 KB, image/png
Details
3.79 KB, text/html
Details
3.50 KB, patch
kmcclusk
: review+
waterson
: superreview+
Details | Diff | Splinter Review
18.29 KB, patch
kmcclusk
: review+
waterson
: superreview+
Details | Diff | Splinter Review
747 bytes, patch
Details | Diff | Splinter Review
3.89 KB, text/html
Details
Reporter

Description

18 years ago
This bug filed from Bugscape bug 8601
(http://bugscape.netscape.com/show_bug.cgi?id=8601). The problem is that we're
rendering the |title| attribute's text as the alternative text for an <img> that
is unavailable.
Reporter

Comment 1

18 years ago
Posted file test case
Reporter

Comment 2

18 years ago
hixie: dbaron said you were the guy to talk to about rendering an <img> tag's
alternative text. Can you point me to any juicy bugs? (I'm curious why we don't
render a ``broken'' image, e.g.)
Status: NEW → ASSIGNED
Keywords: testcase, topembed
Priority: -- → P3
Target Milestone: --- → mozilla0.9.5
This bug is INVALID. If the markup doesn't want any alternate text, it should say
alt="". What are the websites in http://bugscape.netscape.com/show_bug.cgi?id=8601?
Keywords: compat
Whiteboard: INVALID/WONTFIX?

Comment 5

18 years ago
no Ian, this is not invalid for a multitude of reasons, removing whiteboard 
entries.
Whiteboard: INVALID/WONTFIX?
Whiteboard: INVALID/WONTFIX?
The original HTML 4.0 REC had the following text:
http://www.w3.org/TR/1998/REC-html40-19980424/appendix/notes.html#altgen
the current HTML 4.01 REC refers to the WAI drafts, and I can't find the
relevant text there.

Comment 7

18 years ago
i know exactly what the spec says, trust me. regardless this needs to be 'fixed'
Whiteboard: INVALID/WONTFIX?

Comment 8

18 years ago
I presume that this is for compatibility only, so is this then a Quirks-mode
only bug (i.e. the fix applies to quirks mode only)?
Whiteboard: INVALID/WONTFIX?

Comment 9

18 years ago
David, Ian and Marc -- yes, this has to do with being compatible with IE and 
should be handled in quirks mode. If my previous answer offended anyone, that 
was not the indent, I prefer short answer instead of long, drawn out 
descriptions

Updated

18 years ago
Whiteboard: INVALID/WONTFIX?
Reporter

Comment 10

18 years ago
Looks like this is really just a dup of some or all of the RFE's in bug 41924.
I'm tempted to mark it as such, since so much discussion on this issue has gone
on there.

Comment 11

18 years ago
Yes Chris, except that if this is somehow 'urgent' (see topembed kwd) then it is
a lot easier to fix than the super-alt-text-bug 41924.

I'm happy to do this if you want me to take it, though it is bound to be
temporary work until bug 41924 is take by the horns, so to speak.
Reporter

Updated

18 years ago
Target Milestone: mozilla0.9.5 → mozilla0.9.6

Comment 14

18 years ago
I attached a simple patch to prevent using the TITLE attribute when no ALT
attribute is found, in Quirks mode only of course. ...Might be worth looking at...
beppe: Do NOT remove my status whiteboard markings. That is a blatant breach of
Bugzilla etiquette.

It's all very well saying that this bug is "topembed" -- just because it has some
magic keywords does not make this a valid bug. As I asked above, please give us
the URIs for the pages that this "breaks".

You say that this is not invalid "for a multitude of reasons", but have not given
a single one. I am still under AOL NDA, if your multitude of reasons are all 
confidential then please e-mail them to me.
Whiteboard: INVALID/WONTFIX?

Updated

18 years ago
Whiteboard: INVALID/WONTFIX? → [bugscape: 8601]INVALID/WONTFIX?

Updated

18 years ago
Blocks: 64833

Comment 17

18 years ago
Actually, this is not an invalid request.
The referenced section is from David Baron was from the 4.0 spec and not the 
current 4.01 spec, that would be an obsoleted reference:
http://www.w3.org/TR/1998/REC-html40-19980424/appendix/notes.html#altgen -- 

the current, valid reference is this:
http://www.w3.org/TR/html401/appendix/notes.html#accessibility

That would lead you to: 
http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/#gl-provide-equivalents

Following the link to the techniques:
http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-text-equivalent

Where you would end up at:
http://www.w3.org/TR/WCAG10-HTML-TECHS/#image-text-equivalent -- section 7.1

Through all of the WAI documents, it is not suggested that 'the title attribute 
should be used', in fact the title attribute is not mentioned.

In addition, section 13.8 
(http://www.w3.org/TR/html401/struct/objects.html#visual) directs you to the 
accessibilty guideline
Do the WAI drafts describe a clear procedure that we *should* follow?

Comment 19

18 years ago
I have been scanning through the Web Content guidelines and the UA guidelines, 
and neither provide a process. Since a process is not defined, then that would 
lead me back to the 4.01 spec. The 4.01 spec does not suggest using title as an 
alternative to the alternative text.

Comment 20

18 years ago
Taking this bug. I will be working on bug 41924 and will take this bug into
account when working on that one. My assumption is that this bug only adds the
idea that the |title| attribute should not be used for alt text, but I think the
more important aspects are the preservation of the geometry when a width and
height are specified for the image (and a visual indication like a broken image
icon).
Assignee: waterson → attinasi
Status: ASSIGNED → NEW
Depends on: alttext

Comment 21

18 years ago
I agree w/ Marc. The dims of the image should be preserved. If this is quirks
mode, can add the preservation of the dims (add a broken image too?) to this patch?

Comment 22

18 years ago
I have this pretty much resolved now. Here is the status:

* sized images will display the ALT text (or Title if no ALT text) in a box that
is sized correctly. Alt text is clipped.
* unsized or incompletly sized images will not get a box: the alt text is simply
displayed inline.
* an icon will be displayed for broken and loading images that have a size.
* if the icon cannot be found, a simple colored DOT is painted (green for
loading, red for broken).

Still to do:
* I need a valid GIFs for the loading and broken image icons. Currently I am
using a random image I found in the chrome, but I need a nice 16 X 16 image for
each. Any artists out there ;)
* more testing. Specifically, turning OFF image loading does not seem to work,
which I believe is a bug in the imageLib, so testing is more tedius.
* checkin icons, makefiles for the images, and the changed files (soon to be
attached).
Assignee: attinasi → attinasi_layout
Summary: WRMB do not render |title| attribute is alternative text for <img> → WRMB: preserve the dimensions of a broken image and do not render |title| attribute as alternative text

Comment 24

18 years ago
Posted patch frame constructor changes (obsolete) — Splinter Review

Updated

18 years ago
Blocks: 106958

Comment 26

18 years ago
Never mind that patch. It was allocating and loading the broken image and 
loading image icons on each instance.

I have a new version that uses a singleton object to maintain a single pair of 
icons. Unfortunately, the singleton is destroyed if there are no image frames in 
existance... I need to see if this impacts load time, or if there are enough 
image frames around to keep the singleton alive.
Status: NEW → ASSIGNED

Comment 27

18 years ago
This seems to be right on IMO.

Updated

18 years ago
Depends on: 108538

Comment 28

18 years ago
Comment on attachment 56331 [details] [diff] [review]
image frame changes - need more testing

obsolet patch: new one coming up
Attachment #56331 - Attachment is obsolete: true

Comment 30

18 years ago
Seeking reviews for patches to ImageFrame and FrameConstructor.

Bug 108538 has been opened as a request for artwork (for the icons). In the
patch, temporary icons have been used (emoticons from the editor).

Updated

18 years ago
Summary: WRMB: preserve the dimensions of a broken image and do not render |title| attribute as alternative text → [FIX]WRMB: preserve the dimensions of a broken image and do not render |title| attribute as alternative text
Whiteboard: [bugscape: 8601]INVALID/WONTFIX? → [bugscape: 8601]INVALID/WONTFIX? | waiting for reviews

Updated

18 years ago
Keywords: edt0.9.4

Comment 31

18 years ago
is this bug really blocked by 41924, or is 41924 a dupe of this at this point?

Comment 32

18 years ago
It is a dup now, but there are still a couple of points in bug 41924 not covered
here, so it may stay open. Removing the dependency. I'll update bug 41924 as well.
No longer depends on: alttext

Comment 33

18 years ago
Hixie told me that the spec says that we arn't supposed to do the stuff that
this patch adds.  Depending on this, the broken icon may not be the correct
behavior.  I personally don't care one way ot the other, but I believe the old
broken icon we have is ugly and we should get a new one if we are going to do this.

I don't believe we should have a placeholder icon for loading.  This will slow
down (probably minor) page loads and it doesn't really give us anything useful.
 IE has this "feature" off by default, and I think it is just ugly and disruptive.

Comment 34

18 years ago
I believe we need to come to an agreement on the validity of this bug before any
further steps are taken.
As I have already said in this bug (twice), this bug is not valid. I shall, 
once again, ask for the people in favour of changing our behaviour to please 
give us the URIs for the pages that we "break".
 
Comments above say that this is not invalid "for a multitude of reasons", but 
nobody has given a single one. I am still under AOL NDA, if the multitude of 
reasons are all confidential then please e-mail them to me (ian@hixie.ch).
 
Please read http://www.hixie.ch/advocacy/alttext
 
The bug covering what must be done to improve our alt text support is bug 
41924. That bug contains a detailed spec explaining when a placeholder frame
should be used.

My personal opinion is as follows:
   1. I don't mind if we drop the use of the "title" attribute as I don't
      expect it to make much difference in quirks mode documents and strict
      mode documents should all have "alt" attributes anyway,
   2. Broken images should never have fixed size placeholder frames (see the
      spec in bug 41924 for details).

Taking QA as this is an alt text issue and I am the alt text QA contact.
QA Contact: petersen → ian
Reporter

Comment 36

18 years ago
Make this be |static| (as well as |inline|), so that the compiler doesn't
generate an external reference for it. Also, couldn't this just _return_ a PRBool?

-static void HaveFixedSize(const nsHTMLReflowState& aReflowState, PRPackedBool&
aConstrainedSize);
+inline void HaveFixedSize(const nsHTMLReflowState& aReflowState, PRBool&
aConstrainedSize)


pavlov: did you actually _look_ at the icons he chose? ;-)

Anyway, the patch looks fine to me, sr=waterson.
QA Contact: ian → petersen
*** Bug 108576 has been marked as a duplicate of this bug. ***

Comment 38

18 years ago
ok, the failed image is good...

The only part of this patch I have a problem with (aside from the spec, which I
don't really understand (or want to understand)) is the loading image icon.  I
really don't think we should waste time displaying an icon saying that we are
loading.

If you remove the loading icon, and come to some agreement with hixie on if the
alt text handling part of this patch is correct, I will review it.

Comment 39

18 years ago
Thanks for all of the feedback ;)

** Pavlov - The reason for the icon during the load is found in Ian's alttext
document (http://www.hixie.ch/specs/alttext), snipped here:

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" mode:

    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).

    Insert an image icon inside the placeholder (regardless of the
    existence of any alternative text).

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

I guess we could make it an option / pref. It should not slow loading because
the image is tiny and cached.

** Hixie - 

>2. Broken images should never have fixed size placeholder frames (see the
>      spec in bug 41924 for details).

I read your spec but I don't know why you think that this is the correct way to
handle broken images. It seems to mess up lots of web page layout when I surf
with images turned OFF, and it makes composer a bitch when images are missing /
changed.

>Comments above say that this is not invalid "for a multitude of reasons", but 
>nobody has given a single one. I am still under AOL NDA, if the multitude of 
>reasons are all confidential then please e-mail them to me (ian@hixie.ch).

That was beppe's comment, she can provider her reasons. I am fixing this for two
reasons: 1) it is important to preserve the layout for missing images that have
width and height specified, see the comments in the realated bug 41924, and 2)
we have some internal requirements, such as in mail and composer, to show the
image even if it is broken.

>My personal opinion is as follows:
>   1. I don't mind if we drop the use of the "title" attribute as I don't
>      expect it to make much difference in quirks mode documents and strict
>      mode documents should all have "alt" attributes anyway,
>   2. Broken images should never have fixed size placeholder frames (see the
>      spec in bug 41924 for details).

I do not care in the least about the TITLE attribute, in fact in my patch it is
still there. But, I disagree with point 2 and I think that we must preserve the
size of broken images if we can, for reasons I have already stated. I think that
the border helps too, but I also think that in 'do not show images' mode the
border could probably be dropped. Again, what spec is this violating? Is it
acceptable in Quirks Mode?

** Chris - thanks for the sr! I'll incorporate your comments.

Please note: note that this TOPEMBED bug originated from a Bugscape bug, and
understand the position that puts one in :)
> it is important to preserve the layout for missing images that have
> width and height specified

No, it's not. From http://www.hixie.ch/advocacy/alttext :

: Argument number #1: 
: > The essential aspect of an image is its area.
: 
: The essential aspect of an image is _not_ its area; it is its meaning.
: That the information is in graphical format is _not_ (usually)
: essential. (One possible exception to this rule would be optical
: illusions -- there, the graphical form of the meaning is indeed very
: much essential.)

: Argument number #5: 
: > If, in this example, when the image failed to load, that ALT text
: > were placed in a box whose size was defined by the height and width
: > attributes, it would retain its semantic identity and provide a cue
: > that the entire content of the webpage is not at present available.
: > If that same ALT text were to appear inline with the same display
: > properties as the surrounding text, it could confuse.
: 
: The reader of the page frankly couldn't care less if the author has
: made a mistake and the page is not completely available. The reader
: wants the information. So if an image is not available, the page
: should adapt. This is what alt text is designed to do.

: Argument number #8:
: > How about if we did display ALT text (and if there is none, title,
: > name, or filename), but always in a box the size of the image (if
: > WIDTH and HEIGHT attributes are given). That way: (1) we'd always be
: > displaying ALT text (maybe make sure that the entire text is visible
: > by adding tooltips), (2) wouldn't have to worry about special cases,
: > and (3) wouldn't break any page layout (if images can't load or
: > image loading is turned off).
: 
: This misses the fundamental point: that HTML is *NOT* about "page
: layout". If the page doesn't look like the author intended, then THAT
: IS WHAT IS HAPPENING ANYWAY if, e.g., fonts have been changed, there
: is a user stylesheet, author colours have been disabled, the browser
: is not graphical, the page is going through a sadistic firewall, or
: any number of other possibilities.
: 
: If the image is a decorative graphic, then we can drop it altogether
: (this should be the alt="" case, but some heuristics may be needed to
: work out when an image is just decorative or used for layout, if it is
: missing the alt attribute). If the image is not decorative, and is in
: fact informative, then it should have a textual equivalent in the form
: of its alt text, and that is what we should show (or a synthesised
: version, e.g. from the filename or the title attribute).
: 
: As has been previously mentioned, the important aspect of the page is
: not its layout, it is its content. If images are disabled, and a page
: relies on images for layout, then that's ok: forget the layout
: altogether, and simply draw the remaining text.


> we have some internal requirements, such as in mail and composer, to show 
> the image even if it is broken.

Then mail and composer should send layout into a mode to show the image frames.
Mail and composer requirements must not be used to compromise our browser's 
rendering engine.


> Please note: note that this TOPEMBED bug originated from a Bugscape bug, and
> understand the position that puts one in :)

I understand fully the position that puts you in -- namely, you are being asked
to change the Mozilla source code because a broken web site (which STILL hasn't
been mentioned in this bug) is pointing to images that do not exist or are 
corrupted. If someone would just tell us exactly WHICH website is forcing us to
consider making these compromises, I could contact them to offer my help in
fixing their problems.


Pavlov: the reason to have an icon when images are loading is so that you know
what to right click on to pick "block images from this server".
Reporter

Comment 41

18 years ago
Hixie: the topembed bug in question has to do with CS/Gecko not rendering a page
properly that has been sent as an email attachment. In this case, the images
were present in the original document (``as the author intended''), but the page
has been taken out of context, and the images are no longer accessible to the
user-agent. This could happen in a number of cases; for example, if a web page
refers to an image on another server that is temporarily unaccessible, if the
images are dynamically generated and the user-agent is off-line, if the server
is extremely busy and some of the connections get dropped or time-out. Anyway,
my sr= stands: de facto standards trump one-off advocacy and underspecified
specfications any day, as far as I'm concerned.

marc: as I sent in a private email, I was wrong about |inline| and external
references. (But still, change the routine to return a PRBool!)

Comment 42

18 years ago
Argument 8 is the only one that resonates with me, and I do not think that your
answer to it is very persuasive.

: Argument number #8:
: > How about if we did display ALT text (and if there is none, title,
: > name, or filename), but always in a box the size of the image (if
: > WIDTH and HEIGHT attributes are given). That way: (1) we'd always be
: > displaying ALT text (maybe make sure that the entire text is visible
: > by adding tooltips), (2) wouldn't have to worry about special cases,
: > and (3) wouldn't break any page layout (if images can't load or
: > image loading is turned off).
: 
: This misses the fundamental point: that HTML is *NOT* about "page
: layout". If the page doesn't look like the author intended, then THAT
: IS WHAT IS HAPPENING ANYWAY if, e.g., fonts have been changed, there
: is a user stylesheet, author colours have been disabled, the browser
: is not graphical, the page is going through a sadistic firewall, or
: any number of other possibilities.

* First, even if HTML is not about layout, pages are written to be visually
appealing, and to that extent layout matters - a lot. I would even go so far as
to say that as much effort is put into page layout (eg. visual appeal) as is put
into page content.
* Second, though it is true that a page can be made to look very different than
how an author intended it, it is also true that in some cases it does not have
to. This is one of those cases - just because a user has turned off images does
not mean that the layout of the page has to be wrecked. Just because I can put 
  '* {display:block;}' 
in a user stylesheet to wreck 99% of web page layout does not mean that honoring
width and height on broken or blocked image is wrong.
 
For just a moment I'd like to turn this around and ask "What is the drawback to
honoring the dimensions of a sized image when the image is not found or is
blocked?" In other words, how is honoring the width and height of a blocked or
broken image going to "compromise our browser's rendering engine"?

Though I have not yet seen mention of a ratified spec related to this, I accept
that your well thought out specification has value and is good, even if I
disagree with some minor parts of it. On the other side of the argument we have
current practice to contend with. Both Nav and IE honor the width and height for
missing (or blocked) images. So at least for Quirks mode I think that Mozilla
should too, to comply with current (and old) standard practice.

Does this sound OK? Are there any other issues remaining besides the honoring of
the width and height on sized images?
> What is the drawback to honoring the dimensions of a sized image when the 
> image is not found or is blocked?  In other words, how is honoring the width 
> and height of a blocked or broken image going to "compromise our browser's 
> rendering engine"?

Here is an example of some well written HTML:

   <h2>The Foo Flower</h2>
   <p><img src="flower.jpeg" height="100" width="40"
           alt="The foo flower has five golden petals, with a beautiful
                tall bright green stem. The stem has two leaves, one about
                one third of the way up, on the right, and one two thirds
                of the way up, on the left. The leaves are a darker shade
                of green, and appear to be thick and velvetty." /></p>

Paste that into your build with your changes (or on IE) and then try it in
a current build or in Lynx.

Also, take a look at argument #3 of http://www.hixie.ch/advocacy/alttext -- I
didn't paste it in above because the reply to that point is rather long.

Comment 44

18 years ago
It amazes me that badly written pages can force a browser to change how it
handles HTML spec.

* If a page is broken - author is the one to be blamed, not the browser for how
it displays it. Especially if it displays it in the way that the spec has intended.
* If I block images from a site - I don't want them. I don't even want any ugly
reminders of them in form of huge empty boxes. I wanna get rid of them, not
replace them with whole lotta empty space.

It's interesting how people are afraid to provide something different to what
user would expect.

First time I saw Mozilla stop keeping those image boxes - it was weird. It was
alien! Time has passed and now I LOVE it. Instead of seeing all those ugly
boxes, Mozilla provides in a presentable way whatever content is left from the
page and I absolutely love it. If I can't see an image - I absolutely don't care
what size it was. If a site relies on images for layout and all images are
broken - I'm not interested in seeing their boxes what so ever. If I can't see
the site in the way the author wanted me to - to hell with that layout! All I'm
interested in is quickly finding some meaningfull link that would lead me to
where I'm going to and away from this broken page, and Mozilla actually makes
this job easier by collapsing all that empty space and presenting me with what I
can actually work with, not with what I could of worked with if the site was not
wrecked.

As I understand the 2 main reasons for doing this are:
1. Breaks layout of a site.
2. Not wanting to be different from other browsers.

Well if the page is a wreck already - keeping layout of what it could of been
just doesn't achieve anything. It actually accentuates what's wrong with the
page, instead of trying to concentrate on what's right.

Different, doesn't nessesarily means worse.


Also I think using a term "broken image" is actually inapropriate. I think we
shouldn't call absence of image - a "broken image". Broken page - fine, there's
something left over. But if there's no image, that's what it is - absence of image.

So now if we call things by their name: You want to replace absence of image
with a broken image + alt text, instad of simply replacing it with alt text.

If you put it that way, it does sound kinnda weird.
And the "preserve dimensions", yadda-yadda, are just technical terms for for it.
Reporter

Comment 45

18 years ago
...and for some _real_ nonsense, give that <img> tag an |align="right"|
attribute so that the inline text gets jumbled up with the flow! Hixie, that
example is _really_ stretching. Why are we fighting the web here?

Comment 46

18 years ago
What I meant to say above is that term "broken image" is more apropriate for
that thing you want to replace it with, than for absence of image. :o)
waterson: If you float the image, the 'display' property becomes 'block' (or 
block based) and thus the height and width properties (derivied from the 
attributes) take effect as you would expect.
> Why are we fighting the web here?

Because the web is wrong. The current browsers give the impression to authors
that HTML is a layout language, that they can control what the user gets. They
can't. They shouldn't. Mozilla has, in the past, focussed on giving the user the
best experience. When an image is missing, the user doesn't care about it -- he
just wants the image replaced with an equivalent alternative (ideally the alt
text). The size of the image becomes irrelevant.
Reporter

Comment 49

18 years ago
The web is neither right nor wrong. The web is. Deal.

Seriously, people complain that pages look like crap in real-world situations
where images are not accessible from the user-agent.
The pages will look like crap either way. If we do the right thing (as we are
currently doing most of the time) then well designed pages will look ok and
badly designed pages will look like crap. If we do as this bug proposes, all
pages will look crap, however they are designed.

                             | As now     | As this bug suggests
   --------------------------+------------+-------------------------
   Well designed page        | looks ok   | looks crap
   --------------------------+------------+-------------------------
   Badly designed page       | looks crap | looks crap

Ergo the only way to get any pages to look ok is to do what we do now (modulo
the known issues listed in bug 41924).
jag brought up an interesting point, btw -- the <object> element avoids this
entire issue by unambiguously saying that if it cannot be rendered it should be
replaced by its contents. The HTML working group consider the <object> element
to be a better solution than the <img> element.

I think this should be used as a good indicator as to what the HTML working
group intend for images' alternate text.
Reporter

Comment 52

18 years ago
Wrong. It's not the web page's fault that some crappy mail program sent it
without fixing up the links to be absolute URLs. It's not the web page's fault
that it refers to an image on a different server that's not accessible for some
reason or another. It's not the web page's fault that it's served from a host
without enough bandwidth, and that the connection got dropped.

In such cases, we ought to give a best-effort to preserve the layout of the page
as the author intended. And, because of the way that graphical user agents have
been implemented since 1994 or so, that means that we ought to preserve the
dimensions of the image, displaying as much of the alternate text that will fit
in to that box.
Reporter

Comment 53

18 years ago
Fine: all ye clever HTML authors who want to describe the velvetty flower inline
use an <object src="velvet.png">All my alternate text here</object>. In the
meantime, all those old luddites using the <img> tag can get the behavior they
expect.

Comment 54

18 years ago
I don't think authors actually expect their pages to be broken when they design
them (except for those few clever ones).
Users are the ones who expect particular behaviour from a broken page. Why not
present them with a better alternative?
> Wrong. It's not the web page's fault that some crappy mail program sent it
> without fixing up the links to be absolute URLs. 

But it is the page author's fault that the page is missing suitable alternate
text. Can you give me an example of a page that looks bad because of our
handling of missing images? (Note that pages that have incorrect alternate text
and therefore do not work with images disabled are not valid examples here:
those pages are not going to be of much use anyway if the images are broken.)


> In such cases, we ought to give a best-effort to preserve the layout of the 
> page as the author intended

In such cases, we ought to give a best-effort to preserve the MEANING of the
page as the author intended. Most of the time the user is not looking at the
page because the layout is supposedly wonderful -- he is looking at the page
because it contains information he wants to learn. The layout is secondary.


> And, because of the way that graphical user agents have been implemented 
> since 1994 or so, 

Legacy user agents have many bugs, do you propose we emulate all of them?
(Actually I would not be surprised if I heard a "yes" to this question given the
number of WRMBs I have seen filed recently.)


> Fine: all ye clever HTML authors who want to describe the velvetty flower 
> inline use an <object src="velvet.png">All my alternate text here</object>. 

There are other issues that make <object> less desirable to authors than <img>,
including (unfortunately) lack of wide spread support.
Reporter

Comment 57

18 years ago
Anyway, I'm not going to argue about this anymore. It's clear there is religion
here that I don't understand. My sr= stands.
Actually that page did change my opinion on one thing. I think the original bug
mentioned here may in fact be valid, and we should drop our use of the title 
attribute if 'alt' is missing, instead just defaulting to alt="". (dbaron?)
Reporter

Comment 60

18 years ago
Posted image yup.
I suspect that the problem here is that Mozilla renders the title attribute when
it shouldn't, not the lack of broken image icons with sized frames.
Reporter

Comment 62

18 years ago
Comment on attachment 56578 [details] [diff] [review]
ImageFrame changes: supports loading and broken image icons and displaying alt text in size-constrined image frames that cannot/will not load

sr=waterson, in case there was any doubt.
Attachment #56578 - Flags: superreview+
Reporter

Comment 64

18 years ago
(By the way, I'm fine with the solution suggested here -- or was it in the 
other bug -- that we do this broken-image-image stuff in quirks mode only. You 
can throw all the goofy behavior you want at people who claim to write 
standards-compliant HTML.)
So on this one page I actually found the lack of placeholder borders ("frames")
to result in a more legible page, since there aren't any funny white patches,
leaving more room for the text to flow, resulting in longer runs of text and a
shorter page. Of course, that really says something about the original page with
images, too.
Heh, I was already under the impression that if we'd go with this fix it would
be quirks only.

Comment 67

18 years ago
Why assume this is quirk behavior? Is there some spec somewhere that indicates
the standard way to do this? That's the part that still gets me - there is no
standard for this, so how can we argue that one way is 'right' and one is
'wrong'? We just have personal preferences and the de facto standard that is
represented by 95+% of the user agents.

Anyway, in the name of flexibility and in hopes of pleasing the 'inliners' and
the 'sized-boxers' I propose the following: render the alt text in a sized box if:
* the image has a fixed size
* is in a Quirks Mode document
* there is no pref set to force inline alt text 

(NOTE: that pref front-end will have to be setup later - it is not part of the
initial patch I plan on landing, but the routine to control this will support
it). This way those who like to see the alt text inline with the rest of the
document can click a checkbox or edit pref files, and the rest of the world will
get the same behavior they have come to expect since the late 1900's. In
addition, I will prevent the TITLE from being used in QuirksMode - when the
standard is clear we can decide for standard mode.

If this is cool, I'll update the patch and seek the still needed review. If not,
then, well, shit, I'll probably just do whatever I want to and stop reading
email for a month ;)
Given the suggestion that we stop using the title attribute for alternate text
in all modes (the original bug filed here, which I was originally against but
in the light of new evidence support), could the people in favour of changing 
Mozilla's placeholder dimensions behaviour please show pages that look better
with that change implemented?

Waterson's example, as jag points out, looks better if we handle it as now
except for the title attriute handling.

Comment 69

18 years ago
Example of page that looks better if dimensions are enforced on "broken images":
http://origin2.the-i-pa.com/mozex.php
The "unbroken" version of this page is here:
http://www.redstonehighlands.org/html/pictures.php

Comment 71

18 years ago
Compare the (admittedly academic) testcase at
http://bugzilla.mozilla.org/attachment.cgi?id=56728&action=view
between Mozilla without this change and Mozilla with it (or IE, if you have not
applied the patches).

The sized images have lots of alt text, and not honoring the image dimensions
means that the inline alt text will spill all over surrounding positioned
images, which themselves have too much alt text and spill over other 'images'. 

Honoring and showing the image box is just as important as what we do with the
TITLE attribute, more actually, since constraining the ALT text to the image's
dimensions makes the source of the alternate text less important *to the
layout*. As to what is better for the *content* of the alternate text, I have no
strong opinion, except that authors probably expect the TITLE to NOT be used
(since neither Nav or IE use it), so we should drop it and just use the ALT
attribute.

If the proposed 'inline' handling of the ALT text were to become part of a
specification then it would be a lot more compelling of a solution (since other
browsers would probably implement it as well, and authors and users would start
to expect the behavior). For now, lacking a spec, the more compelling arguments
are for compatibility with dominant UAs.  That said, I offer up the pref and
Quirks mode restriction in hope of pleasing both the average user and the
standards mongers. 

I cannot argue this forever - there are difference of opinion, a reasonable but
non-sanctioned specification, and the legacy behavior to contend with - it is
somewhat of a religious battle. I'll attach a new patch that checks for
QuirksMode, ignores the TITLE attribute and supports a pref for forcing inline
alternate text.
Yep, an author who had written such a page would be advised to add one of the
following lines to his CSS:

   img[align] { overflow: hidden; }

...or

   img[align] { height: auto; }

Note that if Mozilla implements the placeholder dimension-related changes
mentioned on this bug, the author will lose this level of control.

As far as quirks mode is concerned: I am not going to stop changes to quirks
mode. But as I mentioned on bug 41924, I think that is a poor compromise: I am
getting more and more concerned as to the number of differences (especially
undocumented differences) between standard mode and quirks mode. I personally
think we should be reducing the differences, not increasing them. Especially
since in this case I personally believe that real world pages look _worse_ with
the suggested change, whatever mode we're in.

Comment 73

18 years ago
The proposed rules:
>img[align] { overflow: hidden; }
>...or
>img[align] { height: auto; }

do nothing to help the non-aligned images that now spill over the positioned
images. I guess I could use 'IMG {overflow:hidden;}' but that is a pretty
counter-intuitive solution. Besides, it is hardly my desire to tell page authors
to change their page when every other browser does what they expect AND there is
no specification to quote in support of our implementation.
>Note that if Mozilla implements the placeholder dimension-related changes
>mentioned on this bug, the author will lose this level of control.
Why?

> I am getting more and more concerned as to the number of differences
>(especially undocumented differences) between standard mode and quirks mode.
Yes, me too. These differences correspond to the seperation between what the
standards say we should do and what users expect, based largely on the way that
the dominant browsers act. This seperation is large, and as we try to gain
market share we need to lean more away from a focus on standards and more toward
a focus on adoption. Once we regain some market sharte we will be in a much
better position to lean back toward standards, IMO. In this case, I might say
that there is no need to bother with a Quirks vs. Standards implementation as
there is *no standard* to implement. On the other hand, I want to promote
consensus between those who want compatibility with the _de facto_ standards and
those who do not care about legacy behavour, and the use of Quirks Mode and the
Pref should do that, I hope.

Comment 74

18 years ago
Comment on attachment 56332 [details] [diff] [review]
frame constructor changes

new patch coming...
Attachment #56332 - Attachment is obsolete: true

Comment 75

18 years ago
Comment on attachment 56578 [details] [diff] [review]
ImageFrame changes: supports loading and broken image icons and displaying alt text in size-constrined image frames that cannot/will not load

new patch coming...
Attachment #56578 - Attachment is obsolete: true

Comment 78

18 years ago
New patches attached. Restricts the change to QuirksMode docs, and allows a pref
to override the sized-box representation of the ALT text:

   pref("browser.display.force_inline_alttext", false);

Anyone care to review it?
Could we add this pref to all.js as part of this patch with a comment explaining
what it does?
Do we really want to fork this much code between standards mode and quirks mode?
 What will end up happening is that the standards mode code won't work right,
and we'll just discourage people from triggering standards mode.  (Remember our
standards mode form controls, and how broken they turned out to be when they
were turned on for all modes?)  I'd think if we do this, we should do it in all
modes.
Reporter

Comment 81

18 years ago
Comment on attachment 56758 [details] [diff] [review]
Changes to CSSFrameConstructor: export (as static) the GetAlternateTextFor method, and stop using TITLE attribute in that method

sr=waterson
Attachment #56758 - Flags: superreview+
Reporter

Comment 82

18 years ago
Comment on attachment 56760 [details] [diff] [review]
ImageFrame changes: incorporating waterson's comments, and added check for Quirks Mode and a pref to force inline alt text.

sr=waterson
Attachment #56760 - Flags: superreview+
> The proposed rules:
>
>> img[align] { overflow: hidden; }
>> ...or
>> img[align] { height: auto; }
>
> do nothing to help the non-aligned images that now spill over the positioned
> images.

That's a problem anyway, whether the images are broken or not.


> I guess I could use 'IMG {overflow:hidden;}' but that is a pretty
> counter-intuitive solution. Besides, it is hardly my desire to tell page 
> authors to change their page when every other browser does what they expect 
> AND there is no specification to quote in support of our implementation.

Well. An alternative (one that I would not be opposed to, actually) is to
implement bug 11011 and then do what this bug describes using exclusivly CSS
rules in html.css (and/or quirk.css).


>> Note that if Mozilla implements the placeholder dimension-related changes
>> mentioned on this bug, the author will lose this level of control.
> Why?

How, with your patch, would you get the behaviour that I am advocating?


> Yes, me too. These differences correspond to the seperation between what the
> standards say we should do and what users expect, based largely on the way 
> that the dominant browsers act. This seperation is large, and as we try to 
> gain market share we need to lean more away from a focus on standards and 
> more toward a focus on adoption.

I am not convinced that we need to become less standard compliant to be adopted.
Our UI and general sluggishness are significantly more important.


> Once we regain some market share we will be in a much better position to 
> lean back toward standards, IMO.

I don't believe that. If Gecko-based products ever gain 90% market share, the
legacy-behaviour supporters will be saying that we have to be backwards-
compatible instead of saying we have to be compatible with the market leader.

And I have good reason to be sceptical: Do you see Microsoft massively improving
their standards compliance?


> there is *no standard* to implement. 

The HTML spec is not very explicit about this, I'll grant you that. However I
believe the spirit of the spec is clear. The word "alt" in the name of the
attribute stands for *alternate*, not "text you would like to put in a box the
size of the image".


> On the other hand, I want to promote consensus between those who want 
> compatibility with the _de facto_ standards 

I don't suppose that I can quote Lynx for a precendent, right? How about
Netscape 6.0, 6.1 and 6.2? :-)

Comment 85

18 years ago
Boris, I added the default and a comment - thanks.

David, I would prefer to do this in all modes, but the Quirk-check was added to
build consensus. I would personally prefer to do the sized-box in all modes, and
just use the pref to force the inline behavior.
Ian:
>That's a problem anyway, whether the images are broken or not.
No it is not. If the image is not broken, it takes up a rect of the size
specified by the author. If the image is broken and we do not honor the rect,
then it takes up whatever the alt text needs in flow, and that will in some
cases overwrite other, positioned, elements that are not overlapped by the
size-constrained image. Basically, the image is one size, the alt text is
another - there will be cases where there are problems.

>How, with your patch, would you get the behaviour that I am advocating?
If you mean the inline-alt-text behaviour, I would set the pref in all.js, but I
would not want that behaviour. Alternatively, I might consider NOT specifying
the width and height on the image...

>I am not convinced that we need to become less standard compliant to be adopted.
>Our UI and general sluggishness are significantly more important.
This is opinion, and others hold different opinions. Think about it, different
clients have different needs, different users have different expectations,
different Gecko-based products have different performance characteristics.

>I don't believe that. [...]
OK, as I indicated, that was just my opinion and has little bearing on this
discussion. You might be correct in your skepticism, but look as well at how
much more leverage MS has now that they are the market leader - they can drop
things like NS Plugins in favour of their own technology, something they could
never do when they were playing catch-up.

>The HTML spec is not very explicit about this...
Not very explicit? It says nothing about how to layout the ALT text
(http://www.w3.org/TR/html401/struct/objects.html#h-13.8).

>The word "alt" in the name of the attribute stands for *alternate*, not "text
>you would like to put in a box the size of the image".
Are you sure? You seem to be able to infer a lot from the word "alternate", and
anyway, it is merely conjecture. My conjecture is that ALT stands for 'Alternate
Text' which is to be presented in place of the image (note the lack of layout
constraint in that interpretation).

Updated

18 years ago
Whiteboard: [bugscape: 8601]INVALID/WONTFIX? | waiting for reviews → [bugscape: 8601]INVALID/WONTFIX? | have SR, need R
Comment on attachment 56758 [details] [diff] [review]
Changes to CSSFrameConstructor: export (as static) the GetAlternateTextFor method, and stop using TITLE attribute in that method

r=kmcclusk@netscape.com
Attachment #56758 - Flags: review+
Comment on attachment 56760 [details] [diff] [review]
ImageFrame changes: incorporating waterson's comments, and added check for Quirks Mode and a pref to force inline alt text.

r=kmcclusk@netscape.com
Attachment #56760 - Flags: review+

Comment 88

18 years ago
Patches checked in to trunk. Still need to update the image icons, opening new
bug for that.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Whiteboard: [bugscape: 8601]INVALID/WONTFIX? | have SR, need R → [bugscape: 8601]INVALID/WONTFIX?
Note that bug 41924 also exists on this issue.

Comment 90

18 years ago
Bug 108799 opened for the icon issue.

Yes, 41924 is now _the_ [META] ALT text bug.

Comment 91

18 years ago
Gee Ian, most of your statements are so bogus I don't even know where to start.

: Argument number #1: 
: > The essential aspect of an image is its area.
: 
: The essential aspect of an image is _not_ its area; it is its meaning.
: That the information is in graphical format is _not_ (usually)
: essential. (One possible exception to this rule would be optical
: illusions -- there, the graphical form of the meaning is indeed very
: much essential.)

This is a stupid question-answer fabricated to show things in black and white
when the world is grayscale.
The essence is in deed the content and not the size, but in a GRAPHICAL
ENVIROMENT the image size in itself is still VERY important.
If the size ISNT important, then why the h*ll did the designer state a width and
height attribute to begin with? Width and Height are NOT required attributes in
the HTML specs.
You are suggesting that the especially _desired_&_specified_ size by a webauthor
should be totally ignored. On what merit? 
Your own written "guide" (propaganda would be a better word for it though) that
has absolutely 0 backup in any of the official W3C specs?

Don't you think an authour knows better then you how HE would like his page to
look then you do?

 
: Argument number #5: 
: > If, in this example, when the image failed to load, that ALT text
: > were placed in a box whose size was defined by the height and width
: > attributes, it would retain its semantic identity and provide a cue
: > that the entire content of the webpage is not at present available.
: > If that same ALT text were to appear inline with the same display
: > properties as the surrounding text, it could confuse.
: 
: The reader of the page frankly couldn't care less if the author has
: made a mistake and the page is not completely available. The reader
: wants the information. So if an image is not available, the page
: should adapt. This is what alt text is designed to do

Yet another compleatly bogus statement with no realtion to reality.

"author has made a mistake"

What about servers being down or any other of a myriade of technical and other
factors outside of the authors controll?
Yet again, if the author doesn't think it's important to have a specific size on
the image, why did he use 2 NON REQUIRED attributes to specify it?

"So if an image is not available, the page should adapt. This is what alt text
is designed to do"

The technica term for that statement is BS. Please state which W3C document
state that alt text should do that. Link please...


: As has been previously mentioned, the important aspect of the page is
: not its layout, it is its content. If images are disabled, and a page
: relies on images for layout, then that's ok: forget the layout
: altogether, and simply draw the remaining text.

Again, you are failing to realize that there is a difference between a non
graphical envirorment and a graphical one.
Eg, do you have 28"+ TV at home or just a 14"? It's the same content beeing
shown isn't it, so why do people prefer a lager TV evehn if it costs more?
Because SIZE MATTERS!

Another TV analouge, have you ever watched a foreign move with subtitles?
Well, if you don't understand the language then the sound (as per your
reasoning) shouldn't be important either and thus replaced by the "alt text". Do
you turn the sound off and just read the subtitles?
Mayby you do, but I bet 99.999% of the population would not (if they are not
disabled and thus have sound of anyway).

"the important aspect of the page is not its layout"

Yeah right. That is why CSS was invented, because layout is unimportant...
layout IS secondary to the content, but it ISN'T unimportant. Somehow you seem
to fail to realize this.

"Mail and composer requirements must not be used to compromise our browser's 
rendering engine."

Your fabricated ALT-TEXT-FAQ with no support in the specs what so ever should
also NOT compromize the browsers rendering engine.

"If someone would just tell us exactly WHICH website is forcing us to
consider making these compromises, I could contact them to offer my help in
fixing their problems."

That is very noble of you but I severly doubt that even you can ensure eg that
every webserver in the world has an 100.0000% uptime.


"waterson: If you float the image, the 'display' property becomes 'block' (or 
block based) and thus the height and width properties (derivied from the 
attributes) take effect as you would expect."

And if you float a div wich contains images (if you eg want to "connect" text to
an image), did you ask yourself what happens then?
It again goes to **** layoutwise with your suggestion.


"Here is an example of some well written HTML:

   <h2>The Foo Flower</h2>
<p><img src="flower.jpeg" height="100" width="40"
           alt="The foo flower has five golden petals, with a beautiful
                tall bright green stem. The stem has two leaves, one about
                one third of the way up, on the right, and one two thirds
                of the way up, on the left. The leaves are a darker shade
                of green, and appear to be thick and velvetty." /></p>
"

That is NOT well written HTML.

From the 4.01 specs

alt %Text; #REQUIRED -- short description --
longdesc %URI; #IMPLIED  -- link to long description (complements alt) --

What you have above is a perfect example of a longdesc attribute, NOT alt. Stop
making things up to prove a point that isn't correct and try reading the specs
instead.

http://www.w3.org/TR/html401/struct/objects.html#adef-longdesc-IMG


"Actually that page did change my opinion on one thing. I think the original bug
mentioned here may in fact be valid, and we should drop our use of the title 
attribute if 'alt' is missing, instead just defaulting to alt="". (dbaron?)"

That is the one thing I do agree with you on in this thread. Title should not
replace Alt under any circumstance.
If the author wants the same text to be used he should specify the same text for
both.
Using title instead of alt will produce unexpected and uncontrollable resoults
for a designer that knows what he is doing.


Finally Marc Attinasi have come with the perfect solution that will satisfy even
the "inline alt" people.
Create a Pref that turns the placeholding on or off.
However this should NOT just be this way in Quirks mode. If anyone disagrees
please state why (and back it up with W3C specs, not fiction).

"I don't suppose that I can quote Lynx for a precendent, right?"

NO!!  Since Lynx is a text only browser, It makes perfect sence for Lynx to
ignore any height or width of images since it bears no relevance for it's layout.
Mozilla is a GRAPHICAL browser. If you don't understand what it means look up
Graphical in a dictionary.

"Netscape 6.0, 6.1 and 6.2? :-)"

Only because some weirdo went on a one man crusade against logic and better
judgement and managed to push through something that has 0 support in the specs
while refering to his propaganda FAQ.
BTW, IIRC this wasn't introduced until after 6.0, before that at least this part
worked correctly even in NS 6.x.


To sum it up, get Mozilla to behave as 99.9% of the people would expect it to,
and put in a "display alttext inline" as a user controlled preference, both in
quirks AND in STANDARDS COMPLIANT mode.

(and again please state where in the specs it sais that a the OPTIONAL height
and width attributes should be ignored if scr="" is not displayed for any reason
if you disagree with it beeing 100% standards compliant)

Comment 92

18 years ago
"could the people in favour of changing 
Mozilla's placeholder dimensions behaviour please show pages that look better
with that change implemented?"


Here is how it should look.
http://hem.bredband.net/b103277/graphics/jwm2.html

Here is how "greate" it could look with inline alt if some of the images where
missing depending on eg a server failiour.
http://hem.bredband.net/b103277/graphics/jwm2broken.html

Please resize your browser window a few times to see alterantive renderings.



"The HTML spec is not very explicit about this, I'll grant you that. However I
believe the spirit of the spec is clear. The word "alt" in the name of the
attribute stands for *alternate*, not "text you would like to put in a box the
size of the image"."

If the spec wanted to say REPLACES it would do so, since it does so for
<object>, on the very same page.

Do notice that the page is not only valid XHTML 1.0 Transitional, it is also
soley the use of the target attribute in hrefs (it normally reside in a framed
enviroment) that keeps the document from beeing STRICT XHTML 1.0.
IOW, it's is litterally balongs to the best STANDARDS compliance pages that
Mozilla is likely to run accross on the web currently and it still looks like
**** with inline alt in a graphical browser.

Comment 93

18 years ago
I hesitate to throw my (possibly misinformed) two cents in on an argument 
that seems to be getting rather heated, but...

Given that Mozilla can't know whether an image is broken until after it tries 
and fails to retrieve it, wouldn't using the size attributes (assuming that 
they're specified) speed layout and/or reduce reflowing during page 
rendering? And, given that the rest of the points being made here seem to 
be subjective, wouldn't that simple performance issue settle the 
argument, being the only legitimately objective point in favor of one 
method or the other?

Comment 94

18 years ago
"Given that Mozilla can't know whether an image is broken until after it tries 
and fails to retrieve it, wouldn't using the size attributes (assuming that 
they're specified) speed layout and/or reduce reflowing during page 
rendering?"

Absolutely correct, that is what the size attributes are there for, to give
layout hints to the browser of how large an image is so the browser can begin
rendering the page well before it recives all parts.
The main reason for this is to keep stuff jumping all over the place when
loading a page in a graphical browser.

Inline alt-text as it's currently implemented in Mozilla can make a page
litterally unreadable during loading since the page might be constantly
reflowing due to images first having a specified "reserved space" and then at
some arbitrary point beeing collapsed to inline-text instead.
If you have 100 images unaccessible for whatever reason, you will have 101 total
page renderings of the same page until "it's done" and you can start reading
without the text jumping all over the place.

"And, given that the rest of the points being made here seem to 
be subjective, wouldn't that simple performance issue settle the 
argument, being the only legitimately objective point in favor of one 
method or the other?"

That is one of many points of why inline alt-text would be a generally bad idea.

The point here isn't which method is the "correct" one according to the specs
because the spec is (IMO) deliberatly vague regarding this issue. IOW both ways
are 100% correct in respect to what the specs say.

Why (IMO) is the spec deliberately vague in this area?
Simply because the spec is "browser media neutral". The rules are written to fit
both Graphical, textbased and many other browser types that might not even be
visual.
It would be litterally stupid to make a rule that would make eg Lynx break the
HTML specs for not reserving the space for an image when it will never show it
anyway.
Conversly, it is extreemly illogical to ignore the layout effects of an image in
a Graphical enviroment.
To cover all ends the spec is thus deliberatly vague and allows the desition of
the implementation to the makers of each browser.

Thus it all comes down to what is the most practical for a given browser
implementation. If one makes a simple pros list of both alternatives for a
graphical browser as Mozilla  for me that would be.

Inline alt pros 
* Taking smaller screen place once rendering is (compleatly) finished.

Keeping reserved space pros
* It keeps pages from constantly having to reflow if imagedata isn't avaliable.
* Pages are and have been designed counting on this behaviour.
* Users expect a browser to behave like this.
* This is how EVERY other GRAPHICAL browser I've seen does it and has done for
years.

Given that neighter method is wrong according to spec then, as I see it, there
is a MASSIVE weight in favour of the "keep space" method for Mozillas default
behaviour.

Any other decision for a default implementation of this I would consider a HUGE
mistake. I also see no SPECproblems with implementing a user preference for
inline alt, but for default behaviour it's a definite no no.

This is especially true for Mozillas STANDARDS COMPLIANT mode as it would lead
to designers deliberatly NOT making pages standards compliant because then
Mozilla breaks the layout if images are not avaliable, EVEN IF A DESIGENER
DELIBERATLY SPECIFY A SIZE TO AVOID IT!

We should also not forget that if a designer DOES NOT specify the size, Mozilla
will (and should) use inline alt-text... or IOW the default behaviour IS already
inline alt UNLESS the web author wants something else.

Comment 95

18 years ago
Inline alt pros 

* Taking smaller screen place.
* Doesn't look as ugly as having empty boxes all over the place.
* Concentrates on presenting user with actual content, instead of on what's broken.
* User is able to navigate the page faster without being distracted by useless data.
* The *sane* behaviour, opposed to a fubar legacy one.
* Encourages authors to create well formed pages.
* All previous versions of Mozilla and Netscape 6 behave like this.


In your previous enormous post you keep ranting non-stop about difference
between graphical and text browsers, completely failing to realise that "no
image" = "no difference" in this case. There is no graphics to display, only text.

> alt %Text; #REQUIRED -- short description --
> longdesc %URI; #IMPLIED  -- link to long description (complements alt) --

> What you have above is a perfect example of a longdesc attribute, NOT alt. Stop
> making things up to prove a point that isn't correct and try reading the specs
instead.

How about you start to read it? Maybe then you'll notice that value of longdesc
is a URI and not text, and it is meant mostly for describing image maps. Ian is
the person who does QA on Mozilla's handling of the standards, and not only he
does know them better than other people around here, he also contributes in
their creation. He would know what thought and intent stands behind a
specification, even if the spec wording itself is not good in delivering it.

Most people giving reasons for keeping these boxes seem to think that this
somehow will make the page look less broken than it already is. This is just
silly. When page layout was designed to contain images, if images are gone -
THIS IS NO LONGER WHAT THE PAGE WAS DESIGNED TO BE. Original layout was not
designed for that. A lot of people fail to realise that. Layout is no longer
"good". There is no point in clinging onto it. What this behaviour actually
does, is accentuates what is wrong with the page, instead of accentuating what's
right.

Think outside of the (broken) boxes you live in. :o)
Marc:

>> That's a problem anyway, whether the images are broken or not.
> Basically, the image is one size, the alt text is another - there
> will be cases where there are problems.

This is only a problem when you think of HTML as a layout language.
It's not a layout language. Assuming it is will give you problems all
the time, with user stylesheets, different UAs, different medias,
different prefs, etc.

Unfortunately I guess most quirks mode pages _are_ assuming that HTML
is a layout language, so I will live with this in quirks mode (for
now).


>> How, with your patch, would you get the behaviour that I am advocating?
> If you mean the inline-alt-text behaviour, I would set the pref ...

I meant as an author.


> Alternatively, I might consider NOT specifying the width and height
> on the image...

...which would make the page have many unnecessary full reflows as the
images came in, especially over a slow connection.


>> I am not convinced that we need to become less standard compliant
>> to be adopted. [...]
>
> This is opinion, and others hold different opinions. Think about it,
> different clients have different needs [...]

Not regarding standards compliance, and not regarding accessibility.


> You might be correct in your skepticism, but look as well at how
> much more leverage MS has now that they are the market leader - they
> can drop things like NS Plugins in favour of their own technology,
> something they could never do when they were playing catch-up.

They don't have nearly as much power as even they thought they had.
Look at what happened with Smart Tags, for instance. And their "quirks
mode" changes -- they are scared stiffless of changing legacy
behaviour. Why do you think you would _not_ be scared if the previous
version of your browser had 99% market share?


>> The HTML spec is not very explicit about this...
> Not very explicit? It says nothing about how to layout the ALT text
> (http://www.w3.org/TR/html401/struct/objects.html#h-13.8).

Exactly. HTML is not a layout language.


>> The word "alt" in the name of the attribute stands for *alternate*,
>> not "text you would like to put in a box the size of the image".
> Are you sure?

100% convinced. The whole point of alternate text is to provide an
alternative representation. There is *nowhere* in the spec that
suggests that the alt attribute should be used as the contents of a
box the size of the image.



> You seem to be able to infer a lot from the word "alternate", and
> anyway, it is merely conjecture. My conjecture is that ALT stands
> for 'Alternate Text' which is to be presented in place of the image

Exactly -- instead of the image, put text. Where else in HTML does
text suddenly acquire a fixed size box??



Stefan: Some extra comments in addition to what Alexey said:

>: Argument number #1: 
>:> The essential aspect of an image is its area.
>
> This is a stupid question-answer fabricated to show things in black
> and white when the world is grayscale.

Every question-answer in that FAQ comes verbatim from e-mail
conversations and bug comments, so your statement is false (sorry).


>: The essential aspect of an image is _not_ its area; it is its meaning.
> 
> The essence is in deed the content and not the size, but in a
> GRAPHICAL ENVIROMENT the image size in itself is still VERY
> important.
>
> If the size ISNT important, then why the h*ll did the designer state
> a width and height attribute to begin with?

To prevent unnecessary reflows. This is even mentioned in the HTML
spec, section 13.7.1:

# The height and width attributes give user agents an idea of the size
# of an image or object so that they may reserve space for it and
# continue rendering the document while waiting for the image data.



> Width and Height are NOT required attributes in the HTML specs.

This is because the author may not know the height and width in
advance.


> You are suggesting that the especially _desired_&_specified_ size by
> a webauthor should be totally ignored. On what merit?

HTML is not a layout language. If the author wanted to SUGGEST a
layout, he should have used CSS.


> Your own written "guide" (propaganda would be a better word for it
> though) that has absolutely 0 backup in any of the official W3C
> specs?

My propaganda is based on my interpretation of the spec. I understand
there are alternative interpretations, that does not mean they are
valid. I do think that the HTML spec should have more explicitly
mentioned the expected behavior.


> Don't you think an authour knows better then you how HE would like
> his page to look then you do?

What the author wants is IRRELEVANT. The web is a medium that puts the
READER in control.


> [snip repeated arguments already replied above]


>: So if an image is not available, the page should adapt. This is
>: what alt text is designed to do
> The technica term for that statement is BS.

Please keep bug comments civil. Thanks.


> Please state which W3C document state that alt text should do that.
> Link please...

Section 13.8 of HTML4:

# Several non-textual elements (IMG, AREA, APPLET, and INPUT) let
# authors specify alternate text to serve as content when the element
# cannot be rendered normally.

That sentence is the backing of the sentence you quote above.


>: As has been previously mentioned, the important aspect of the page
>: is not its layout, it is its content. If images are disabled, and a
>: page relies on images for layout, then that's ok: forget the layout
>: altogether, and simply draw the remaining text.
>
> Again, you are failing to realize that there is a difference between
> a non graphical envirorment and a graphical one.

If all you are displaying is text, then no, there isn't.


> Eg, do you have 28"+ TV at home or just a 14"? It's the same content
> beeing shown isn't it, so why do people prefer a lager TV evehn if
> it costs more? Because SIZE MATTERS!

Nope. People prefer a bigger TV because that gets you a more immersive
atmosphere. The same argument can be used to DROP the size of the
image and render the alternate text inline. Is it eaaier to read text
text in paragraphs, or text that is spread across differently sized
boxes and dotted around the screen? It's easier when the text is
inline -- that gives you the most immersive atmosphere.


> Another TV analogue, have you ever watched a foreign move with
> subtitles? Well, if you don't understand the language then the sound
> (as per your reasoning) shouldn't be important either and thus
> replaced by the "alt text". Do you turn the sound off and just read
> the subtitles?

Nope, because the subtitles do not convey the complete meaning of the
audio track. However the real analogue is this: If you have turned off
the sound, or if you do not have sound, do you prefer the text to be
placed in boxes either in between frames (a la very early films before
sound recording was developed), or on top of people's mouths (like
"beep" bubble on some family-targeted TV shows, possibly cropping if
their mouth is small), or do you instead prefer the subtitles to be
displayed inline, at the bottom of the screen, consistent with other
text displayed on the screen, such as news tickers?


>: the important aspect of the page is not its layout
> Yeah right. That is why CSS was invented, because layout is
> unimportant...

Actually, you are correct -- CSS was invented to split the layout from
the structure. One more argument in favour of not treating anything
HTML says as being layout-orientated.


>> Mail and composer requirements must not be used to compromise our
>> browser's rendering engine.
>
> Your fabricated ALT-TEXT-FAQ with no support in the specs what so
> ever should also NOT compromize the browsers rendering engine.

I do not believe I am compromising the rendering engine, as I fully
believe my position provides the best experience for end users.


>> If someone would just tell us exactly WHICH website is forcing us
>> to consider making these compromises, I could contact them to offer
>> my help in fixing their problems.
>
> That is very noble of you but I severly doubt that even you can
> ensure eg that every webserver in the world has an 100.0000% uptime.

Whether alt text is rendered because images are disabled, the image
format is not supported, the image is corrupted, or the server is down
should make no difference. A well designed page should ALWAYS
gracefully degrade to an image-free state (also known as "should look
good in lynx").


> And if you float a div wich contains images (if you eg want to
> "connect" text to an image), did you ask yourself what happens then?
> It again goes to crap layoutwise with your suggestion.

Please give me an example. All examples I just tried end up with a
perfectly reasonable layout where the three images' alt text are
merged into a sidebar-like paragraph, and the user thinks "isn't this
page nice" as opposed to "ugh, this page has broken images
everywhere".


>> Here is an example of some well written HTML:
>> 
>>   <h2>The Foo Flower</h2>
>> <p><img src="flower.jpeg" height="100" width="40"
>>         alt="The foo flower has five golden petals, with a beautiful
>>              tall bright green stem. The stem has two leaves, one about
>>              one third of the way up, on the right, and one two thirds
>>              of the way up, on the left. The leaves are a darker shade
>>              of green, and appear to be thick and velvetty." /></p>
>
> That is NOT well written HTML.
> From the 4.01 specs:
>
># alt %Text; #REQUIRED -- short description --
># longdesc %URI; #IMPLIED  -- link to long description (complements alt) --
>  - http://www.w3.org/TR/html401/struct/objects.html#adef-longdesc-IMG
>
> What you have above is a perfect example of a longdesc attribute,
> NOT alt. Stop making things up to prove a point that isn't correct
> and try reading the specs instead.

If you honestly believe that is a *long* description then frankly you
have no experience in writing web pages that are accessible to
disabled users. A longdesc page for a flower image would have been
many paragraphs long. Just take a look at the D-link images in the CSS
spec for examples.



>> I don't suppose that I can quote Lynx for a precendent, right?
> 
> NO!! Since Lynx is a text only browser, It makes perfect sence for
> Lynx to ignore any height or width of images since it bears no
> relevance for it's layout. Mozilla is a GRAPHICAL browser. If you
> don't understand what it means look up Graphical in a dictionary.

When images are disabled, Mozilla is also a text browser. Why should
Lynx not leave room for images? I *really* don't understand your
position here. What do you *think* "graphical" and "text mode" mean?

In my dictionary "graphical" means: "of or relating to a pictorial
device used for illustration, as in a lecture". If you have images
disabled, how is anything relating to a pictural device??? (Here
"device" does not mean computer peripheral, it means an object such as
a photograph.)



>> "Netscape 6.0, 6.1 and 6.2? :-)"
> Only because some weirdo went on a one man crusade against logic and
> better judgement and managed to push through something that has 0
> support in the specs while refering to his propaganda FAQ. BTW, IIRC
> this wasn't introduced until after 6.0, before that at least this
> part worked correctly even in NS 6.x.

I had the full support of the previous layout owners (buster, kipp,
peter) YEARS ago (late 1999), eons before 6.0 came out. This was a
done deal and it is only the recent rumblings from AOL that changed
matters. :-)


> Here is how it should look.
> http://hem.bredband.net/b103277/graphics/jwm2.html

> Here is how "greate" it could look with inline alt if some of the images where
> missing depending on eg a server failiour.
> http://hem.bredband.net/b103277/graphics/jwm2broken.html

That page has some very poor alt texts. "flag" and "shield small" are
not appropriate. The longer alt texts are much more reasonably sized,
but the stylesheet doesn't take them into account, so they overflow.
The author should have thought of this (after all, what if Lynx ever
supports CSS? I'm told they intend to.)

And frankly, do you really think the way IE or Konqueror handle that
page is any better?

Here is what a well-written verion of that page would look like:

   http://www.damowmow.com/mozilla/bugs/102281/jwm2broken.xml

It would look _even_ better if bug 11011 was fixed.


> Do notice that the page is not only valid XHTML 1.0 Transitional,

My version (URI above) is XHTML strict.


> it is also soley the use of the target attribute in href ... that
> keeps the document from beeing STRICT XHTML 1.0.

Actually, I had to make some other changes as well (<img> is not
allowed to be placed directly inside <body>, for one, and while not
required by the DTD it is highly recommended to include the XHTML
namespace on the root element so that namespace-aware processors, like
Mozilla, correctly display the page).


>> The HTML spec is not very explicit about this, I'll grant you that.
>> However I believe the spirit of the spec is clear. The word "alt"
>> in the name of the attribute stands for *alternate*, not "text you
>> would like to put in a box the size of the image".
>
> If the spec wanted to say REPLACES it would do so, since it does so
> for <object>, on the very same page.

The only mention of the word "replace" on that page relates to the
<img> tag, not the <object> tag.



inquisition@unforgettable.com:
> Given that Mozilla can't know whether an image is broken until after it tries 
> and fails to retrieve it, wouldn't using the size attributes (assuming that 
> they're specified) speed layout and/or reduce reflowing during page 
> rendering?

I fully support our using the height and width attributes before
discovering the image is broken! We have been doing that for some time
and I have never suggested the opposite. This is indeed exactly what
these attributes are intended to do.



Alexey Chernyak: Thank you. You summarise the issues better than I do.

Comment 97

18 years ago
After this patch was checked in, Mozilla users immediately displayed their
unhappiness in bug 41924.

Personally, I don't mind the pref - the more flexibility, the better. It should
be hooked up somewhere in GUI.
However I do mind the differences between quirks and standard, which would scare
authors away because it looks alien, instead of encouraging them to start making
strict, valid pages.

I think we should make it behave in the same way in quirks and strict. Netscape
can use boxes by default if they really want to, and have Mozilla use inline by
default. How does that sound?

It's hard to make technical progress when you have business oriented people
sitting on top, afraid that any change would scare customers away.

Goal of Mozilla, as far as I know, is to be the best.
Goal of Netscape is to reclaim the market share.
Keeping these two goals together is hard, so let's separate them. And have to
each their own. Mozilla can be a controversial browser in pursuit of technical
innovation, while Netscape can be a laid back version of it. :o)
Blocks: 109410
Uh oh. Hold it right there. One of the things I found most objectionable about
bug 88297 was that there was the potential for a fork in standards support.
Whatever changes Netscape makes to Mozilla should be all packages/aesthetics;
all browsers using the same version of Gecko should have the same standards
support. Period. Otherwise, we just make the whole browser-sniffing situation an
order of magnitude worse.

Comment 99

18 years ago
Christopher: What you're saying is that we should have *no* user configurable
prefs affecting layout (eventhings like Java and JavaScript related), otherwise
not all users of Gecko based browsers will see the same. Whether the schism of
changing a setting is vendor selected default or a user choice is not important.
The end result is the same: some people will have [gasp!] different settings.
http://planetmath.org/?op=getobj&from=objects&id=790

try understanding that with images off and image placeholders clipping the alt text.

Comment 101

18 years ago
> I fully support our using the height and width
> attributes before discovering the image is broken!

Great! Good! You completely missed my point.. and I find your position on 
this a bit confusing. If the size of an image is irrelevant, as you say, then 
why honor size attributes at all? If you see it as good that that Mozilla 
honor size attributes for the sake of page rendering, then why do you 
insist on throwing all those benefits in the trash by forcing the page to 
reflow every time an image breaks? And knowing that designers mean for 
their pages to be readable as designed, how can it help users to 
maliciously break them at the first opportunity?

I was leery of butting in before, when the argument seemed to be a 
reasonable difference of opinions, but recent comments go too far. Hixie, 
as a user I'm grateful for your efforts on Mozilla's behalf, but the only thing 
you're succeeding in convincing people of here is that you have an ego the 
size of a zeppelin. Your ridiculous and wholly unrealistic attitude that 
layout is irrelevant - pick a page off Google at random and look at it, for 
pete's sake! - is only going to alienate everyone here, and if it succeeds in 
influencing Mozilla, I suspect it will alienate a lot of users and developers 
as well. Your arguments seem more focused on "proving" that everyone 
else is wrong and the web should look as it did in 1993 than on actually 
making sense in context or benefiting users.

If it's so crucial to you that people use CSS size attributes instead of HTML 
ones - a change which offers no benefit to anyone whatsoever, and which 
will make Mozilla less compatible with almost every page that exists - then 
go evangelize a web design magazine or something, but drop this stupid 
crusade. Standards compliance is one thing; forcing people to build the 
web in accordance with one man's vision is another, and has already 
spectacularly failed once.
I am against forking Gecko for Netscape vs Mozilla since the whole point of
doing it the way I support is that once a browser that implements this as I
suggest has a large market share, it will force authors to at least *think*
about what happens when images break, which will cause them to fix their pages
to be more readable to users without images.


Daniel: http://planetmath.org/?op=getobj&from=objects&id=790 is a great example
about why we must do alt attributes inline as soon as possible. Can you imagine
what it must be like for a blind user reading that page? They get latex stuffed
in the middle of english. That page is not in the least bit accessible. If the
author had tried viewing that page in Lynx he would *never* have even
*considered* using latex source for alt attributes. However Lynx has no market
share and is therefore not used by authors as a benchmark. That's why Mozilla,
which is used as the basis for the product which is trying hardest to regain
market share (Netscape 6.x), should take the lead on this issue as we have on
many others. (Note: We have already seen Microsoft change their behaviour to
match ours on issues like this one. We have never seen them follow Lynx.)


inquisition@unforgettable.com:
> If the size of an image is irrelevant, as you say, then why honor size 
> attributes at all?

I apologise, for I must have been unclear. The size of the image is irrelevant
to the page's _meaning_. However it is not irrelevant to the _image_. So if the
image is present, then the size should be used. If the image is not present, 
then the size should _not_ be used. (To put this in CSS terms, if the image is
present then the frame should be a replaced element, and if it is not, then the
frame should be a non-replaced element.)


> And knowing that designers mean for their pages to be readable as designed

Designers need to be shown why for a minority of their users (mainly disabled
users) their alt text is of an extremely poor choice. If we put the alt text
inside the boxes then we are saying "oh don't worry about this, it doesn't
matter" when it blatently _does_.


> [...] you have an ego the size of a zeppelin [...]

I welcome advice on how to explain this better. What part of my argument do you
not agree with?

The most likely reason for a difference in opinion is a difference in our
respective starting points. I am starting from the forward-looking position that
I would like Mozilla to encourage good practices. You, I would guess, are coming
from the position that you would like Mozilla to render everything exactly as
before. Is this correct?

If it is, then why not just use IE?


> Your ridiculous and wholly unrealistic attitude that layout is irrelevant...

I'm sorry, I really did not mean to convey that as a blanket statement. It is
my belief -- backed up by the HTML spec, see chapter 2 -- that the structure,
the _meaning_ of the document is what matters most _to the user_. (There are of
course exceptions -- for example, when the page is demonstrating a particular
CSS feature, the "meaning" of the page is the layout itself!) Layout is 
important -- and certainly not irrelevant -- otherwise, why would the W3C have
spent so many resources developing not one, not two, but three layout languages?

However, good layouts are flexible. They will cope with user stylesheets, with
different font sizes, different size screens and windows -- they will even cope
with being used on media as different as hand held phones and printers. If an
image is not present (for whatever reason -- the UA doesn't support images, the
server is unavailable, the user is offline, etc) then the page should adapt to
the new environment just like it should adapt to a different window size. It is
the author's responsability to have planned for this -- and as I showed in the
page I rewrote to back a point in my previous comment, it is very easy to do so.


> ...if it succeeds in influencing Mozilla, I suspect it will alienate a lot of 
> users and developers as well.

It influenced Mozilla for over 2 years, and influenced three commercial Netscape
releases, including the quite popular* 6.2. So far I have heard less than a
dozen complaints regarding this issue, all in this bug. This is *considerably*
less than I have heard for other similar issues, such as the "please show the
alt attribute in a tooltip" request.

It is worth nothing that I have heard as people many complaining that we have
changed our behaviour to be as you describe as I have heard complaints saying
that we should have changed it.


> Your arguments seem more focused on "proving" that everyone else is wrong and 
> the web should look as it did in 1993 than on actually making sense in context 
> or benefiting users.

My entire argument is for the benefit of users on the long run, as I explained
above.


> If it's so crucial to you that people use CSS size attributes instead of HTML 
> ones - 

"Crucial" is a strong word, however I am of the firm opinion that authors should
be moving towards a world where they separate content from style as was
originally intended over 10 years ago when HTML was first invented, and as the
W3C has been pushing for a good 5 years.

It takes a long time to change the behaviour of web designers. Changing web
browsers to make the better behaviour work better is part of the work of
encouraging authors to move forward.


> ...a change which offers no benefit to anyone whatsoever

I am sorry to hear you consider disabled people, search engines, people on slow
connections, et al to be insignificant.


> ...then go evangelize a web design magazine or something

That is a separate issue. There would be no point evangelising my position to a
web design magazine if no web browser did it the way I evangelise, as web
authors are famous for just doing "what works" instead of what is right.


> but drop this stupid crusade.

Why? Are you worried my arguments might convince more people than yours and
therefore want me to shut up?


> ...forcing people to build the web in accordance with one man's vision is 
> another...

I am not trying to *force* authors per se, however, if there is any way of
encouraging authors to write web pages so that they are more accessible then I
believe we should do our best -- don't you?


* based on download.com "thumbs up" statistics, Netscape 6.2 is more popular 
than IE6.

Comment 103

18 years ago
How does the visual formatting of the alt text for broken images impact the way
a blind person reads a site? For that matter, how does the visual formatting of
the alt text for a broken image impact accessability at all? My (niave)
understanding is that aural renderings can be vastly different from the visual
renderings (what about braile rendering?), and that accessability features can
operate orthogonally from the visual layout.
Marc: I believe Hixie's point was not that displaying boxes around alt text
damages accessibility per se, but that it panders to inaccessible site design. 
Look at bug 109140: once we start doing this, long (and accessible) alt text is
positively *discouraged*, because you can no longer read it.

The idea of a pref is also fairly silly, IMO (and I think mpt will almost
certainly turn down graphical exposure for this pref); the average end user does
not understand what such a pref is all about.  Whether or not we show "boxes" is
just something the browser does, and is not something that is meaningful to
configure for 99% of users.  We should settle on one behavior to do this, and
I'm in favor of Just Getting It Right.

Comment 105

18 years ago
>The idea of a pref is also fairly silly, IMO (and I think mpt will almost
>certainly turn down graphical exposure for this pref); the average end user does
>not understand what such a pref is all about.  

I disagree about it being silly, but agree that users may not bother with it
themselves. But, different *installations* can set the default to what the
expected audience wants. For example, Mozilla may want to set the pref to true,
whereas netscape 6 or k-meleon may want to set it to false. Still other
installations may want to allow the user to choose for themselves,and they may
find a clever way to describe it (display broken images like Lynx or IE?)

>We should settle on one behavior to do this, and
>I'm in favor of Just Getting It Right.

Unfortunately, there is no 'Right' or 'Wrong' here - there are different
audiences that have different expectations and different desires in this regard.
For example, some people want to use a scheme that urges web authors to think
about how they use ALT text, and others want to use a scheme that presents no
surprises to users by being compatible with legacy behavior. Who is right?
 I think both have legitimicy and now both can be accomodated.
Marc: honestly, this business of a pref sounds like sheer ad-hockery to disguise
the fact that we're letting embedders degrade our standards compliance.  I've
already argued in bug 88297 about the evil of this; as I said there, if people
want to embed Mozilla, they will get standards, take it or leave it.  We don't
support layers.  We don't support document.all.  If embedders are willing to
accept that, not getting "alt boxes" should be a non-issue.  Furthermore, I
don't see that there's any support for the "box" interpretation, other than "it
used to work that way in NS 4.x."  The <object> element, for instance, when it
can't be loaded, is replaced with its own content, which can cause very drastic
changes in layout.  Given that <img> is really just a left-over special case of
<object>, I don't see why its behavior should be different. And the "it worked
in NS 4.x, it should work now" argument is a non-argument that's already been
rejected in the two cases above.  Just because people want the hacks and browser
bugs they've been using to go on forever and never have to do anything right
doesn't mean they should get it.

Comment 107

18 years ago
>... as I said there, if people
>want to embed Mozilla, they will get standards, take it or leave it.

Are you speaking for yourself for for Mozilla? In some ways, I wish that was a
true statement, as I spend most of my time reverse-engineering quirks which is
not much fun, but from what I have seen, Mozilla tends to be more reasonable.
Good thing too, or the number of people using it would be approximately equal to
the number of people creating and testing it.

>Furthermore, I
>don't see that there's any support for the "box" interpretation, other than "it
>used to work that way in NS 4.x."

Well, it works that way in more than 90% of the user agents in use. Granted I
realize you just don't care, but to characterize this as "used to work that way
in NS 4.x" is inaccurate in its implication. Besides, we do lots of things
because that is what legacy browsers do/did. Look at tables - if we did not base
the implementation on legacy nobody would know what to implement because the
specs are so incomplete.

>Just because people want the hacks and browser
>bugs they've been using to go on forever and never have to do anything right
>doesn't mean they should get it.

Whatever. If you wanna be hard-line and take Mozilla off in some
narrowly-focused direction that does not allow for support of any legacy
behavior, more power to you - but I am not interested. I work for a company that
actually wants people to *use* the technology, and so we try to make reasonable
compromises.

BTW: though I am not interested in the religious arguments, I am still
interested in the possible impacts on accessability
Marc: first of all, I know you are a reasonable person, and that you're not
wantonly adding things to quirks mode to annoy standards people.  Be that as it
may, the only coherent argument I've seen for this behavior is that "we used to
do it".  This is an argument for adding support; it is not an *absolute*
argument for adding support, as per my examples above.  Given that the "boxes"
obscure long, descriptive, accessible alt texts (see bug 109410, typo in my
previous reference), authors are encouraged by it to omit alt texts or include
short or misleading ones (alt="Turn on image loading, damnit!" has been observed
in the wild.)

In other words, either behavior will cause a certain amount of pages to be
damaged.  Given that people are still (despite good intentions) authoring quirks
mode pages and look to do so for some time, and given also that the number of
broken images encountered in web surfing (in my experience) is nowadays quite
small, as servers become more reliable, etc., I think that accessibility should
take priority over a certain loss of polish.  "Surfing with images turned off"
seems a bit of a red herring to me; I should think that people who do this
regularly experience far more discomfort from meaningless, silly, or absent alt
attributes than from layout being rearranged.
Hear hear.

Comment 110

18 years ago
I think what we need to do is distinguish between cases where the *viewer*
decides not to load images and where the *image itself* doesn't load due to
unexpected circumstances (broken link or busy server). In the former case,
content is more important and the viewer may prefer the option to have the ALT
text expanded at the cost of page layout. However, when images unexpectedly
break, how they are handled should have *nothing* to do with whether or not the
page is built to any standard. I would certainly be unhappy if I had a gallery
page (the situation where I most expect this to become a problem) and the entire
layout went out of whack simply because of some stupid ALT text that was put
there for Lynx and search engines. There is also a chance that an imagemap could
still be usable if the placeholder uses the right dimensions. Therefore the
default behavior should be to keep the image at its specified width/height and
trim the ALT text to fit (and being able to expand it, bug 109410, is very
important). And again, *nothing* related to placeholders should depend on
whether or not the browser is in quirks.

Also, I think we should include the icon and box (and render as a block element)
the last image in the testcase without any width or height attributes. Right now
you can't tell it's an image's ALT text. Imagine how strange something like this
would look:

Welcome to my <IMG ALT="A picture of a dog"><BR>
web page.

Yes, it is a poorly designed HTML page, but we should be prepared for that.

Comment 111

18 years ago
> I apologise, for I must have been unclear. The size
> of the image is irrelevant to the page's _meaning_.

The color of the page is irrelevant to the page's _meaning_. But if it used 
black text on a black background, where would that leave it?

What I mean to say is that content and layout can't always be completely 
divorced. Even if the size of an image doesn't convey any direct message 
to the viewer doesn't mean that it can be safely thrown away.

> Designers need to be shown why for a minority of their
> users (mainly disabled users) their alt text is of an
> extremely poor choice.

Perhaps.. or perhaps those designers just don't care. There's a difference 
between a page which is explicitly required to be accessible to everyone 
and a page where the designer may not intend for his page to be viewed 
by the blind (not optimally, anyway). ALT text may not be optional under 
current standards, but considerate design certainly is.

> > [...] you have an ego the size of a zeppelin [...]
>
> I welcome advice on how to explain this better. What
> part of my argument do you not agree with?

The part where you present yourself as the ultimate authority on the spec, 
and your personal interpretation as the only correct one?

> The most likely reason for a difference in opinion is
> a difference in our respective starting points. I am
> starting from the forward-looking position that I would
> like Mozilla to encourage good practices.

I've heard this before, and my answer was the same as it is now: by all 
means, do encourage good practices, but don't try to do it by forcing 
people to do it your way or else. The specs are too broad to prevent abuse 
(and I don't think they were ever designed to; only to allow good design as 
an alternative), or to put it another way, you're trying to herd cats here.

> You, I would guess, are coming from the position
> that you would like Mozilla to render everything
> exactly as before. Is this correct?

Your summation is too broad. If I wanted Mozilla to be an exact clone of 
Netscape 4, or IE 5, I would simply use those browsers, as you suggest. 
However, I take issue with this specific proposal, because I think it will do 
far more harm than good.

> Layout is important -- and certainly not irrelevant 

...and therefore, should be preserved, if possible.

> However, good layouts are flexible. They will cope
> with user stylesheets, with different font sizes, different
> size screens and windows -- they will even cope with
> being used on media as different as hand held phones
> and printers.

Ideally, yes, but in many cases a page can be well-designed without 
being this compatible. For instance, many pages were never intended to 
be viewed on a cellphone. Incompatibility is not necessarily a sign of bad 
design, only of special requirements which are not met by all devices or 
envirnoments.

> I am sorry to hear you consider disabled people, search
> engines, people on slow connections, et al to be insignificant.

Search engines could care less whether Mozilla preserves boxes or not, 
so this is a non-issue. Likewise for any browser which makes little or no 
attempt to preserve layout, which would include Lynx. Likewise for braille 
readers, aural browsers, and the like. As for the people on slow 
connections.. well, surely that's their problem, isn't it? A few years ago, I 
complained that Mozilla wasn't compatible with my hardware (at the time, 
a 68k Mac) and found no sympathy; I see no reason why some poor 
bastard with a 9600 baud modem should be treated any differently.

> I am not trying to *force* authors per se, however, if
> there is any way of encouraging authors to write web
> pages so that they are more accessible then I believe
> we should do our best -- don't you?

Accessibility is not the sole priority here.

It occurs to me that we have two distinct classes of users here to 
consider: those who would benefit more from inline ALT text that destroys 
layout, and those who would benefit more from clipped ALT text that 
preserves it. I don't like the idea of having a pref for this, but nevertheless, I 
think that the only solution that serves both classes will be one that serves 
them individually, rather than trying to find one behavior that serves both.
Why are you people arguing in a resolved bug?  If you really want mozilla.org
staff to render a judgment here, I'll do it (but those of you who are dragging
this out here won't like the decision).  Please take it to a newsgroup if you
must keep beating this dead horse.

/be

Comment 113

18 years ago
Brendan: You're right, and part of this bug still needs to be changed.

1. Placeholders should always be drawn whether running in standard mode or
quirks mode, not just in quirks mode. I have yet to see any valid reason to only
do this in quirks mode (since the behavior of ALT text isn't standardized). As a
matter of fact, placeholders with expandable ALT text would satisfy checkpoint
2.10 of the W3C user agent accessibilty guidelines.
<http://www.w3.org/TR/UAAG10-TECHS/guidelines.html#tech-toggle-placeholders>

2. There should be a way to view alternate text without a block container for
users who keep images turned off. We already have a pref for this, it just isn't
available in the UI (access to this pref should be near the setting to turn off
images). This one probably belongs in another bug, but I won't be the one to
file it since my motto is "if you want a Lynx, go use Lynx."

So, for part 1, I will change the summary and reopen this bug.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Summary: [FIX]WRMB: preserve the dimensions of a broken image and do not render |title| attribute as alternative text → Draw appropriately sized placeholder regardless of standard/quirks mode
Please do _not_ change bug summaries on resolved bugs.  It screws with searches,
if nothing else.  This bug is fixed.  Do not morph it to be what it is not. 
Futher problems == new bugs.
Status: REOPENED → RESOLVED
Closed: 18 years ago18 years ago
Resolution: --- → FIXED
Summary: Draw appropriately sized placeholder regardless of standard/quirks mode → [FIX]WRMB: preserve the dimensions of a broken image and do not render |title| attribute as alternative text

Comment 116

18 years ago
Have it your way.

New bugs:

Bug 110212: Draw image placeholder even when there is no height/width
Bug 110213: Draw appropriately sized placeholder regardless of standard/quirks mode

Not created:

Add pref to UI for browser.display.force_inline_alttext

Comment 117

18 years ago
>Inline alt pros 
> * Taking smaller screen place.

That is true, as I've said myself

>* Doesn't look as ugly as having empty boxes all over the place.

Your won't have empty boxes anyway,
_unless_the_designer_deliberatly_has_specified_theses_boxes_
I don't know how many times I've said this now but inline alt IS the default
behaviour with an <img>. It ONLY when you SPECIFICALLY state a size that you
will get boxes.
Can't you see the difference?

>* Concentrates on presenting user with actual content, instead of on what's broken.

Albeight to the cost of the page constantly resizing before it's loaded and text
jumping around.

>* User is able to navigate the page faster without being distracted by useless
data.

When the page has finished loading... before that he won't be able to navigate
at all since the page will constantly reflow.

>* The *sane* behaviour, opposed to a fubar legacy one.

And of course performance penalties to be payed is compleatly irrelevant or at
least you have to be insane to bother with that aspect.
Well I'm sorry to say, in that case I'd better get myself commited since it
matters to me.
Also, I'm yet to be convinced why a legacy, 100% to spec, method is fubar just
becuse it's legacy.
Progress is to make something better, not just replace it with something else
just to change things.

>* Encourages authors to create well formed pages.

Please state where my page is "broken" to make it NON well formed? Did you even
check the links?
Also, feel free to take a look on the page in eg Lynx.
If you can design a better page, please show me how, I'd be most interested.

>* All previous versions of Mozilla and Netscape 6 behave like this.

That is simply not true. You obviously havn't been testing Mozilla for very
long. Overriding specifed attributes and forcing inline alt hasn't been the case
always.

>How about you start to read it? Maybe then you'll notice that value of longdesc
>is a URI and not text, and it is meant mostly for describing image maps.

Um, I think you need to read it again, not me.
"short description" for Ian's example would be alt="A foo flower" with a link to
his small essay as the longdesc.
(LINK yes, it even sais URI in the part I cut and pasted, which you obviously
missed. Who knew I had to state it more then once for everyone to pick that up).

>Most people giving reasons for keeping these boxes seem to think that this
>somehow will make the page look less broken than it already is.

Did you bother to visit the two links I gave?
Tell me again how it does not make the page look a lot more broken.

>Layout is no longer "good". There is no point in clinging onto it.

That desicion is NOT up to you but up to the author that designed the page. If
he feels the layout IS important enough to cling on to, why are you trying to
deprive him of the right to do so?
For the 14526th time width and weight are NOT required attributes. They are only
optional and specified when the author wants it.

Comment 118

18 years ago
"Why are you people arguing in a resolved bug?"

Because it's an issue that has had very lobsided argumentation already in many
many bugthreads on the forum.

I agree that it would be much better in a forum thread somewhere, but that has
obviously not been the prefered way sofar.
If someone starts a discussion somewhere more apropriate I'll gladly join there,
but currently this is where the issue is discussed by people with strong
connections to the mozilla project. Thus for now I will reply in this bugthread.



@Ian

>  There is *nowhere* in the spec that
>suggests that the alt attribute should be used as the contents of a
>box the size of the image.

There is also *nowhere* in the spec that suggest a browser should compleatly
ignore non depreceated attributes in an arbitrary fassion.
What part of the specs are you going to ignore next?
Why don't we just go down the MS road and implement just the parts of HTML a
small cohsen group think is useful.

>> You seem to be able to infer a lot from the word "alternate", and
>> anyway, it is merely conjecture. My conjecture is that ALT stands
>> for 'Alternate Text' which is to be presented in place of the image

>Exactly -- instead of the image, put text. Where else in HTML does
>text suddenly acquire a fixed size box??

Everywhere where the author has DELIBERATLY specified that there should be a box.

>Every question-answer in that FAQ comes verbatim from e-mail
>conversations and bug comments, so your statement is false (sorry).

In that case sorry about the fabrication part, but those statements/arguments
are still stupid even if they did come from real people. However you can prove
stupid arguments wrong forever, it still does NOT prove that your suggestion is
"right".
And in this case I also think beeing "right" means not violating the W3C specs.

As I've said, nothing in inline alt is wrong according to the spec. But the
exact same thing is true for the "keep reserved space" too, it also is in line
with the specs.
Thus it boils down to a preference... which thus belongs in the usercontrolled
preference settings.

>> If the size ISNT important, then why the h*ll did the designer state
>> a width and height attribute to begin with?
>To prevent unnecessary reflows. This is even mentioned in the HTML
>spec, section 13.7.1:

But I guess unnessecary reflows due to ignoring these attributes and collapsing
reserved space are ok?
Please explain why one type of reflow is better then another as I view them to
be equally bad.

>HTML is not a layout language. If the author wanted to SUGGEST a
>layout, he should have used CSS.

So you mean if it would have said style="width:xpx;height:ypx" then everything
would be fine?
That works for me and I can start using that tomorrow, but how is that better
solution then a user controllable option to turn it on or off depending on
preferance?

Height and width are are just as valid HTML attributes as style. Why should one
be ignored while the other is not?

Woudn't it be better that we leave up to the W3C to decide what parts of the
specs are deprecated and what parts are not?
Personally I would think that would be a better way for the future.

>> Please state which W3C document state that alt text should do that.
>> Link please...

>Section 13.8 of HTML4:
># Several non-textual elements (IMG, AREA, APPLET, and INPUT) let
># authors specify alternate text to serve as content when the element
># cannot be rendered normally.
>That sentence is the backing of the sentence you quote above.

Where in that section of the spec do you read that attributes of the entity in
which the content lies should be ignored arbitrarily?

SGML ground model
<tag attribute1 attribute2 ...>Content<endtag>

Logically I cannot see a reason for keeping 1 attribute while discarding another
in a given tag whithout any support in the specs.

>Nope. People prefer a bigger TV because that gets you a more immersive
>atmosphere. The same argument can be used to DROP the size of the
>image and render the alternate text inline. Is it eaaier to read text
>text in paragraphs, or text that is spread across differently sized
>boxes and dotted around the screen? It's easier when the text is
>inline -- that gives you the most immersive atmosphere.

What you are saying now is that there should be no images to begin with and all
text as in a book. Sorry, but the reality on the web is that people use pictures.

>Nope, because the subtitles do not convey the complete meaning of the
>audio track.

An alt-text does also NOT convey the compleate meaning of an image.
The size alone of an image represents something which is compleatly lost with
inline alt. 
If it's a small 5x5px picture it is very likely to be less important then a
800x600 image (alternativly it can convey the message that the authour is
clueless of what he is doing if he has a nonimportant image of the size 800x600,
but it's not Mozillas job to assume that).

>Actually, you are correct -- CSS was invented to split the layout from
>the structure. One more argument in favour of not treating anything
>HTML says as being layout-orientated.

Here we are back to my previous point of letting the W3C decide what parts of
the spec are deprecated and what parts are not.

>I do not believe I am compromising the rendering engine, as I fully
>believe my position provides the best experience for end users.

The defacto standard which is compleatly in line with the specs is to keep the box.
So why is a userpref to controll this behaviour a bad desicion? Then everyone
can decide for them selfs. Why do you have to force your preference on other people?

>Whether alt text is rendered because images are disabled, the image
>format is not supported, the image is corrupted, or the server is down
>should make no difference. A well designed page should ALWAYS
>gracefully degrade to an image-free state (also known as "should look
>good in lynx").

If you look at my above example I've liked to with Lynx you will notice that it
looks just perfect. It will also look just perfect if ALL images are displayed
as inline alt in a graphical browser.
Problems doesn't appear until just some of the images are missing for whatever
reson.

In short you are wrong, it DOES matter what the reason for a missing image is.

>A longdesc page for a flower image would have been
many paragraphs long. Just take a look at the D-link images in the CSS spec for
examples.

Could you give a link please, it's a long spec.

In any case I build my view of the alt attribute on the HTML 4.01 spec, which
sais it should be a *short description*. I don't recall ever seeing anything
longer then 5 words as an altdescription example there either, tough I might be
wrong.
Until I do I will assume that I am right and you are wrong.

I will accept other dokuments then the HTML spec as proof that an alt-text
should be several sentances long. However it should be a W3C spec, not something
you have written on your own.

>When images are disabled, Mozilla is also a text browser. Why should
>Lynx not leave room for images? I *really* don't understand your
>position here. What do you *think* "graphical" and "text mode" mean?

If images are compleatly disabled I have no problem with Mozilla using inline
alt exactly the same way as Lynx (and for the exact same reason).
And again if you look at my page I've liked to you will see that it looks just
perfect in a *strictly* inline alt enviroment.

It only goes to **** in a mixed "reserve space/inline alt" enviroment.

>I had the full support of the previous layout owners (buster, kipp,
>peter) YEARS ago (late 1999), eons before 6.0 came out. This was a
>done deal and it is only the recent rumblings from AOL that changed
>matters. :-)

It might have been that long ago, but I definitly noticed the switch, though I
first figured it was a temporary bug.
Also rumbelings from AOL in this issue... I can't imagine why.
It's not like they risk losing 30million customers if they start using Moz
because the users will switch to an IE-based browser that behave like they
expect it to instead of thrashing the page layout because of a few peoples
preferences that has nothing to do with beeing right or wrong according to the
W3C specs.

>And frankly, do you really think the way IE or Konqueror handle that
>page is any better?

In IE that page at least keeps it's strukture and the parts remain in an orderly
alphabetical order. The ugy X icon I could do without, but it still beats
Mozillas inline alt version of the same page.

>Here is what a well-written verion of that page would look like:

Frankly, that page is if possible even uglier then original "broken" page. The
page is still massivly disorganized, not even nearing an orderly alphabetical
order of the divs.

The text is also made so small that it simply is unreadable unless you increase
the fontsize manually. Manually having to adjust anything for even a non
disabled to read a page at all is NOT a well-written page.

Also for me you page also doesn't even show up in Lynx (instead it tries to DL
it and save to HD...). How greate is that.


>Actually, I had to make some other changes as well (<img> is not
>allowed to be placed directly inside <body>, for one, 

Yes, sorry. That was actually deliberately kept a bit too sparce to use as an
example of how to use CSS background as a better way of placing decorative
images on a page then using <img alt="" ...>.
In any case it does not affect the inline alt issue in any way.

>and while not
>required by the DTD it is highly recommended to include the XHTML
>namespace on the root element so that namespace-aware processors, like
>Mozilla, correctly display the page).

This likewise does not affect the inline alt issue in any way, but if we are
going to nitpick you are aslo still missing the (eg) <?xml version="1.0"
encoding="iso-8859-1"?> part on your page that should be placed infront of the
doctype. I usually use both on my pages, but as I said it's a somewhat dumbed
down page to show CSS put to good use instead of a somewhat missues of images to
create layout.


>The only mention of the word "replace" on that page relates to the
><img> tag, not the <object> tag.

Again you have a tendency of nitpicking on nonissues. It is not the exact
wording no.
But I guess I should include this quote from you in this very same thread where
you actually say just that.

>the <object> element avoids this entire issue by unambiguously saying that if
it cannot 
>be rendered it should be replaced by its contents.

Instead of nitpicking please stick to the issue instead as I'm sure you are well
aware of my point beeing the difference in how <img> and <object> is handled
where the entire <object> (attributes and all) are REPLACED by the content in
case it can't be shown for whatever reason.
For <img> one content is used instead of another, leaving the entity and the
it's attributes in place unaltered.

This issue was even brought into this thread by you, so your remark that "the
exact word isn't used for object" is very inapropriate.


-------
>I think we should make it behave in the same way in quirks and strict. Netscape
>can use boxes by default if they really want to, and have Mozilla use inline by
>default. How does that sound?

You make valid points IMO.
I would prefer having boxes as default even in mozilla (as it's the encuraged
developer test platform for NS6.x) but personally it doesn't matter to me if I
or you have to open up the preferencebox and change the setting.

-------




@ Hoss

>The <object> element, for instance, when it
>can't be loaded, is replaced with its own content, which can cause very drastic
>changes in layout.

In a predicatble manner crossbrowser which is what a webdesigner will expect and
provide a solution for.
The suggestion here is for IGNORING the webdesigner provided a solution of
adhering to the size attributes.

>Given that <img> is really just a left-over special case of
><object>, I don't see why its behavior should be different.

Becuse the spec sais they ARE different.
I don't care if you think <div>s should be displayed upside down or <table>
shouldn't be diplayed at all, as long as it's in the spec I would expect a
working browser to behave according to spec and not how you would like.

The whole issue here isn't which method of displaying is the correct one
(because they are both correct to the spec) but which one to choose for a
graphical browsers "default when size is specified". It is already decided that
if size is NOT specified, alt should be displayed inline.

Personally if there is not even a possibility for a user to manually controll
the behaviour I will be forced to start using style="" to force imagesizes
anyway, since the current implementation breaks layout for me an unacceptable
manner.
Isn't a userpreferance really a better solution?

>I don't see why its behavior should be different. And the "it worked
>in NS 4.x, it should work now" argument is a non-argument that's already been
>rejected in the two cases above.  Just because people want the hacks and browser
>bugs they've been using to go on forever and never have to do anything right
>doesn't mean they should get it.

The "keep reserved space" is perfectly correct according to spec so this has
noting in common with "old bugs and hacks".

>only coherent argument I've seen for this behavior is that "we used to
>do it".  

I made a list earlier, if you missed it here it is again

* It keeps pages from constantly having to reflow if imagedata isn't avaliable.
* Pages are and have been designed counting on this behaviour.
* Users expect a browser to behave like this.
* This is how EVERY other GRAPHICAL browser I've seen does it and has done for
years.

To this add that is 100% correct behaviour in regard to the specs.

The question is really, is there strong enough resons to change this legacy
behaviour with all the negative side effects it will generate?
I think not while others think there is.
Also I'd be satisfied with a user pref compromize, but apparently everyone else
is not (and their arguments does have merit also in my ears).

These ARE 2 two real issues here and nothing else.
To keep this post to a reasonable size, I have trimmed my reply
drammatically (the original reply to all the points raised was around
600 lines long). If you do not see a reply to one of your points, it
means I thought it was either redundant (i.e. already answered
elsewhere in this bug) or silly. If you disagree, please restate your
question or argument and I will attempt to answer it.


Skewer:

> I think what we need to do is distinguish between cases where the
> *viewer* decides not to load images and where the *image itself*
> doesn't load due to unexpected circumstances (broken link or busy
> server).

Not really -- IMHO well designed pages would cope well with all these
scenarios. I posted an example before of how this could be achieved.


> ... imagemap ...

HTML explains how image maps should be made accessible -- if the image
is not available, then alt texts should be used to make a menu. (That
would certainly be better than an image map where you have to guess
where to click, IMHO.)


> Welcome to my <IMG ALT="A picture of a dog"><BR>
> web page.
>
> Yes, it is a poorly designed HTML page, but we should be prepared
> for that.

Imagine how it would look in lynx, or sound to someone browsing the
web aurally (e.g. using an audio web browser while driving the car, or
for blind users) or on a cell phone, or...

Why should we encourage bad design?



inquisition@unforgettable.com:

>> I apologise, for I must have been unclear. The size of the image is
>> irrelevant to the page's _meaning_.
> The color of the page is irrelevant to the page's _meaning_. But if
> it used black text on a black background, where would that leave it?

Oddly enough, that was going to be my next argument. If an author sets
the text and background to the same colour, should we change the
colours to make it readable, or should we instead do what he said?
IMHO, we should do the second, because that encourages better
practice.


>> Designers need to be shown why for a minority of their users
>> (mainly disabled users) their alt text is of an extremely poor
>> choice.
>
> Perhaps.. or perhaps those designers just don't care.

That's the problem! They don't! They should! (IMHO)


>>> [...] you have an ego the size of a zeppelin [...]
>>
>> I welcome advice on how to explain this better. What part of my
>> argument do you not agree with?
>
> The part where you present yourself as the ultimate authority on the
> spec, and your personal interpretation as the only correct one?

I don't want to be perceived as the ultimate authority on the spec,
apologies if that is how I come across. Yes, I believe my personal
interpretation is the only correct one -- don't you think _your_
personal interpretation is the only correct one? (If you don't, then
does that means you agree with me?)


> I've heard this before, and my answer was the same as it is now: by
> all means, do encourage good practices, but don't try to do it by
> forcing people to do it your way or else.

Where am I _forcing_ anyone to do anything??? My way even lets authors
specifically get the behaviour _you_ want by using appropriate CSS,
your way doesn't! It looks to me like _you_ are forcing authors to do
what _you_ want, not the other way around.


>> Layout is important -- and certainly not irrelevant 
>
> ...and therefore, should be preserved, if possible.

...which it isn't if the image is not available in the first place.
The layout -- the look of the page -- is already broken, the only
thing keeping the size the same will do is crop the alt text. To draw
a parallel with your arguments: if you think only the positions and
sizes count for the layout, then we could just stop supporting images
and just put boxes in the right place, no?


> Ideally, yes, but in many cases a page can be well-designed without
> being this compatible. For instance, many pages were never intended
> to be viewed on a cellphone.

A well designed page will look (sound, feel, smell) good on _all_
platforms, not just those the author has seen.


> Search engines could care less whether Mozilla preserves boxes or
> not, so this is a non-issue.

You missed the point.

Mozilla does it the way I describe -> authors write better pages ->
search engines get more sensible alt text.

Mozilla does it your way -> authors write worse pages -> search
engines get nonsense alt text to index.


> As for the people on slow connections.. well, surely that's their
> problem, isn't it?

Thanks, I'm glad you are looking out for everyone's interests here and
not just yours.

Tell you what, since we have a pref, why don't we set it to the way
that helps most people and you can change it on your installation to
be the way you want it?


> A few years ago, I complained that Mozilla wasn't compatible with my
> hardware (at the time, a 68k Mac) and found no sympathy; I see no
> reason why some poor bastard with a 9600 baud modem should be
> treated any differently.

A 36.6k modem is slow enough for this to matter, and a huge number of
people have connections slower than that.



Brendan Eich:
>
> Why are you people arguing in a resolved bug?

Because that is the relevant forum for this issue, and gives a good
way of referring back to the argument in other bugs.


> If you really want mozilla.org staff to render a judgment here,

I do not think anyone is advocating a change in this bug. If they
were, the bug would presumably have been reopened.


> Please take it to a newsgroup if you must keep beating this dead
> horse.

What harm does it do to have this discussion in this bug?



Stefan Huszics:

> Your won't have empty boxes anyway, _unless_the_designer_deliberatly_
> _has_specified_theses_boxes_.

...which of course is the best practice, to reduce reflows in the
general case.


>> * Concentrates on presenting user with actual content, instead of on what's
broken.
> Albeight to the cost of the page constantly resizing before it's
> loaded and text jumping around.

Er, you just indirectly argued that that was ok behaviour:

> I don't know how many times I've said this now but inline alt IS the
> default behaviour with an <img>. It ONLY when you SPECIFICALLY state
> a size that you will get boxes. Can't you see the difference?

Why is it ok for a page to reflow and change sizes when the images are
present (the most common case) but not when images are broken (very
rare nowadays)?


>> * User is able to navigate the page faster without being distracted
>> * by useless >> data.
>
> When the page has finished loading... before that he won't be able
> to navigate at all since the page will constantly reflow.

See above.


>> * The *sane* behaviour, opposed to a fubar legacy one.
>
> And of course performance penalties to be payed is compleatly irrelevant or at
> least you have to be insane to bother with that aspect.

Same argument again. See above.


>> * Encourages authors to create well formed pages.
> Please state where my page is "broken" to make it NON well formed?
> Did you even check the links?

He didn't mean "well formed" in the strictly formal sense, he meant it
in the sense of a well designed page.


>> * All previous versions of Mozilla and Netscape 6 behave like this.
> That is simply not true. You obviously havn't been testing Mozilla
> for very long.

ROFL. I can't even begin to argue that point, it is so patently untrue
on all counts.


> Overriding specifed attributes and forcing inline alt hasn't been
> the case always.

That is technically correct, there were a few months in 1999 where we
did it your way, and there have been a few days recently where we
changed back to that behaviour in quirks mode.


>> There is *nowhere* in the spec that suggests that the alt attribute
>> should be used as the contents of a box the size of the image.
>
> There is also *nowhere* in the spec that suggest a browser should
> compleatly ignore non depreceated attributes in an arbitrary
> fassion.

Exactly. So we're both arguing a position compatible with the exact
wording of the (famously vague) spec.


> What part of the specs are you going to ignore next?

What part of the spec am I ignoring _now_?


> Why don't we just go down the MS road and implement just the parts
> of HTML a small cohsen group think is useful.

What _are_ you talking about?


>>> You seem to be able to infer a lot from the word "alternate", and
>>> anyway, it is merely conjecture. My conjecture is that ALT stands
>>> for 'Alternate Text' which is to be presented in place of the
>>> image
>> Exactly -- instead of the image, put text. Where else in HTML does
>> text suddenly acquire a fixed size box??
> Everywhere where the author has DELIBERATLY specified that there
> should be a box.

Er. Point me to a single such case of "everywhere" in the spec.


> But I guess unnessecary reflows due to ignoring these attributes and
> collapsing reserved space are ok?
>
> Please explain why one type of reflow is better then another as I
> view them to be equally bad.

Because one kind of reflow will happen many, MANY times more than the
other. Therefore while on a per-reflow basis they are equally bad, on
a total user experience basis the one that happens the most is the
worst.


> So you mean if it would have said style="width:xpx;height:ypx" then
> everything would be fine?

Assuming you also give the right 'display' type, yes (width and height
on a non-replaced element are ignored in CSS if display is 'inline',
the default for an <img> tag).


> An alt-text does also NOT convey the compleate meaning of an image.
> The size alone of an image represents something which is compleatly
> lost with inline alt.

So an image changes meaning if it has a different size?


>> A longdesc page for a flower image would have been many paragraphs
>> long. Just take a look at the D-link images in the CSS spec for
>> examples.
>
> Could you give a link please, it's a long spec.

This is a good example:

   http://www.w3.org/TR/REC-CSS2/images/longdesc/clip-desc.html

(Note. The alt texts in the CSS2 spec are _not_ good examples of alt
texts. We intend to fix this in future releases of the CSS specs.)


> Also for me you page also doesn't even show up in Lynx (instead it tries to DL
> it and save to HD...). How greate is that.

Lynx doesn't support XML, I should maybe have made the page HTML
instead of XHTML but I was following your lead. Sorry about that.


> This likewise does not affect the inline alt issue in any way, but if we are
> going to nitpick you are aslo still missing the (eg) <?xml version="1.0"
> encoding="iso-8859-1"?> part on your page

It is optional and redundant in this case since the page is returned
as text/xml and not text/html.


> I made a list earlier, if you missed it here it is again
>
> * It keeps pages from constantly having to reflow if imagedata isn't
> * avaliable.

At the expense of making them reflow when imagedata _is_ available --
see above.


> * Pages are and have been designed counting on this behaviour.

This is why I am not fighting the fact that we do this in quirks mode.


> * Users expect a browser to behave like this.

How do you know? Most non-geek users I've spoken to don't expect
anything in particlar.

Comment 120

18 years ago
>> Welcome to my <IMG ALT="A picture of a dog"><BR>
>> web page.

> Imagine how it would look in lynx, or sound to someone browsing the
> web aurally (e.g. using an audio web browser while driving the car, or
> for blind users) or on a cell phone, or...
> Why should we encourage bad design?

I agree that the behavior of such a page would be unacceptable in many scenarios
like those (although I wouldn't allow any aural browser under my control not to
read that as "Welcome to my Image A picture of a dog Web page"). However, it's
not up to Mozilla to be the police for these things. A gallery page, which I've
used as an example somewhere before, would have an infinitesimally small
audience using such platforms--and, with any luck, a decent-sized audience using
graphical browsers like Mozilla. Sometimes, images don't load. Why should I be
punished, of all things, for holding strictly to a W3C standard, which contains
absolutely *nothing* that you've managed to demonstrate for us to suggest that
the dimensional-placeholder behavior is wrong?

Mozilla's goal shouldn't be to completely distort a page that isn't perfectly
designed; Netscape 4 did that, and as a result both end-users and developers
pushed it aside as a mere novelty. (I mean, NS4 is a damn nice table validator,
but it does me absolutely no good as an everyday web browser.) Don't concern
yourself with negligent web developers; they'll get what they deserve
eventually. They aren't worth making Mozilla flip out every time it finds a
broken image. If a web developer wants to make his page flow the way you
recommend so badly, there *is* a pref.
Might it be sensible to file an RFE on reducing the size of the font used to
render the alt text (down to the configured minimum font size, now that we
support that) if it's too long to fit in the box?

This debate aside, that would be a good thing.

Gerv

Comment 122

18 years ago
Gerv: ALT text obscured by the placeholder is bug 109410.
> Mozilla's goal shouldn't be to completely distort a page that isn't perfectly
> designed; Netscape 4 did that, and as a result both end-users and developers
> pushed it aside as a mere novelty.

If "pushed aside" means that after 4 years of being (image) obsolete it still
has more than (image) 15% of the marketshare despite the competition being 
(image) significantly better in all respects and using (image) illegal tactics
to promote their product (image) using one of their other monopolies (image),
then I am very happy for (image) Mozilla to be "pushed aside".

Oops, maybe it would have been (image) better if my renderer placed images
inline (image) (image) instead of doing some other (image) behaviour, like
telling the user (image) about the (image) images (image) that they don't care
about anyway since they can't see them.

Or did you really (image) want to (image) know about the images I would have
embedded in this (image) comment if bugzilla supported (image) images?


> Don't concern yourself with negligent web developers; they'll get what they 
> deserve eventually.

Er, how, exactly, if no browser does anything about it?


> They aren't worth making Mozilla flip out every time it finds a
> broken image. If a web developer wants to make his page flow the way you
> recommend so badly, there *is* a pref.

I'm not sure exactly what you think a "pref" is but there isn't much a web
author can do about the prefs of his readers' browsers.


Gerv: your idea is dependent on bug 11011.

Updated

18 years ago
Depends on: 108799

Comment 124

18 years ago
>> Don't concern yourself with negligent web developers; they'll get what they 
>> deserve eventually.
>
>Er, how, exactly, if no browser does anything about it?

If no browser at *all* cares about this, it's a non-issue. If your Lynx and
aural browsers care, though, as soon as they show up the website has lost a
share of its market because the developer didn't make his page accessible. Let's
let that be his problem and not ours. If web designers want to screw their Lynx
users, it's their loss (of what, one user out of every thousand? ten thousand?
hundred thousand?).

>> They aren't worth making Mozilla flip out every time it finds a
>> broken image. If a web developer wants to make his page flow the way you
>> recommend so badly, there *is* a pref.
>
>I'm not sure exactly what you think a "pref" is but there isn't much a web
>author can do about the prefs of his readers' browsers.

You just got through saying our unusual behavior for ALT text is present in the
interest of developers for Lynx/aural pages. It's useless to the developer's
readers (they don't care what the page looks like in Lynx/aural browsers).

Comment 125

18 years ago
> Oddly enough, that was going to be my next argument.
> If an author sets the text and background to the same
> colour, should we change the colours to make it
> readable, or should we instead do what he said?
> IMHO, we should do the second, because that
> encourages better practice.

In other words, you want to honor attributes that have been explicitly 
specified by the author, rather than changing them in a way that you 
believe makes the page easier to read. Good! Then I expect you'll 
abandon this argument immediately, since you've been pushing for the 
opposite, and obviously even you disagree with you. ;P

> > Perhaps.. or perhaps those designers just don't care.
> 
> That's the problem! They don't! They should! (IMHO)

Then go evangelize them! Nothing stops designers from writing better 
ALT text if they want to, and none of your rhetoric has (or ever *will*) 
demonstrated otherwise, since it's irrelevant to any reasonable real-world 
situation.

> Yes, I believe my personal interpretation is the
> only correct one -- don't you think _your_ personal
> interpretation is the only correct one?

My personal interpretation is the only one that makes any sense. There's 
nothing wrong with your interpretation, aside from the fact that it's idiotic, 
helps no one who exists outside your mind, and serves only to punish 
people for (a) using Mozilla and designing pages that aren't in accordance 
with your personal vision, or (b) using Mozilla and viewing pages that 
aren't in accordance with your personal vision.

> The layout -- the look of the page -- is already broken,
> the only thing keeping the size the same will do is
> crop the alt text. To draw a parallel with your arguments:
> if you think only the positions and sizes count for the
> layout, then we could just stop supporting images and
> just put boxes in the right place, no?

But only the positions and sizes DO count for the layout. I don't care what 
the "theme" of the design is, what I care about is if I tell the browser that 
there's an 110 x 76 thingy here, it bloody well renders a 110 x 76 thingy.

Everyone likes examples. Here's one:

[                        ] BIG TEXT! [  ][         ]
[                                                  ]
[                        ]
|                        |  text text text text text
|                        |  text text text text text
|                        |  text text text text text
[                        ]  text text text text text

vs.

BIG TEXT! text text text text text text text text text text text text text text text text 
text text text text

Hmm, gee, which one would look better in a graphical browser? (Which 
one is more likely to be comfortable to read at any resolution higher than 
640 x 480?) You get three guesses, and the first two don't count.

> A well designed page will look (sound, feel,
> smell) good on _all_ platforms, not just those
> the author has seen.

"A well designed browser will look (sound, feel, smell) good on _all_
platforms, not just those the author has seen."

Righty-o. Mozilla doesn't work on my Gameboy, so it must be a piece of 
****. I'll tell Slashdot right away. Or you could rethink that position...

> Mozilla does it the way I describe -> authors write
> better pages -> search engines get more sensible alt text.

Mozilla does it the way I describe -> you bloody well drop this spanish 
design inquisition and just evangelize people like I keep telling you to -> 
authors write better pages -> search engines get more sensible alt text -> 
people don't abandon Mozilla when it mangles layouts

Hey, I've got a great idea (disclaimer: this is SARCASM). How about we 
build an HTML validator into Mozilla, and have it refuse to render any page 
that reports validation errors? Surely that would encourage better design!

> Tell you what, since we have a pref, why don't we
> set it to the way that helps most people and you
> can change it on your installation to be the way
> you want it?

So in other words, the browser would behave normally by default, and if 
for some reason users would rather render pages in the way that you 
suggest, they could explicitly set it to do so? Sounds fine to me.

> A 36.6k modem is slow enough for this to matter,
> and a huge number of people have connections
> slower than that.

If you meet them, tell them to cry me a river.
On the general subject of accessibility: encouraging authors to use accessible
designs is, in fact, doing them a considerable favor.  There have been
successful lawsuits (most notably over the Sydney Olympics site, Maguire vs.
SOCOG) because sites used an inaccessible design.  This verges, IMO, on the
utterly stupid, but there is, in fact, a legal risk involved in inaccessible
design.  (Look at some of the suits brought under the ADA if you don't believe
me--such lawsuits may sound like arrant nonsense, but people have fought and won
sillier cases.)  You might also want to look into Bugzilla's fcc508 keyword,
what it means, and why we have it.  (In fact, cc'ing aaronl, who should be
weighing in on this as the local accessibility guru).  Much as it would no doubt
cheer you to write off the disabled as an irrelevant minority, that's clearly a
poor strategy, both for authors and UA implementors (NFB vs. AOL, anyone?).

Some specific points:

>Then go evangelize them! Nothing stops designers from writing better 
>ALT text if they want to, and none of your rhetoric has (or ever *will*) 
>demonstrated otherwise, since it's irrelevant to any reasonable real-world 
>situation.

Well, actually, it *has* been demonstrated otherwise.  People do indeed shorten
otherwise useful ALT texts into uselessness or omit them entirely because of
this method of display, which you would have discovered had you searched for
discussions of ALT text in the archives of the various W3C WAI mailing lists.  I
suppose coming to this discussion with awareness of the historical background of
the issue would be too much to ask of you, but c'est la vie.

>> Yes, I believe my personal interpretation is the
>> only correct one -- don't you think _your_ personal
>> interpretation is the only correct one?

>My personal interpretation is the only one that makes any sense. There's 
>nothing wrong with your interpretation, aside from the fact that it's idiotic, 
>helps no one who exists outside your mind, and serves only to punish 
>people for (a) using Mozilla and designing pages that aren't in accordance 
>with your personal vision, or (b) using Mozilla and viewing pages that 
>aren't in accordance with your personal vision.

Well, no, that's also incorrect.  The position that showing boxes around ALT
text with dimensions equivalent to the height and width of the image is a bug,
and that the alt text should not be cropped, has been endorsed by Alan J.
Flavell (author of the only comprehensive FAQ on ALT text use I've found), and
members of the W3C WAI have consistently characterized this as poor design for
its failure to expose complete ALT texts.  (Indeed, one suggestion seriously
discussed was to recommend in authoring guidelines that the height and width
attributes not be used, so as to avoid causing this!)

At this point, your best move would probably be to denounce Hixie, Flavell,
myself, the W3C, and possibly the Federal Reserve as a conspiracy of elitist,
ivory-tower airheads.  Put some useless exposition between that part and the
part where you appeal plaintively to the W3C's specifications to avoid appearing
hypocritical.

Alternately, you could simply dismiss the whole concept of accessibility as a
fraud and a sideshow.

> The layout -- the look of the page -- is already broken,
> the only thing keeping the size the same will do is
> crop the alt text. To draw a parallel with your arguments:
> if you think only the positions and sizes count for the
> layout, then we could just stop supporting images and
> just put boxes in the right place, no?

But only the positions and sizes DO count for the layout. I don't care what 
the "theme" of the design is, what I care about is if I tell the browser that 
there's an 110 x 76 thingy here, it bloody well renders a 110 x 76 thingy.

[snip example]

So...you've discovered that an author who doesn't consider the fact his images
may not load can author pages that look bad when that happens, just as someone
who's set a black background and text in HTML and a background image in CSS will
produce a page that looks bad when someone surfs it with CSS turned off.  I
suggest that you contact the W3C immediately and have them write a standard in
which nothing that looks bad can ever be written.  Maybe Kibo too, this sounds
like a job for the founder of HAPPYNET.

>>"A well designed browser will look (sound, feel, smell) good on _all_
>>platforms, not just those the author has seen."

>Righty-o. Mozilla doesn't work on my Gameboy, so it must be a piece of 
>crap. I'll tell Slashdot right away. Or you could rethink that position...

I think Hixie meant to write "web page" here, if I'm not mistaken, but I don't
speak for him.

>> Mozilla does it the way I describe -> authors write
>> better pages -> search engines get more sensible alt text.

>Mozilla does it the way I describe -> you bloody well drop this spanish 
>design inquisition and just evangelize people like I keep telling you to ->
>authors write better pages -> search engines get more sensible alt text ->
>people don't abandon Mozilla when it mangles layouts

Well, no.  History shows us (going waaaaay back to NS 1.1 and multiple <head>
tags) that making browsers not do buggy things is, in fact, what induces web
authors to fix their content.  Not to mention that your proposal would
materially impede evangelism, as has already been explained, and concluded upon,
by people with a more substantial grasp of the subject.

>Hey, I've got a great idea (disclaimer: this is SARCASM). How about we 
>build an HTML validator into Mozilla, and have it refuse to render any page 
>that reports validation errors? Surely that would encourage better design!

You strike nearer to the truth than you know, grasshopper.  I don't think it
could be done in one fell swoop, but were the major browsers indeed to work
their way up to this level of strictness over several releases, by the time they
got there (it would, admittedly, take years), 90% of the web would be validating
HTML.  When browsers stop supporting some misfeature like this, people whine,
cry, shriek, and moan...and when it doesn't come back, they fix their pages. 
Ultimately, web authors really do follow what the browsers do; how else to
explain the profusion of "Best Viewed with $BROWSER Version Foo or Greater"?

>> Tell you what, since we have a pref, why don't we
>> set it to the way that helps most people and you
>> can change it on your installation to be the way
>> you want it?

>So in other words, the browser would behave normally by default, and if 
>for some reason users would rather render pages in the way that you 
>suggest, they could explicitly set it to do so? Sounds fine to me.

Only because your definition of "normal" is a couple of sigma away from that of
anyone with any authority or reputation on this subject.  Enjoy the blue sunsets
or whatever you get in your world, though.

>> A 36.6k modem is slow enough for this to matter,
>> and a huge number of people have connections
>> slower than that.

>If you meet them, tell them to cry me a river.

I'll do that 
Skewer:
>>> Don't concern yourself with negligent web developers; they'll get
>>> what they deserve eventually.
>> Er, how, exactly, if no browser does anything about it?
> 
> If no browser at *all* cares about this, it's a non-issue.

My bad, I meant "no well-deployed browser".


> If your Lynx and aural browsers care, though, as soon as they show
> up the website has lost a share of its market because the developer
> didn't make his page accessible. Let's let that be his problem and
> not ours. If web designers want to screw their Lynx users, it's
> their loss (of what, one user out of every thousand? ten thousand?
> hundred thousand?).

Assuming it's one out of every hundred thousand. That means that in
the UK alone there are 6000 people affected by this. 6000 people who
are totally unable to access/use many websites because web authors do
not think they matter. Yet if we fixed well-deployed browsers such as
Mozilla's derivatives so that web authors were more inclined to do the
right thing, the number of websites they would have problems with
would drop significantly.

Are these 6000 people not important enough for us to care?


>>> They aren't worth making Mozilla flip out every time it finds a
>>> broken image. If a web developer wants to make his page flow the
>>> way you recommend so badly, there *is* a pref.
>>
>> I'm not sure exactly what you think a "pref" is but there isn't
>> much a web author can do about the prefs of his readers' browsers.
> 
> You just got through saying our unusual behavior for ALT text is
> present in the interest of developers for Lynx/aural pages. It's
> useless to the developer's readers (they don't care what the page
> looks like in Lynx/aural browsers).

The point is not to give web developers who care a useful tool. They
already have several. The point is to give web developers who do NOT
care, usually through ignorance, a reason to care.


inquisition:
>>> Perhaps.. or perhaps those designers just don't care. That's the
>>> problem! They don't! They should! (IMHO)
>
> Then go evangelize them!

Oh, I do. A lot.

There are millions of them, though, and only one of me. Having a web
browser Do The Right Thing here would make that task a whole lot
easier.


> Nothing stops designers from writing better ALT text if they want
> to, and none of your rhetoric has (or ever *will*) demonstrated
> otherwise, since it's irrelevant to any reasonable real-world
> situation.

No, nothing stops them. But nothing much encourages them either.


>> Yes, I believe my personal interpretation is the only correct one
>> -- don't you think _your_ personal interpretation is the only
>> correct one?
> 
> My personal interpretation is the only one that makes any sense.

Does that mean you have an ego the size of a zepplin?


>> The layout -- the look of the page -- is already broken, the only
>> thing keeping the size the same will do is crop the alt text. To
>> draw a parallel with your arguments: if you think only the
>> positions and sizes count for the layout, then we could just stop
>> supporting images and just put boxes in the right place, no?
> 
> But only the positions and sizes DO count for the layout. I don't
> care what the "theme" of the design is,

There lies the fundamental disagreement we are having.

You think it is more important that the web browser render the page
using the exact geometrics that the author intended. In that case,
give up on HTML and CSS and use PDF. The web is not like that, it was
never intended to be like that. Read the introduction chapters of the
those two specs, it's quite clearly laid out.

I believe content is king, not layout. Layout is merely pretty sugar
on top. Important sugar, hence my being a CSS working group member.
But only sugar.


> 
> Everyone likes examples. Here's one:
> 
> [                        ] BIG TEXT! [  ][         ]
> [                                                  ]
> [                        ]
> |                        |  text text text text text
> |                        |  text text text text text
> |                        |  text text text text text
> [                        ]  text text text text text
> 
> vs.
> 
> BIG TEXT! text text text text text text text text text text text
> text text text text text text text text text
> 
> Hmm, gee, which one would look better in a graphical browser?

As I said, here is where we disagree. I much prefer the second one to
the first one. The first one would probably look nicer if the images
were present, but if they are not then _I_ (as a reader) don't caree
about them.


> Which one is more likely to be comfortable to read at any
> resolution higher than 640 x 480?

Which one is more likely to be comfortable to read at _any_
resolution? The second one.


>> A well designed page will look (sound, feel, smell) good on _all_
>> platforms, not just those the author has seen.
> 
> "A well designed browser will look (sound, feel, smell) good on
> _all_ platforms, not just those the author has seen."
> 
> Righty-o. Mozilla doesn't work on my Gameboy, so it must be a piece
> of crap. I'll tell Slashdot right away. Or you could rethink that
> position...

You argued against your own rhetoric there, not my statement.

A well designed page will look (sound, feel, smell) good on _all_
platforms, not just those the author has seen. That is the whole POINT
of HTML and CSS and other W3C specs.


>> Mozilla does it the way I describe -> authors write better pages ->
>> search engines get more sensible alt text.
> 
> Mozilla does it the way I describe -> you ... just evangelize people
> ... -> authors write better pages -> search engines get more
> sensible alt text -> people don't abandon Mozilla when it mangles
> layouts

You think I will be able to evangelise more people than Mozilla will
reach? Either you significantly over estimate my abilities, or you
seriously under estimate Mozilla's popularity.

If the former, then please, I apologize, for I am not the amazing
evangelist you think I am. If the later, then why do you care so much
anyway? It's not like Mozilla is going to be used by anyone.


> Hey, I've got a great idea (disclaimer: this is SARCASM). How about
> we build an HTML validator into Mozilla, and have it refuse to
> render any page that reports validation errors? Surely that would
> encourage better design!

We have. This is the way XML is designed: a broken XML page will not
render in an XML-compliant browser. The W3C decided about 4, maybe 5
years ago that bad markup was one of the biggest problems on the web
and that is why one of the cornerstones of XML is that it must be well
formed or else not render.

The fact that you thought you were being sarcastic and yet the W3C
agreed with your ideas may indicate to you the mindset behind the W3C,
and behind the HTML spec, and thus behind the alt attribute.


>> Tell you what, since we have a pref, why don't we set it to the way
>> that helps most people and you can change it on your installation
>> to be the way you want it?
> 
> So in other words, the browser would behave normally by default, and if 
> for some reason users would rather render pages in the way that you 
> suggest, they could explicitly set it to do so? Sounds fine to me.

Ok, how about the opposite? How about the browser behave as I describe
by default, and if for some reason users would rather render pages in
the way that you suggest, they could explicitly set it to do so?


>> A 36.6k modem is slow enough for this to matter, and a huge number
>> of people have connections slower than that.
> 
> If you meet them, tell them to cry me a river.

It seems to me you have your own interests at heart here rather than
the majority of Mozilla's users'.

Comment 128

18 years ago
> Having a web browser Do The Right Thing here
> would make that task a whole lot easier.

And putting poison (or just something that tasted vile) in hamburgers 
would make people eat healthier.. but even though that's a pretty close 
analogy for what you're trying to do, it is hardly the Right Thing.

If you want people to change for the better, you have to give them carrots, 
not threaten them with sticks. If Mozilla wants to ruin my pages, I'll just 
drop support for it and design solely for IE. Think I can't?

Think I'll be the only one?

> No, nothing stops them. But nothing much encourages them either.

If those 6000 blind people in the UK can't encourage them, maybe they 
really AREN'T important after all.

Incidentally, I'm assuming you're getting that figure by taking some fraction 
of the UK population. I doubt you've taken into account that (a) not 
everyone owns a computer (b) not everyone has internet access (c) blind 
people are less likely to have computers than non-blind people. I wouldn't 
be surprised if the number of actual blind internet users in the UK was on 
the order of a hundred.

> > My personal interpretation is the only one that makes any sense.
> 
> Does that mean you have an ego the size of a zepplin?

Possibly. But I wasn't the one who wrote a lengthy manifesto explaining 
what the W3C meant when they drafted the spec. My arguments are 
based on usability, expected behavior, and common sense.

> You think it is more important that the web browser
> render the page using the exact geometrics that the
> author intended. In that case, give up on HTML and
> CSS and use PDF.

I think that the browser should render the page using the exact 
geometrics that the author SPECIFIED. If it can't do that, we might as well 
throw CSS away, and Mozilla.org has wasted an inordinate amount of 
time making a modern browser when it could have just debugged Mosaic.

> The web is not like that, it was never intended to be
> like that.

Intentions be damned; the web *is* like that. Look around, man! The web 
is not some W3C ivory tower, and this is not 1993!

> I believe content is king, not layout. Layout is
> merely pretty sugar on top. Important sugar,
> hence my being a CSS working group member.

By saying so, you demonstrate a fundamental misunderstanding of the 
medium.

Everything is layout. If you mark up a page with tables and invisible GIFs, 
that is layout. If you mark it up with floats and margins and positioning, 
that is layout. If you ignore all of that, and then choose to render everything 
inline, then guess what.. that is *also* layout. The fact that it's the same 
layout as a plain typeset page, that it's the default layout that everyone is 
used to from reading books and working with text editors, is irrelevant. 
The W3C wants to divorce presentation from content on the theory that you 
can safely do so, and sometimes you can, but sometimes you CAN'T. And 
I don't think that it's the browser's job to determine which layouts are 
acceptable and which ones should be replaced with it's own personal 
interpretation of what good layout would be.. even if the browser were 
capable of making such a decision, which it is not. That's why web 
designers are still made of meat.

> Which one is more likely to be comfortable to read at _any_
> resolution? The second one.

Disproportionately wide text columns (such as the kind you're likely to see 
at the full window width at any resolution greater than 640 x 480, and even 
then you're pushing it) are difficult to read. As any *competent* web 
designer, or indeed graphic designer, pagesetter, etc, should know.

If you had just explained at the beginning that you were making this 
proposal from the standpoint of never having designed a web page in the 
real world, and not having any practical knowledge about web design, this 
would all have been much simpler.

> A well designed page will look (sound, feel, smell)
> good on _all_ platforms, not just those the author
> has seen. That is the whole POINT of HTML and
> CSS and other W3C specs.

It's an unrealistic goal. Web pages, like software, may have unavoidable 
minimum requirements, or no relevance to a certain market or device. No 
one's going to use Lynx to look at an image gallery, so image galleries 
don't need to be Lynx-compatible, and it's not a flaw in their design if they 
aren't. People aren't going to use their cellphones to browse someone's 
personal web page, so it's not necessary to make personal web pages 
that play nice with cellphones. And so forth.

You NEED to take a reality check. Your arguments are being hampered by 
the growing mass of evidence that you have no idea what you're talking 
about, even if they weren't frequently contradictory.

> You think I will be able to evangelise more people
> than Mozilla will reach? Either you significantly over
> estimate my abilities, or you seriously under estimate
> Mozilla's popularity.

You personally? Maybe not. So you get in touch with people who can. Get 
articles in design e-zines or popular columns. Find those 6000 blind 
people and get them to bug designers; by and large, they can be nagged 
into doing things a certain way, as long as it works (and sometimes even 
when it doesn't; there were people playing with PNGs and CSS back 
when support was almost nonexistent).

> We have. This is the way XML is designed: a broken
> XML page will not render in an XML-compliant browser.

Which I fully support, but we are not talking about XML.

> The fact that you thought you were being sarcastic

You utterly missed my point. Let me try again:

"Hey, I have a great idea! Let's make Mozilla refuse to render 95% of all 
web pages!"

> Ok, how about the opposite? How about the
> browser behave as I describe by default, and if for
> some reason users would rather render pages in
> the way that you suggest, they could explicitly set it
> to do so?

Because the default setting should be one that would be preferred by 
most users.

> It seems to me you have your own interests at
> heart here rather than the majority of Mozilla's users'.

It seems to me that you think that everyone who uses Mozilla is either 
blind or surfing with images off. The guys who wrote libpr0n will be 
crushed, I assure you.
inquisition@unforgettable.com:
> [ snip lots of irrelevant tangential pointless rhetoric]
>
> If those 6000 blind people in the UK can't encourage them, maybe they 
> really AREN'T important after all.

If you believe this then I'm afraid your goals are totally divorced of Mozilla's.


> My arguments are based on usability

Note that one of Mozilla's most prolific usability weenies disagrees with most
of your opinions.


> I think that the browser should render the page using the exact 
> geometrics that the author SPECIFIED.

As I said, this is where we fundamentally disagree.

There is no way this can work in the real world. Web pages have to work on many
different media, from normal computer screens at 1600x1200 to PDAs at 70x50. The
industry (Microsoft, Nokia, etc) are working together to make this possible.

You seem to be stuck in 1998, when the web was IE and Netscape and that's it.
This is no longer the case. We are now in 2001 and the industry leaders are
moving the web to be cross-platform.


>> A well designed page will look (sound, feel, smell) good on _all_ platforms, 
>> not just those the author has seen. That is the whole POINT of HTML and
>> CSS and other W3C specs.
> It's an unrealistic goal.

Industry experts disagree.


> No one's going to use Lynx to look at an image gallery, so image galleries
> don't need to be Lynx-compatible, and it's not a flaw in their design if they 
> aren't.

I know several people who have used Lynx to browse image galleries. A well
designed image gallery would allow that.


> People aren't going to use their cellphones to browse someone's personal web 
> page, so it's not necessary to make personal web pages that play nice with 
> cellphones. 

Wow, you really are stuck in the WWW dark ages. You may wish to take a look at
Japan, where the majority of the population browses the web (not the WAP-based
web, the HTML-based web!) on mobile phones on a daily basis.


> You NEED to take a reality check.

No, _you_ need to take a reality check. It appears you have missed the fact that
*technology is moving on*. We are no longer in a one-target web.


> Your arguments are being hampered by the growing mass of evidence that you 
> have no idea what you're talking  about, even if they weren't frequently 
> contradictory.

I challenge you to quote a single contradictory statement that I have made.


>> Ok, how about the opposite? How about the browser behave as I describe by 
>> default, and if for some reason users would rather render pages in the way 
>> that you suggest, they could explicitly set it to do so?
>
> Because the default setting should be one that would be preferred by 
> most users.

What evidence do you have for the suggestion that your idea is preferred?

I have evidence to indirectly support that my idea is preferred: Netscape 6.2
has my behaviour. Internet Explorer 6.0 has yours. N6.2 is more popular than
IE6.0 at download.com, based on the user ratings.


> It seems to me that you think that everyone who uses Mozilla is either 
> blind or surfing with images off. The guys who wrote libpr0n will be 
> crushed, I assure you.

I own and operate libpr0n.com in conjunction with libpr0n's authors. Trust 
me when I say that they would not be in the least bit crushed if I thought that.

Comment 130

18 years ago
Good god, talk about a discussion that belongs in the newsgroups.

Comment 131

18 years ago
> If you believe this then I'm afraid your goals are
> totally divorced of Mozilla's.

I mean to designers. Obviously those 6000 blind Brits are important to *
you*, or else you wouldn't be trying to make Mozilla cater to them at the 
expense of everyone else who has functional organs.

> Note that one of Mozilla's most prolific usability weenies
> disagrees with most of your opinions.

If he's not contributing to this thread, his opinion is worthless to me. I 
could easily invent a thousand fictional people who agree with me; for that 
matter, I've talked to about a dozen users and designers (various friends 
of mine) who all think you're nuts; so much for hearsay.

> > I think that the browser should render the page using the exact 
> > geometrics that the author SPECIFIED.
> 
> As I said, this is where we fundamentally disagree.

And this is where you contradict yourself. In every single comparison I've 
made to this situation, you've agreed that layout is of some importance 
and that the browser should honor the author's (valid) code rather than 
ignoring it. But when it comes to this one specific point, you keep saying 
that layout is irrelevant and that Mozilla should ignore the author and do 
things *its* way.

HTML and CSS aren't designed to force the creation of what you call "well-
designed pages". They're designed to give authors more than enough 
rope to hang themselves with. They have *provisions* for disabled users, 
non-compliant browsers, and the like, but - with the exception of requiring 
an ALT tag with every image, which didn't really help anybody, I think - they 
don't force people to use them.

If you want a "safe" standard, there is one: It's HTML 1. No tables, no 
colors, no fonts, nothing but simple typographic markup. If that's what you 
want, then as I said before, you should stop working on Mozilla, and 
update Mosaic instead. (Good luck getting anyone to use it.) Otherwise, 
you must accept that HTML 4 and CSS2 do *not* work like HTML 1, they 
will not always be "safe", and there's not a damn thing you can do about 
that.

> It appears you have missed the fact that *technology
> is moving on*. We are no longer in a one-target web.

Were we ever? No.. and yet, look at the web's evolution.

Let me remake this point, before we stray too far from it (as we are now 
doing). We are speaking of whether to ignore or preserve layout as 
specified by the author *in Mozilla*. That means that all of the following are 
utterly irrelevant:

- cellphones and PDAs (they do not run Mozilla).
- blind people (since they don't access the web visually, visual clipping is 
of no concern to them whatsoever).
- search engines (they do not use Mozilla, and since they don't access the 
web visually, visual clipping is of no concern to them whatsoever)
- Lynx (is not Mozilla, and displays ALT text inline)

And probably other classes of users as well, but there's no need (I hope) 
to provide an exhaustive list. Note that *nothing whatsoever* currently 
stops designers who want their pages to be more compatible with any of 
those from writing better ALT text; to use your words, those platforms 
"allow them to do so". (And as a matter of fact, many designers did start 
using ALT text in response to the whining of Lynx users, a relatively small 
demographic, so this shows that evangelism is not ineffectual.)

If you feel that any of these classes of users aren't being catered to 
sufficiently by designers, then you must evangelize them. Let me repeat 
that to make it perfectly clear:

EVANGELIZE THEM.
EVANGELIZE THEM.
EVANGELIZE THEM.

> I challenge you to quote a single contradictory
> statement that I have made.

I have done so, many times. Read my previous posts.

> What evidence do you have for the suggestion
> that your idea is preferred?

Most people prefer intact layouts to broken ones. This should be self-
evident.

But here's a better argument (and again I'm forced to repeat myself): my 
behavior is spec-compliant, my behavior is consistent with other popular 
browsers, my behavior is predictable, my behavior doesn't cause 
unnecessary page reflows. Yours is batting .250 (Netscape 6.2 is not a 
popular browser in terms of number of users, which is the only metric that 
designers and their employers are likely to consider).

It's a shame that CSS can't tell if an image is broken. (Unless there's 
something in CSS3 that does this; I haven't read it since it's still being 
drafted. Seems unlikely, though.) If it could, then I could just say, "Ian, just 
change your user style sheet."

> N6.2 is more popular than IE6.0 at download.com,
> based on the user ratings.

Which means exactly squat. How are the ratings generated? Who are 
these users? Are they comparing it to IE6, or to N6, or to N4? Are they 
being affected by anti-MS biases, or pro-Mozilla biases? Do they all 
specify that they prefer your behavior over mine? This is the most 
worthless statistic I've seen in quite a while, and it's sad that you find it to 
be compelling evidence, or expect anyone else to.

---------------------------------------------

I'm getting tired of this. Here's the bottom line: My behavior is more 
consistent, more predictable, more familiar, and offers better 
performance. Your behavior has no advantages over mine *whatsoever*, 
and is in fact nothing more than a misguided attempt to change design 
practices by punishing designers instead of evangelizing them.

Comment 132

18 years ago
Ian:

>> If no browser at *all* cares about this, it's a non-issue.
>
>My bad, I meant "no well-deployed browser".

And if Mozilla continues to allow extremists like you to control its behavior by
choking on bad design instead of tolerating it, Mozilla won't ever *be* a
well-deployed browser. It will just get less and less compatible until it ends
up being another Netscape 4 that renders a significant portion of webpages
*TOTALLY BLANK*.


> Assuming it's one out of every hundred thousand. That means that in
> the UK alone there are 6000 people affected by this. 6000 people who
> are totally unable to access/use many websites because web authors do
> not think they matter. Yet if we fixed well-deployed browsers such as
> Mozilla's derivatives so that web authors were more inclined to do the
> right thing, the number of websites they would have problems with
> would drop significantly.
>
> Are these 6000 people not important enough for us to care?

You seem to think that everyone in the UK has internet access. This is not the
case. <http://www.nua.com/> says that 15 million people in the UK use the
internet at home. One out of every hundred thousand would be only 150 people,
very many fewer than you claim (if it is even true that one out of every hundred
thousand uses an aural browser or Lynx).

Developers should care about these people. However, as a browser Mozilla does
not need to worry about these people. We don't need to worry about the
developers either. We are a *BROWSER*, not a *VALIDATOR*. We need to be
concerned with the end user, not the developer. Otherwise, as I said, Mozilla
will never suceed in the browser market. We can't control developers when they
can just say "Nobody uses that sucky little browser anyway, I'll just develop
for IE." It didn't work for NS4 and it won't work now. (In fact, have you
noticed at all how many sites *TOTALLY BLOCK OUT* Netscape 6 and Mozilla?)

> A well designed page will look (sound, feel, smell) good on _all_
> platforms, not just those the author has seen. That is the whole POINT
> of HTML and CSS and other W3C specs.

That is, unless there is one platform that chews up and spits out almost
everything you put into it... In which case that platform ends up being set
aside and ignored by developers (see previous paragraph). The worse Mozilla
gets, the fewer pages work in it (or even allow it at all). Right now developers
don't take Mozilla seriously because people like you are turning it into such a
terrible product to use as an everyday browser.

Comment 133

18 years ago
Guys... shut up already.  This bug is dead.  Move comments to the newsgroups or
at least another bug.
> I've talked to about a dozen users and designers (various friends 
> of mine) who all think you're nuts; so much for hearsay.

I am nuts. I don't think anyone is disputing this fact.


Discussing in this bug is getting pathetic. We are repeating statements over and
over again ignoring each other's valid points. Since none of us are open to each
other's arguments there is no point continuing this thread.


VERIFIED that in quirks mode images with HEIGHT and WIDTH attributes get a
placeholder if the images are not displayed and that the title attribute is no
longer used to generate the alt text.
Status: RESOLVED → VERIFIED

Comment 135

18 years ago
plussing. please hit the 0.9.4 branch with this.
Keywords: edt0.9.4edt0.9.4+

Comment 136

18 years ago
Checked into 0.9.4 branch. I did have to rework the patches somewhat as the
ImageLib on the 0.9.4 branch is slightly different. The only interesting
difference is in how the icons are cleaned up: in the trunk version, as seen in
the attached patches, the icons are deleted when there are no more imageFrames.
In the 0.9.4 branch, this caused subsequent attempts to load the iamges to fail,
so I changed the nsImageFrame::Destroy method to never delete the icons - they
will thus leak at shutdown (not per page, just at shutdown).
Keywords: fixed0.9.4

Comment 137

18 years ago
Verified on 2002-01-14-23-0.9.4ec.
Keywords: verified0.9.4

Comment 138

17 years ago
I don't mean to sound argumentative, but I don't see that this is fixed.  The
bug is called "preserve the dimensions of a broken image and do not render
|title| element as alternative text" [I think they meant title attribute].  The
only part that seems to have been fixed is the part about "do not render |title|
element".
As for preserving the size of images that aren't displayed, here is what I
observe in Win 98 Build 2002050608:
-For _blocked_ images, specified WIDTH and HEIGHT attributes are honored even
though the image is not displayed (I understand, this is outside of this bug)
-For broken images, specified WIDTH and HEIGHT are ignored; if alt text is
given, image is replaced by an inline text element; if no alt text, image is
collapsed
I don't understand why we honor dimensions for blocked images, but don't for
broken ones.  I would think the default behavior would be exactly the opposite,
and that ideally these would be things that could be user-changable preferences,
so everyone could be happy.
Am I just misunderstanding something?  Maybe someone could kindly fill me in. 
(The bug commentary is so polluted that I am having trouble telling what
actually was done.)
David, which site did you do the broken image test on?  Note that on a site in
standards mode we do the standards thing and do _not_ show placeholders....

Comment 140

17 years ago
Oh, I guess I just didn't realize it was a violation of standards (or maybe moz 
specs) to act like that in standard mode (I always give my HTML a doctype 
declaration, so I would never see quirks mode).
Can you tell me where I can find more information on this specification (I mean 
the one that describes how Mozilla should handle this, not the W3C one).  
Thanks.
See comment 35 and other comments throughout the bug -- the specification you
refer to was hashed out as a compromise in the course of this bug. 

Updated

15 years ago
Keywords: fixed0.9.4
You need to log in before you can comment on or make changes to this bug.