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. Stop being an nuisance, and learn how to write websites properly!
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 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. 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," (that'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 and more non-computer appliances are being used for the internet, 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.
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.
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 unvisited links, as their default colours, anyway.
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.
Writing documents in a way that the content can readily squeeze and stretch to the current width of the browser, is the proper way to do it. 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.
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.
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.
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 could simply ignore graphics, and browse without having to wait for them. Sites using SSL, should be written lean (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 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.
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.
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).
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 exluding 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 deceitfull, and even doing it openly is dispicable. 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.
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 hunting through the page to find where the links are. 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). And the opposite 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.
Writing "click here" for all your links looks very amateurish, and ignores the fact that not everybody "clicks" on a link with a mouse. 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, as 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 accessable).
ECMA is an international industry association founded in 1961 and dedicated to the standardization of information and communication systems. Their website presents all aspects of ECMA and makes available the results of the ECMA standardization 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.
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).
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 for CSS validity.
Information about many of the different browsers in use (there's quite a lot).
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.)
This page was 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?
You're free to copy this page, 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 file; though you're free to copy that 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. Linking to files on this website is not advised; as their URI may not be permanent.