Are you a brain-dead website author? You probably are, if you've been "directed" to read this page. You probably had one of those offensive, "upgrade your browser" demand notices on your website, too. When what's really needed, is for the website to be upgraded. Stop being a nuisance, and learn how to write websites properly!
For anybody else who's stumbled across this page, this isn't going to be a lesson in how to write websites, there's plenty of material on that (there's links to some, near the end of this page). This page has been written, as I've encountered website after website which was badly written; with new sections added as I've discovered yet more annoying and stupid sites. There's a bit of information repeated in sections, to re-inforce the point being made, and avoiding having to scroll back and forth between sections.
Periodically, I research what locations on the WWW have referenced this page, and I've noticed a few common points that have been raised:
They don't like the heavy criticism.
Tough luck! The page is in response to offensive sites, where the nice approach hasn't worked, or a stupid response was received. These people also seem to be defending their own poor authoring habits, to the death; putting far more effort into their arguments than would be required to learn how to author properly.
Idiotic commentary about the prettiness of the site.
Beauty is in the eye of the beholder, and adds nothing to the content. This is a page with a "message," and it works on any decent browser; it's not an art gallery. Most of their "pretty" examples, are pretty unreadable (with tiny fonts, damn fool colour combinations, and using peculiar browser tricks).
Showing their ignorance about why their crummy web browser (Microsoft's Internet Explorer on Microsoft Windows), can't always manage to correctly choose a serif, or sans-serif, type of font for the page (its behaviour is inconsistent).
Their (Microsoft's) system is seriously faulty, the website is fine, and I'm not about to kludge the content to suit its faults. This page is authored for the WWW, not a particular browser; and specifying particular fonts brings about other problems.
If there's one thing that I'm really sick of, it's being told that my browser isn't capable of using some website. Especially, as it usually is! That, and being told that I must re-configure my system (usually, to degrade my security). This sort of thing is a waste of my time, it's damn annoying, and just shows how stupid the website author is. The internet is not for one person's self indulgence, it's for many people to use. Why else would you publicly publish a document, if you don't want as many people as possible to be able to read it? If you know what you're doing, then you write so that as many people as possible can read your pages, and without making them have to go out of their way to manage it.
There's a ridiculously large number of moronic website authors who build sites that will not work in more than one or two browsers, because they've used some non-standard authoring style. If you attempt to use their site with another browser, it will fail in various stupid ways. Guess what? The fault is not in the browser being used, it's in the brain of the website author: They're a bloody idiot! They've written a site for specific browsers, and that's all it's probably going to look okay in. When newer versions of browsers come out, they'll have to rewrite their site.
And there's just as many incompetent ones who assume that their website will only work in one or two browsers, check to see whether you're running one of them; and then blatantly lock you out, if you're not. If you hack your way around their stupidity and gain access, you'll often find that the site does work quite okay, or with only minimal problems (e.g. the site is usable, even if it's a mess).
The solution is simple: Write the website properly! Do not tell the visitor to download some update to their web browser, reconfigure their browser, or to use a completely different browser than what they want to. Write the site to the standard specifications so it works in all browsers that are capable of working properly (i.e. most of them); and only having one version of a website for all browsers, means less authoring work. Don't do browser version testing, just completely avoid doing silly tricks that only work in some browsers, and let the browser ignore things that it can't deal with. And don't misuse HTML.
e.g. "Blockquote" is for quoting blocks of text, not for indenting. There's no specification that says that user-agents "must" indent blockquoted text, so don't "expect" that behaviour (e.g. one of my browsers italicises the quoted text, it doesn't indent it). The "blockquote" element "means" that the contents are "quoted" material ("how" that's indicated, is not specified), "tables" are for presenting tabular data, "em" emphasised text means that the text is "emphasised," not "italicised," (italicising's just a commonly employed, but by no means mandatory, method of indicating emphasised text), and so on. HTML elements have specific purposes, use them appropriately.
I'm not about to spend ages downloading a different browser, install it, reboot, and then come back to look at your site; neither are many other people. Your suggested browser may not even be available for our systems, and/or we may not be "allowed" to make changes to the computer we're using. Likewise, regarding plug-ins to our current browser. And we're certainly not about to change the device we're using to access the internet, just to use your website. More non-computer appliances are being used for the internet, different computer systems are being more widely used, and browsers are getting less tolerant of bad authoring, so idiot website authors had better get it through their thick heads to stop kludging the content for specific browsers.
("Kludging" the content, means writing deliberately broken content, to suit the faults of something else. This kludged content won't suit the requirements of other things.)
We're going to ignore your website, as well we should, permanently. That means no sales, or whatever else that you're trying to use your website for (the ultimate stupidity is computer sales websites, that require the latest version of IE to view them, when they're trying to sell new computers to people using older computers). We'll be away within mere seconds, to find some other site that works, now; in the browser that we're using. It's not just because we're outraged by a dumb site. But why would we persist in trying to get some broken site to work, when it's just a moments work to find something else that does work?
There are more web browsers than Internet Explorer or Netscape, and more operating systems than Windows and Macintosh. And, many of those others are also quite capable of using SSL, CSS, JavaScript, Java, etc. And, very often, are far more secure (safer to use) than IE or Netscape.
If some site excludes other browsers for being potential security risks, then they should permanently block the usage of Internet Explorer, at the very least. It's riddled with serious security flaws, and probably always will be. Disregarding all the programming bugs, and opportunities it provides for hacking; its ability to keep website log-on details stored within the system, is against the usual terms of services for using things like bankcards (it's the same situation as writing your PIN on the card). Banks should not be advocating that their clients use Internet Explorer, nor advising people degrade their security so the site will work, but should be actively advising against it, and authoring their sites better.
Relying on Java or JavaScript, is stupid. They're not used equally across different browsers. They're often disabled, because users are sick of the stupid uses of them, and how they make their system grind to a snail's pace, or their use has been prohibited on various computer networks. And both have been perverted into non-standard variations by Microsoft. Likewise, requiring the use of other plug-ins, such as Flash, Shockwave, and PDF, or non-standard and unsafe browser extensions like ActiveX, is equally stupid; and excludes your site from a large number of people. That number could be in the millions!
Also, relying on cookies, referrer headers, and user-agent headers to control access to your site, is incredibly stupid. Likewise, with relying on client-side scripting to validate data before submission. They're all so easily modified. Relying on them leaves you wide open to abuse, and prone to errors. The referrer header's not even a mandatory header, anyway.
If users have decided that they don't want, animated banners, Java, scrolling mesages, scripts, pop-ups, advertising, graphics, or anything else, then they don't want them! It's not up to you to try and circumvent their preferences. They don't want any of "that" stuff, including yours. Take the hint that users don't want crap inflicted upon them.
When told to quit doing something, the message is that you should stop doing it. When you find that people want to ignore certain things, then get used to the fact that they're not interested. It's not some form of challenge to find yet another way to do something that people don't want. Being involved in any sort of activity, is not about doing what you can get away with, but doing the right thing in the first place, because it's the right thing to do. Exploiting some flaw, that lets you do something that you couldn't otherwise do, is acting in a completely reprehensible manner; "caveat emptor" is the attitude of a fraudulent con artist, and not tolerable.
Not properly using alt text means that pages become nonsensical when images aren't showing, for any reason (maybe because the server isn't working right, or the page was authored badly and got the links to the images wrong, or because the user doesn't want to slow down their browsing for the images, because the user cannot see, etc.).
The alt text attribute is for conveying a
suitable "alternative," for when the images aren't showing. If you're using
an image in a link to the homepage, then the alt
text should make it clearly apparent that it's a link to the homepage (unless the
link also includes text which makes it plainly apparent). If you've included
a photo on the page, that's not just superfluous and ignorable, then it should be a
suitable alternative to seeing the image. If you're using an image which is
unimportant to reading the page, then set the alt
attribute to nothing (e.g. alt="").
Setting it to say something inappropriate, like "image," is a nuisance. It conveys no meaning to what's being read, it's useless information, looks stupid, and frequently interrupts the rest of what would have been a coherently readable section.
If you want some text to appear when the user hovers a mouse over the image, then it's the "title" attribute that you should be using. Regardless of the behaviour of some browsers, regardless of rubbish perpetuated by some people who don't know what they're talking about, that is the purpose of the "title" attribute, not the "alt" attribute.
A serious annoyance with websites, are ones that have unnecessary huge graphics or multimedia files. Apart from costing more money in data traffic expenses, they're slow to use. Slow enough that they try the patience of visitors. Not everyone has a fast internet connection, and not all routes between services are fast, either.
Contrary to modern myth, carving up a picture into sections does not make it quicker to load. It can cause problems with running more connections to a server than would otherwise be necessary. There's a limit to how many connections a server can, or will, accept. Both to a particular visitor, and the overall number of connections it can service to all visitors. Likewise, browsers can only make so-many simultaneous connections. Exceeding the limit results in stalled or aborted downloads. A visitor is likely to try reloading the page, attempting to get the rest of the graphics, only to face the same problem again.
Contrary to another myth, sliced images do not stop people from copying images from your site. It makes it slightly harder, but it's not difficult to work around. Neither do other tricks prevent people copying images (e.g. disabling the right-click menu only works on some browsers, and even that can be easily worked around).
Pages with large numbers of graphics are just as bad. They take ages to load, and suffer the same problems due to the maximum number of concurrent connections.
Likewise with pages that use images to force the page to format in a certain way. Without the images, the page looks a mess. And sometimes with them too, as the author is unskilled at doing it in ways compatible with all browsers and differing browser canvas sizes. People actually do browse with images turned off; it's quicker that way. If site looks stupid, that way, it's because the author doesn't understand what HTML is about, not that the browser is browsing it in the wrong way.
Improper use of image elements make things worse. ALT text is (now) a mandatory field, but it has to be used intelligently. It's to be seen when the images are not showing (ALT is short for "alternative," as in an alternative to the image; to convey the same meaning as the image, not to "describe" it). If you want tooltips to pop up when you hover a mouse over an image, use the TITLE attribute. Set the ALT text to show something meaningful when it's required (e.g. if you used a graphic for a link, then use words that convey the same meaning as the image), and set it to nothing when the image is best totally ignored (e.g. set ALT="" for images that just pad out the page, or are completely redundant in a text-only viewing mode).
Using multimedia content, just for the sake of it, is not a good idea, at all. It's slower for visitors to use, that's if they even can use it.
Flash is typically included in websites using malformed HTML, isn't available for all platforms, and can be a complete pain to install (a prolonged download from a slow and convoluted website, and may also require a reboot). It precludes text-only browsing (speedier browsing of sites, accessibility for the disabled, and search engine indexing of sites). And sitting through a four minute download, only to find that you've been waiting for a completely unnecessary introductory animation, leaves you with very little respect for the page author.
Background sounds and music are damn annoying. It delays the loading of pages, is distracting, and is also typically included using malformed HTML.
Likewise, animated GIFs are a pain to the eyes, and lots of them can be a serious drag on CPU resources.
These sort of things show a fundamental contempt for anybody trying to read your pages. It's the cyber equivalent of trying to read a book with screaming kids running around you in circles.
Picking certain combinations of colours (foreground against background), can make things very hard to read. Even simple black on white (and vice versa), is harsh on the eyes. And if you do specify colours on a page, be sure to specify the colours for background, foreground (text), and the links (i.e. set everything, not just some things). Else, some default setting is likely to clash with your non-default choices. Don't forget that many people will have customised their browsers (not just a few people, it could well be millions of people; the world is a pretty big place), so don't colour pages just for the sake of it, many people will already have made their browsers look better than the original default settings; and not all browsers have black text, white background, blue unvisited links, and purple visited links, as their default colours, anyway.
Other points to remember are that there's an awful lot of people with eyesight problems; colourblindness is very prevelent (some statistics say one in ten people have it). And, many people have badly set up monitors (using very dark colours, may make things disappear from view).
Setting a page to use particular fonts, or font sizing, can make a page difficult, or impossible to read. Anybody who customises their browser, or has a browser which comes with sensible defaults, will have settings that make it easy to read a page. The font size will be a normal size, that's comfortable to read; likewise with the font face.
Choosing something else, means that you're making an assumption that they have the font that you've picked (they may not, and their browser may substitute something awful; or if you've tried to highlight sections in a different font, that highlighting will fail), and that the size is suitable for them (you may have picked a tiny or huge font, particularly when you consider that their screen resolution may be different from your own).
The first common mistake is to think that you need to specify a font. You don't. At all!
The next one is that you have a better idea of what looks good, than they do. You're wrong, and you have no way of telling what's actually "suitable" (for them).
Leading to the next common mistake, that you think that most people have their fonts set up too big, and that you should "correct" that for them, by making your fonts one size (too) small (for many people, that means a font that's significantly too small to be easily read). You're wrong; my fonts are set up exactly how I want them, and many people's are set up exactly how they "need" them. Now, people have to re-adjust their browser, to compensate for your page. Then, the next time that they encounter a website that's written "properly," it looks too big, so they have to re-adjust their browser, yet again. This mess is all your fault.
(On nearly every browser that I've looked at, the default font size has been appropriate. The user hasn't needed to fiddle with settings, until some author has used awkward font sizes.)
Another common mistake is to specify "fixed" font sizes, which not only means that you've probably picked an inappropriate size for them, but you've also made it just about impossible for them to adjust the display of the page to suit themselves. Attempting to fix the size of fonts, to fit text into certain parts of the page (e.g. because you've got images of a certain size, surrounding it), is a mistake. The entire idea of that (fixed page layout), is flawed. It's the complete opposite of the design philosophy of HTML.
(Yes, this page does vaguely specify font types, but only in as much as "suggesting" your choice of sans-serif font face to be used in headings, and your choice of serif font face for the main body text. Your browser, if it's a decent one, will allow you to pick your default serif and sans-serif fonts, amongst other default display choices. Your settings determine what size the main body text is, with the other text on the page, being sized proportionally around those settings. As usual, Microsoft's Internet Explorer does an incredibly crap job of handling this, and often fouls up. This page's style sheet is fine, Internet Explorer is in error, and I'm not going to do kludge my site to suit it. You can use a better browser, though; and have a safer internet experience, too.)
There's a great many "pretty" useless websites. Prettying up a website doesn't make it better, and often makes it worse. Apart from people having different ideas about what looks nice, many people have no idea about how difficult it is to read some web pages (tiny and indistinct fonts, hard to read colour combinations, convoluted layouts, pages that don't fit the browser window, etc.).
This page conveys a message, and it does that with words; anything else is superfluous. Making things look prettier, may be nice (perhaps), but isn't as important as the content.
HTML is a mark-up language, for "marking up" sections of its content as "meaning" something. Incorrectly using HTML elements makes a nonsense of the marked-up data, making machine assessment of the code next to impossible.
(e.g. With appropriate software, I can search through a page for "definitions" of something; but if the author's used the element just to make something look different, rather than using it to "define" something, then they've just broken the functionality of my software. Likewise, I can see a summary of a page, and jump to key points on the page, by assessing the headings used on it; though only if heading elements have been properly used. But if a page is written badly, all I can do is a plain-text word searches.)
HTML should be only used to mark-up the content, to indicate what it is. If you want to change how something looks, then you should be playing with a "styling" language (e.g. CSS); and also realising that styling is merely a "suggestion" (it may be completely ignored by the browser), so don't rely on styling to make your page coherent. Learn what the various WWW languages are really for, and use them properly.
HTML is a document "structuring" language. It's designed to identify sections of the page as having specific meanings (as being paragraphs, lists, quoted text, etc.), which can be machine assessed, by search engines, webbrowers, and other agents; not to specify that certain sections should have a specific "look." The fact that certain HTML elements have acquired customary ways to be rendered, is incidental. They're "customary," in that you can recognise things for what they are, because they're displayed similarly on different browsers (headings, lists, etc.), but they aren't displayed identically on each browser. Very few of the HTML elements actually have a (standard) pre-defined way to be shown, therefore you can't rely on all browsers displaying elements in the same ways as each other (they don't, they're not supposed to, and future browsers may behave differently).
The proper use of HTML allows quite complex machine processing of the contents (e.g. search engines, and various browsing aids), that produce correct results (e.g. displaying a table of contents for a page, reading out structured information in a coherent manner, etc.). Improper usage produces incorrect results, and only caters for very basic machine processing of the data (e.g. searching for words that match your query, treating the document as if it were merely plain text).
Webpages are generally seen on a display screen, with no standard size (neither the screen, nor the browser window), so many of the techniques suitable for printed media, are inappropriate. Many are contrary to the design of HTML (of resizeable, reflowable, page layouts), and are often unachievable (e.g. "fixed" layouts), producing broken results.
e.g. I can't print pages from this ISP's (Optus) user account logs, on normal A4 paper, without a lot of mucking around. They've used a layout that makes the right-hand side of the page fall off the paper. If they'd done it properly, I'd be able to print them without any problems. There's no "good" reason to deliberately restrict my ability to print those pages (it's information for me, about my account; and I'm the only one who can access that page).
However, if you wish to try and make a page look a particular way, then mark-up the content in the correct manner, and use styling (e.g. CSS) to try and achieve the effect that you desire. Understand that it's only a "suggestion," it may be ignored or overridden, and that's how it's supposed to be. It is not your place to try and fix a layout on someone, regardless of how they wish, or need, to see the page; and generally, fixed layout attempts fail, because they don't work in all the viewing conditions that a page is seen.
The best way to support older browsers, is not to use bad HTML authoring techniques, in an attempt to misuse HTML as a page layout language; but to use CSS which can be totally ignored, producing nicer pages in the supporting browsers, and plainer pages in the other ones. Get used to the fact that your pages will be seen in the manner that best suits the viewer, not the author.
One of the first mistakes that authors make, when converting over to using CSS, is to carry on creating pages in the same hideous, user-un-friendly manner. For instance, CSS is not a new way to do the things that you shouldn't have done, with tables.
(Tables have always been a bad way to format a page, not just because they abuse the HTML table element, but they're too inflexible for presenting information that will be seen in a browsers with widely varying page widths, and it's a bad way to present information which should be displayed in a normal manner.)
CSS is for adding extra, optional, styling "suggestions," to a page. You cannot "force" anything upon the user (you can't really do that with HTML, either; apart from forcing a mess upon them). CSS is designed to be optional, to not make a page useless when it's not supported (stupid authoring of pages notwithstanding), and to offer better ways of doing fancy things.
If you have a browser capable of selecting which style sheet a page will be rendered using, such as recent versions of Mozilla, Opera, Netscape, and several others, you'll see that this page has several styles, other than the default. Several of them are there to demonstrate stupid authoring techniques. Some will cause the page to become unreadable.
If your browser doesn't support CSS at all, then you'll see this page, and many other well authored non-CSS reliant pages, in a plain fashion, which is still easily readable. Unlike what happens when you encounter pages stupidly authored abusing various HTML elements (like the table element), where you can do almost nothing to unmangle the contents; and pages which have relied on other special tricks, like JavaScript, which fails to do anything unless supported, and allowed, by the browser.
HTML is designed to deliberately render in a non-specific size, to fit into whatever sized viewing window the browser has. Different people have different screen resolutions, and browser window sizes. You cannot make any assumption about the size of the browsers display (e.g. most people have this, so I'll make a page that uses that space); that's completely incompetent website authoring. We aren't going to change screen resolutions to suit you, and we are going to use browser window sizes that suits us. That's a specific design criteria of HTML; to give the viewer total control over the display of the page.
One of the purposes of HTML is to get away from the problems associated with trying to read documents that were formatted on someone else's (differently set up) computer. Trying to read documents which require horizontal and vertical scrolling, because they're too wide, or have used multi-columnar layouts (which are inappropriate for anything other than printed material) is damn annoying. Likewise, with documents which have become badly wrapped, due to overwide lines, and no neat way of rewrapping them; or require an excessively wide screen to view the page. And reading text that only occupies a thin section of the screen, for no good reason, is just as annoying to read. Not to mention, documents which used fonts that were far too small to be read easily, or stupidly huge ones.
Writing HTML documents so that the contents and squeeze and stretch to the current width of the browser window (as they're supposed to), is the proper way to author them. It fits the needs of the reader, to format the text in the most suitable manner for themselves; and allows the document to fit into the technical limitations of their browser.
Your browser isn't the same as mine (neither in which browsers they are, nor how they're configured), nor do they have to be the same browser. Using features that only work in specific browsers is ignorant of the diversity of devices that can access the WWW, restrictive towards people who can't use the device that you're insisting on, and limits your potential audience. Do you really need that special feature? Or did you just get hooked on playing with fancy toys? The chances are that you don't need to do whatever it is that you're attempting.
Sites that try to determine which user-agent is accessing them, to send a different version or a lock-out notice, often get it wrong; and make a worse job than having a single version that works in all browsers. So coming up with multi-version sites isn't the answer; and involves more hard work, which is all-too-typically a waste of effort.
Using your browser to test whether a site works is utterly useless (browsers are generally designed to work their way around faults, rather than indicate that the page is malformed; and this sort of testing only tests that the site works in your browser). Likewise, telling me that your site works for you is useless, when I've told you that it doesn't work for me; I'm not at your computer, I need it to work for me, on my browser.
Use proper debugging tools (error checkers, and validators), to get sites working in all browsers, and write HTML to the ratified specifications, in the first place.
Not everybody will have the latest version of browsers (or other software), nor wish (or be able to) keep up with installing them. If you use features that only work on the latest software, then you're limiting your audience.
Not only do you have user updating to contend with, but software authoring, as well. The development of technology is usually ahead of the implementation and use of it.
Quite often the special feature isn't needed; and the tests authors try, to see if a special feature is there, are flawed. For instance:
I commonly see JavaScript being used to test if cookies are being accepted; which fails if JavaScript isn't enabled, even if cookies are. And those cookies often weren't really needed, nor was JavaScript needed for anything else but that test, either. (If you really need to test for cookies, then get the server to send them, using server-side functions; and let it react to the response, or lack of response.)
Another common flaw is using JavaScript to check the contents of a form, and no checking of the data received at the server. This leaves you wide open to abuse by hackers, or accidents from people who don't have JavaScript enabled (without it, no tests will be run to check that they're sending you the right data).
Your server is the only thing that you will know the capabilities of, always use it for any special features that you need.
Many sites use JavaScript for links between pages, when it was totally unneccessary (the links could have been done with plain HTML). The site becomes unnavigable in any web browser which doesn't support JavaScript, has JavaScript turned off, or the page author used some non-standard method in their scripting.
JavaScript links can also make it hard to open a page in a new browser window, and prevents search engines from indexing pages (which isn't a good thing; remember that most people find WWW resources through search engines, and rarely through the front page of a website).
In most cases, a site doesn't really need any scripting running in the browser to do some task; but if it does use it, it should be done properly: In a manner where the scripting provides an optional improvement, to when scripting is ignored; and where the page doesn't become useless without the scripting.
e.g. For the href attribute, write a normal HTML link to the resource (or to an useful alternative), so that the page is still usable without scripting in the browser; and place your scripting in the extra attributes provided for those sort of things (such as the onclick and onkeypress attributes).
Firstly, many people disable it on the browsers, or have it disabled for them as a company policy. Secondly, even on reasonable fast computers, it can make them grind down to a crawl. And thirdly, many script authors aren't too competent; writing scripts that are just plain broken, doesn't take into account the behaviour of other web browsers than the one the author tried it with, or is easily exploitable by hackers.
Trying to find your way around a convoluted site is not only annoying, but a serious time waster. We shouldn't have to click through page after page to see something; nor to "drill down" through menu page after menu page, to what we needed; nor have to read information that on a single topic but has been carved up into a few paragraphs per page (such stupid examples also tend to be on excruciatingly slow servers, too); nor have to read the sites "help" or "map" page, to find the page that we need; nor have to deal with sites which pop up other windows, causing us to have to shuffle them all around (sites that rely on a multi-window approach fail when the browser cannot, or will not, open other windows).
e.g. Taking twenty minutes to get through to your bank account transaction listing, making you go through the log-on page, then two or three menu pages which cannot be book-marked, and use slow-to-get navigational icons, is a ridiculous process to have to go through.
Particularly annoying are sites using SSL (https:// links), which are slow enough to begin with, but become tediously slow, once you've got pages with half a dozen graphics being encrypted and decrypted. Such sites also tend to never bother to put in useful ALT text, so that you can't (simply) ignore graphics, and browse without having to wait for them. Sites that use SSL encryption should be written in a lean manner (simple, small pages; avoid the use of graphics, or at least not depend on them; and avoiding having to wade through page after page), and shouldn't use SSL until needed (e.g. on-line shopping sites should keep the main section of the site, where you browse and pick items, as normal HTTP linked pages, then proceed to the SSL section, when it comes to the bill).
Dynamically generated sites tend to be some of the worst sites that I have to use. They're often much slower at serving pages (and tend to have uncacheable resources, so that I can't go "back" a page, I have to re-get the entire thing), and have far more errors; as the author has more authoring work to do than flat HTML sites, and more opportunity to miswrite something; or has (again) relied on special browser features; and much of the automatically generated content is badly generated, and not fixable by the website author.
Webpages are not magazine pages; most people cannot see the entire page in one go, and have to scroll. Trying to read a page which has formatted the contents into columns (with bits of information here, there, and everywhere), is annoying to read. Having to repeatedly scroll up and down, and read little snippets spread throughout margins, around a longer article in another column, is a major pain. Trying to read an article with other things splattered through it, is annoying. And trying to read all of the other things that are placed higgledy piggledy around the page, is an eye strain.
Sites which pop up other windows, are painful. They make older computers grind to a crawl, as they open the other window. The pop-ups get in the way of what we're trying to read. People have to shuffle windows around, to see what's in the other window; or madly close windows that they didn't want to see. Sites that pop-up another window for navigation, cannot be used when the browser doesn't open another window (because it can't, or the user doesn't want it to).
Website authors frequently make websites awkward to use, by ill-thought-out usages of frames; for instance:
Sometimes documents move locations, and webserver adminstrators will set up redirectors in the old location, to forward visitors to the new location (sometimes they don't bother, and links to resources end up leading to nowhere). Unfortunately some people shift their resources around a lot, and when you try to visit their page, you end up going through several redirections, one after another. This shows a lack of planning, or a daft, committee-like, behaviour of continually re-organising themselves, without actually doing anything new.
This is disconcerting in itself, the first time around; as you're not sure whether you're really supposed to be where you ended up, because it wasn't the address that you tried to access. Some browsers warn you that you're being redirected, and perhaps the site's being hijacked, and you should be cautious about trusting where you finally end up (of course, there's no way for you to determine the truth of that). Some browsers won't obey redirections at all; because sites have been hijacked this way, before, or because some malicious sites deliberately bounce you about while you're browsing through them, it's become an exploit to be cautious about, and some people re-configure their browsers not to do allow redirects.
But it's really annoying when you get bounced in and out of secure and insecure addresses, or in and out of trusted and untrusted addresses (as per your personal browser preferences), and you have to okay each of the transfers manually (while still wondering if you should okay them, or forget about it). The Hotmail and other MSN sites are particular woeful in this regard.
Some redirections won't work, very well, either; because the author has done them as meta refresh statements in the HTML head, rather than as HTTP headers. More of the cautious browsers will ignore the meta refresh statements, than they'll ignore the HTTP headers, though some will ignore both; and, caches will generally only pay attention to the HTTP headers.
It's not a good idea to "rely" on a redirect working, and if you must use them, you really should ensure that there's a fall-back mechanism in place (such as the old page stating that the location has changed, and offering a link for people to follow to the new location; for all those browsers which won't, automatically, follow the redirect, to display to the viewer).
Disabling right-click options does not stop people from pinching things from your site (it's already downloaded and cached; and just about anything that you can see, you can copy), but does make things damn hard for people who need to cut and paste things from the page (your e-mail address into their mail client; unknown words into dictionaries; cinema session times into messaging clients, to ask if their friend can make it as well), or use other functions in their right-click menu (navigation, accessibility aids, security checks against your site, opening links in another browser window, bookmarking, changing encodings to suit their system, refreshing frames from broken servers, and so on).
Removing the "chrome" from the browser (parts of the GUI, such as the navigation buttons, the address gadget, scroll bars, etc.), seriously annoys many people, makes it hard to use the browser, and removes options which people use to check whether they want to trust your page.
Making links hard to find, doesn't help people use your website. Removing underlines (because you don't think they look nice) means that links don't have the default look that people expect. Now, they've got to hunt through the page to find where the links are (assuming that they'll bother looking to see if there are any links, given that there isn't the usual hint to show that there are any links on the page). And, relying on links being rendered in a different colour doesn't help people who don't have coloured displays, or who are colourblind (a large number of people are). Another related problem situation, of settings attributes so that visited links don't change colours, makes it confusing for people trying to work out whether they've already followed a link. Using images for links, but without making it plainly obvious that the image is a link, or what the link is for, also isn't helpful.
For some stupid reason, some authors think it's a good idea to author a page in such as way as to make it hard to work out where a link is going to take you (e.g. by using JavaScript to nobble the status display of your browser, or writing the address in some obscure manner). This is as irritating as hell, I want to know where I might be going to, before I decide follow a link. It's also stupid, as people can undo such subterfuge.
Some authors stupidly decide that they want to hide the current page's location, by loading into a frame. This is fruitless, in that it can be easily overcome by reloading the frame into the full window; this is annoying in that it makes it hard to keep track of where you currently are, and to bookmark pages; and is breaking the standard behaviour of my browser (to display the current location).
Attempting to hide your page source does not protect it from being copied, that's is utterly impossible (if I can see your page, I can copy the source, no matter what you try). However, it does make it difficult for people to deal with broken pages, as there's no easy way for them to find out what's wrong, and do something about it (e.g. you typed a link address incorrectly, which they could have hand typed into their browser's address gadget). It also compromises your site's ability to be indexed via a search engine (if you use some obscure method which requires a browser to decode it, like JavaScripting).
If you don't want people copying what you've done, then don't publish it. It's as simple as that, and it's the only solution. All assertions to the contrary, are absolutely false.
Requiring people to degrade their security, is a menace, and shows a lack of skill in web authoring that you can't achieve what you need without compromising someone else's computer. It's exposing users to all sorts of hazards, ones which many people will not be able to repair by themselves; and may cause them to be a problem to other people (propagating viruses, etc.). Even more so, if you're advising people to permanently degrade their default settings, rather than just make exceptions for your site. You're also excluding a lot of people who won't, or can't modify their browser settings.
Anyone insisting that users degrade their security settings causes them to (rightly) be concerned about whether they're just incompetent, or have ulterior motives.
Requiring people to accept cookies is bad enough, without ramming masses of them down their throat. You do not "need" to send a cookie with every image on the page, nor should you be doing that.
Cookies should be used sparingly, if at all. I'm sick of encountering pages where I have to click on thirty-odd cookie prompts, and so are many others. No, we're not going to blindly accept all cookies; there's far too many malicious uses of them to promote that behaviour. If anything, we're going to block annoying cookies.
There are better ways to do things, than rely on the user to store and return data. It's often used as a breach of our privacy, and relying on the integrity of the data is leaving the server wide open to errors and abuse (editing the contents of cookies is easy to do; users will, and should, frequently remove clutter from their drives; and it can lead to private data, about the user, being stored on a computer that's not theirs).
Services which send cookies, and have to wait for responses, particularly lots of them, are also damn slow. Making some services incredibly tedious to use.
In most cases, you don't need to know personal details of visitors; and keeping such records puts a burden of ensuring that they remain private on you, too. Secret tracking and spying techniques are deceitful, and even doing it openly is despicable. It's also somewhat naive to think that people won't provide false information. The more intrusive you are, the less people are inclined to trust you, and care about doing what you want.
Writing "click here" for all your links looks very amateurish, looks damn stupid, and ignores the fact that not everybody "clicks" on a link with a mouse. It's also ignorant of how search engines index pages (they use the words displayed in the link). Printed copies of pages look stupid, and are missing what could be vital information to understanding the document (that's your fault for bad authoring, not the user's fault for printing a page).
Make the link part of the sentence. If you have a file for downloading, and you write about being able to download the file from here, make the phrase or the actual filename, the link. If you're linking to a page with more information on a particular word (or phrase), make that word (or phrase) the link; writing the sentence in a normal manner, so that it reads coherently.
e.g. Download the current version of our program, from our website. The documentation for the program is also available, separately.
Not providing any way for people to contact you, or making it hard to find the information, is not a good idea, and very stupid for commercial websites. If you want customers, make it easy for people to get in touch with you, with whatever methods are available. And actually answer any mail that you get. Also, adequately describe your products and/or services on your website, so that people will know if they want to contact you.
Not including normal, and unobscured, e-mail links, makes it hard for people to e-mail you in a normal e-mail client (which generally is the easiest way to write messages). It means that they can't compose a message to you while they're off-line; they can't keep a record of what they sent to you; and they can't write down an e-mail address (to use later on), while looking at your website on someone else's computer.
Not providing a "form" means that only people with an e-mail account, can contact you. Likewise, if you don't allow them to specify that you contact them back using some non-internet method (e.g. over the phone, or real mail). Many people use other people's computers (private or public ones), where they only thing that they can use is the web browser; and they mayn't have an e-mail address, or one that they can access frequently.
Overly complex forms are seriously annoying (e.g. ones that demand certain information that you don't have, don't need to give as part of your query, or don't want to divulge). Likewise, with ones that give you a tiny little window to try and type a message into.
Provide both normal e-mail addresses and easily usable forms. That lets people contact you using the most convenient method, for them.
e.g. A simple write to
us page, with both methods of sending a message (this ISP
doesn't provide a mailto: form handler, so the page only has a non-working
"example" form, and a ordinary mailto: link).
Providing a normal postal address is a wise idea, too; particularly if you're a supplier of some service. It helps to let people know whereabouts in the world you are (e.g. there's not much point looking through the catalogue of some foreign company who don't trade overseas, but don't make it clear where they're based), and allows people to write to you, even if they don't have their own computer. Likewise, listing fax and phone numbers, is also a good idea. Many people want to find out about products in their own time, but still want to speak to a real person, or send something in writing.
Make it easy for people to get in touch, and respond to enquiries, or lose business.
Using "valid" HTML (as per the freely, and publicly, published specifications), means that your pages are written "correctly," and that they should work "correctly" in all browsers (the ones that exist now, and any others that will be created; so long as the browsers are built properly).
Get it right, in the first place, and you won't have to keep on "fixing" it, to work in newer, and different, browsers.
Understand (and work with) those concepts, and your pages will work properly on different browsers. Work against it, and they'll fail; on many browsers. If you find that you're having to force things for certain browsers, or that you're even trying to "force" something, in the first place; then you're using HTML against its spirit, and your efforts are bound to be limited in their effectiveness, or even cause more problems.
By way of another example of HTML's "built-in" compatibility and convenience; HTML is also designed to present its contents to more than just visual mediums (e.g. aural browsers), as it already stands, without "requiring" a second version of the contents (until an author stupidly "relies" on non-textual content, a specific layout, or complicates the contents, etc.).
World Wide Web Consortium (W3C) - the people who set the HTML specifications. Anybody designing HTML rendering agents (e.g. web browsers), who knows what they're doing, will be designing it to adhere to these specifications. Writing HTML to the ratified specifications ensures the widest possible audience for your website. The site also has other WWW authoring related information (e.g. making websites widely accessible).
ECMA is an international industry association founded in 1961 and dedicated to the standardisation of information and communication systems. Their website presents all aspects of ECMA and makes available the results of the ECMA standardisation work to all interested persons and organizations, free of charge and copyright. Amongst other things, you can find the specifications for ECMAscript (a standardisation of JavaScript), there.
Instructional information on authoring websites, and avoiding problems. This is a more tutorial based site, compared to the two sites above, which could be regarded more as reference material.
A campaign to promote developing websites that work in any webbrowser. This site (the any browser site) is a promotional attempt at the campaign. The morons page is a blunt object to strike at annoying webmasters with.
The latest version of the Hyper-Text Mark-up Language (HTML); the language that web pages are written in. The latest version now being "Extensible HTML" (XHTML), but requires you to also read the HTML 4 docs to see a manual of the HTML elements and attributes, or read the very terse lexicon of XHTML elements. Though, HTML 4 is still your best bet for compatibility with the largest number of browsers.
The latest version of HTML 4.
ISO HTML (the only officially specified version of HTML, though the W3C is the recognised authority figure). It's a tightening up of the HTML document structuring rules, into a more logically sequenced structure (such as specifying that any sub-headings must be the next sub-heading down, and not skip a level; e.g. you follow a h1 heading, by a h2 heading, not a h3 or another h1). But the HTML elements are still the same as defined by the W3C specifications (the ISO HTML specifications are applied on top of the W3C specifications). Any browser that handles HTML nicely, will handle ISO HTML just as well, the difference between them is mainly about more sensible authoring of documentation.
Note: This is a redirecting URI; this address is supposed to be permanent, it will redirect you to wherever their document is currently located (rather than be a link that directly points to where the document actually is). I think that a "standard" should have a real, and direct, permanent URI, and not rely on such tricks (that the purl.org service is, perhaps, going to be around for longer than wherever their page is actually hosted), but the ISO HTML author has told me that this is the address they want to promote.
Cascading Style Sheets (CSS) specifications. Used to add style control (presentation and layout) to websites, to pretty them up; but in a manner that isn't required for the site to be of use to people. Non-CSS capable browsers will ignore the CSS statements, and the page will render in a plainer fashion.
JavaScript is a complete mess. It was originally invented by Netscape (cashing in on the name of Java, but has nothing at all to do with it). Netscape has some diabolical documentation of it (it's full of bugs, and only applies to their own browser). JavaScript is applied in various incompatible ways in different browsers (IE has a JScript perversion of it). A more standardised version has been developed, using the name of "ECMA-262" or "ECMA script." Browser support for scripting is varied, and is best avoided unless you absolutely require it (which usually isn't true, the author has just got some stupid idea in their head).
Sun invented Java, Microsoft created a bastardised incompatible version of it. Sun's Java engine is used in various different browsers, even the later versions of IE can use it; authoring for Sun's Java, ensures wider compatibility.
An on-line validator, to check web pages for HTML errors.
An on-line validator, to check web pages for HTML errors. They also offer a free downloadable validator, that you can run with your own webserver.
An on-line validator, to check for CSS validity.
(Useful information, but not what you'd call "authoritive.")
The site used to have information about many of the different browsers in use (there's quite a lot), listing all the known browsers for different computers systems, giving a brief summary of their features, and giving their website addresses; but it appears to have been bought out and replaced with a huge advertising whiz-bang technology gloat site (almost the opposite of the browser information site that used to be at that address).
When I find a new equivalent, I'll put it's address, here.
This site has a long-ish list of different browsers that are available. Unfortunately, it's little more than a list of different browsers, with links to pages where you could download the browsers (i.e. didn't have details about each browser, that I could see; it's not even categorised into browsers for different computer operating systems). The links were also a series of pages to click through, eventually ending up at a notice about where they could be downloaded from (providing direct links to the homepages of each browser, rather than to archive sites, may have been more practical; as I've done below, for Opera and Mozilla).
Some information about different browsers, lists of them, and other information.
Opera is one of the most standards compliant, and secure, web browsers. It's also a reasonably small sized file to download. It's written to adhere to the HTML, CSS, and ECMA script specifications, rather than trying to go their own way. If a website works in Opera, then it should work for just about all other browsers. It's available for a wide variety of operating systems, and a very handy browser for checking your pages, as you can very simply, and individually, toggle on and off; CSS interpreting, image loading, plug-ins, proxying, cookies, etc. (That's not referring to "error checking," by the way. No browser is suitable for that task, as browsers typically try to work their way around errors, rather than protest about them. But Opera does give you a quick and simple way to see how pages will look with, and without, images, styling, or scripting, etc.)
Mozilla is now an open-source project (i.e. the program code is not a secret, anybody can see exactly how it works, and use the information). There's a Mozilla webbrowser, and other browsers use its technology as their core (e.g. Beonex, K-meleon, and recent versions of Netscape). It's programmed with a goal of being "standards compliant," rather than hotch potch (as per MSIE), and is under peer review, rather than being at the mercy of a corporation only interested in making money. Mozilla is also available for various different computer operating systems, and competent programmers could create versions for even more systems.
If you'd like to refer anybody to a particular aspect of this page, then you may like to use these links (below). They link to the headings of each section.
This page was originally written using the W3C's Amaya browser/editor, has been checked for HTML 4.01 validity, and passed without any errors being detected. It should work, okay, on most web browsers; and is best viewed at whatever resolution suits you. Can you claim the same thing about your pages?
I (the author) originally published the page towards the end of 2002, at <http://homepages.ihug.com.au/~night-owl/morons.html>, then re-published it on <http://members.optusnet.com.au/~night.owl/morons.html>, when I changed ISPs. Which is its current location, as of March, 2003. If you're reading it from someone else's re-publication, you may wish to check this location for updated versions.
You're free to copy this page (in whole or part), put it on websites, send it to clueless website authors, or do anything else useful that you can think of doing with it. It's a single stand-alone file, and doesn't "need" the associated CSS files; though you're free to copy them, too. Nor does it "need" the other pages that this page links to; and copying the linked "write to the author" (me) page wouldn't do you much good, anyway. I recommend that you read the page source, and modify any links to things which aren't suitable (such as the links to my homepage and my "write to the author" page; and links to my stylesheets, if you don't copy them, as well). There's comments in the HTML, near those things, to give you some help. You do not need to seek my permission, nor have to attribute the page to me, though you cannot claim it as being yours (because it simply is not). If you feel the need to attribute it, then I suggest that you simply mention that the page was copied from this site, at whatever date that you did so. Linking to resources on this website is not advised; as their URI will not be permanent (I will drop this ISP if their service degrades, or they charge too much, and they would purge the site's contents).
So far, some
visitors might have checked this page (since October 29th, 2002); and before
they come back, they ought to know that the site may only be temporary (see
the previous sentence, for an explanation).