Closed Bug 102281 Opened 24 years ago Closed 24 years ago

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

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.6

People

(Reporter: waterson, Assigned: attinasi_layout)

References

Details

(Keywords: compat, testcase, topembed, Whiteboard: [bugscape: 8601]INVALID/WONTFIX?)

Attachments

(13 files, 3 obsolete files)

test case
112 bytes, text/html
Details
patch: skip the title attribute if in quirks mode
2.27 KB, patch
Details | Diff | Splinter Review
testcase: alt and title text explored
561 bytes, text/html
Details
advanced testcase: exercises various image markups (image src's are valid but slow)
4.12 KB, text/html
Details
because users don't want to see shite like this
42.96 KB, text/html
Details
shite like this, you mean?
291.18 KB, image/png
Details
yup.
101.18 KB, image/jpeg
Details
Same page except for s/title="[^"]*"//g
48.32 KB, image/png
Details
testcase showing some potential cases where not honoring the image dimensions for the ALT text makes it look bad
3.79 KB, text/html
Details
Changes to CSSFrameConstructor: export (as static) the GetAlternateTextFor method, and stop using TITLE attribute in that method
3.50 KB, patch
kmcclusk
: review+
waterson
: superreview+
Details | Diff | Splinter Review
ImageFrame changes: incorporating waterson's comments, and added check for Quirks Mode and a pref to force inline alt text.
18.29 KB, patch
kmcclusk
: review+
waterson
: superreview+
Details | Diff | Splinter Review
Add default value and comment to all.js
747 bytes, patch
Details | Diff | Splinter Review
Testcase - standard mode version of previous testcase.
3.89 KB, text/html
Details
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.
Attached file test case —
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?
no Ian, this is not invalid for a multitude of reasons, removing whiteboard entries.
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.
i know exactly what the spec says, trust me. regardless this needs to be 'fixed'
Whiteboard: INVALID/WONTFIX?
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?
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
Whiteboard: INVALID/WONTFIX?
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.
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.
Target Milestone: mozilla0.9.5 → mozilla0.9.6
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?
Whiteboard: INVALID/WONTFIX? → [bugscape: 8601]INVALID/WONTFIX?
Blocks: 64833
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?
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.
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
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?
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
Attached patch image frame changes - need more testing (obsolete) — — Splinter Review
Attached patch frame constructor changes (obsolete) — — Splinter Review
Blocks: 106958
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
This seems to be right on IMO.
Depends on: 108538
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
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).
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
Keywords: edt0.9.4
is this bug really blocked by 41924, or is 41924 a dupe of this at this point?
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
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.
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
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. ***
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.
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".
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!)
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.
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.
...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?
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.
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.
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.
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.
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.
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?)
Attached 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.
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+
(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.
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.
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
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.
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 on attachment 56332 [details] [diff] [review] frame constructor changes new patch coming...
Attachment #56332 - Attachment is obsolete: true
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
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.
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+
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? :-)
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).
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+
Patches checked in to trunk. Still need to update the image icons, opening new bug for that.
Status: ASSIGNED → RESOLVED
Closed: 24 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.
Bug 108799 opened for the icon issue. Yes, 41924 is now _the_ [META] ALT text bug.
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)
"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.
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?
"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.
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.
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.
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.
> 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.
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.
>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.
>... 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.
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.
> 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
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: 24 years ago → 24 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
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
>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.
"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.
>> 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
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.
Depends on: 108799
>> 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).
> 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'.
> 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.
Good god, talk about a discussion that belongs in the newsgroups.
> 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.
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.
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
plussing. please hit the 0.9.4 branch with this.
Keywords: edt0.9.4 → edt0.9.4+
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
Verified on 2002-01-14-23-0.9.4ec.
Keywords: verified0.9.4
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....
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.
Keywords: fixed0.9.4
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: