[111Design.ca]

111Design Consulting

Supporting Industry Standards and Accessibility [Navigation]

Menu

[Dead End]

why the standards exist

software issues

People who create Websites need to understand it's the software, not the programming languages, and certainly not the standards that are flawed. Code to the standards, and eventually all browsers will get it right. The trouble is, most Web designers are not programmers, and many have no idea that "Web Standards" even exist. They have little or no understanding of how browsing devices, search engines, and HTML editors work. I know "professional" designers who rely on their WYSIWYG editor (a Web-authoring tool that formats text for you) for what reason I could never understand. They never bothered to learn HTML?? These programs generate rheems of invalid and unneccessary code. Hand-coding on a plain text editor is the only way to ensure valid markup.

A full explanation of the Standards is beyond the scope of this article, though I've included some tutorials elsewhere on the Site. The W3C is the "horse's mouth". So if you need to look something up, go there. Don't count on other tutorial Sites being correct or up to date. Most importantly, validate your markup (that includes validating CSS) every time you make a significant change to it. Don't give up because the report shows 156 errors. One small mistake can cause a cascade of error lines. It will be easier to find where you first went wrong if you stay on top of things.

defective browsers

One big unresolved problem to this day is, browsers that do not conform to the Standards. In order to make layouts display consistantly, designers will resort to browser-specific hacks¹ that cater to each one's rendering bugs. It then becomes necessary to write multiple versions of the Site, and to use messy javascripts that redirect the user to the appropriate page. This method is not reliable. Opera, for instance, can identify itself as Netscape—or Internet Explorer (or Opera). And what about users who surf with javascript turned off?

Other designers have their favourite browser and code for it alone—an especially bad practice if that browser happens to be Internet Explorer for Windows. Internet Explorer (the default browser installed on every Windows PC) will render a page containing hundreds of coding errors intelligibly enough for the content to still be readable. Without passing such pages through an HTML validator, horrific mistakes can escape unnoticed... until the customer complaints start pouring in. Cross-browser compatibility testing is still an essential step in the design process.

In my opinion, Netscape 4 was not a complete disaster. Before you start jumping up and down, let me explain. Despite its instability and zero DOM support, it had this nifty behaviour its competitor lacked—It outright refused to display pages containing open or improperly nested tags. Future browsers may behave similarly. Icab for the Mac OS, though not Standards-compliant (as of the date this article was written) will indicate when a Web page has deviated from the core Standards. If all browsers did this, designers would be forced to write valid code or risk looking awfully foolish.

Contrary to popular belief, Internet Explorer (for Windows) is not Standards compliant.

2007/04/10: For years I held my breath waiting for Microsoft to "get with the program" only to be let down again. The recently released IE7 falls sadly short of the mark. Its CSS support is still terrible.

For a list of browsers that are Standards compliant, visit our Browser Watch page.

barriers

Most of the Web sites on the Web are not valid (markup). We may assume that this is the case for 99% of the Web pages, but there are no statistics to support this. —Karl Dubost, Conformance Manager, W3C*

Fraudulent claims of Standards-compliance are a whole other ball game. Anyone who does this deliberately deserves to be blacklisted and publically flogged.

Something few people realize is, how individual Websites effect the Web as a whole. Try to imagine the Internet as a living entity. Now think of what happens when a biological organism's component parts aren't functioning properly... The whole organism gets sick! No, I'm not expecting the Internet to become sentient any time soon. People—programmers, designers, Internet Service Providers, and hosting companies control how we experience the Web. I'm sure this will be the case for many years to come. But with the huge number of badly designed Websites out there—and the questionable methods some advertisers are using to deliver content, surfing the Web can feel like strolling through Central Park after midnight. "Drive-by-downloads" are just the latest threat users need to contend with.

While ordinary Web pages that contain coding errors are unlikely to damage your computer or steal your passwords, they can and do cause crashes and lock-ups. It's unfortunate that some Websites with excellent content get burried in the search engine results. But that's what can happen if they are coded poorly. A Semantic Web will only be possible when the majority of Websites validate. And until Dreamweaver, Frontpage, and other web-authoring tools become "smarter", the average person will not be able to write a valid Web page. The Internet, as it exists today does not work nearly as well as it should.

It seems no one was thinking much about the future when all of this got started. The commercial potential of the Web created a high demand for design services and WYSIWYG editors, which, in their great haste to exploit this demand, churned out badly formed documents faster than you could say "Netscape sucks". (Incidentally, Netscape no longer sucks. It's better than IE.) Browser vendors compounded the problem by allowing such documents to be displayed, more or less as the author intended them to, in "quirks" or "bugs" mode. The "better"(?) browser would ignore (forgive, attempt to fix, or guess at) bad coding, thereby encouraging it. This will not always be the case.

It may never be an issue for Aunt Martha's personal Home page—Her friends all run Windows with Internet Explorer at its default settings. But badly designed public Sites stamped with a "best viewed in Browser 'X'" banner are inexcuseable. If the viewer is unable to download and install Browser 'X' with plugin 'Y' (and who says he would even want to?), he is unable to use it. The same goes for sites that are designed for a specific screen resolution.

Consider the following:

  1. Pages that present a barrier to certain browsing devices are likely to be inaccessible to search engines as well.
  2. Improperly marked up documents—and unethical practices for tricking the Search Engines degrade their overall performance.
  3. Recent changes in the law regarding Internet Accessibility are more than just encouraging designers to write Standards compliant documents. If a Site does not meet the necessary requirements, its owner could get sued.

forwards compatibility

Badly designed Websites are bad for everyone, not just handicapped users. Small screen wireless devices have difficulty rendering invalid or proprietary code. These Sites have a direct impact on the usefulness of the Internet as a whole.

Backwards compatiblity means forwards compatibility as well. A Site that requires Internet Explorer 5+/ Windows with Macromedia Flash plugin, 1024x768 screen resolution, and javascript enabled, does not work in a PDA. »

Footnotes
 
1. Instead of using the semantically correct "abbreviation" tag (abbr), which is not supported in Internet Explorer, designers have begun using styled span tags to provide explanations for abbreviated terms and acronyms—just for the benefit of IE users. This does nothing to distinguish the letters from a text-reader's perspective. I'm assuming a program like JAWS (JAWS, incidentally, is an acronym) will attempt to pronounce the contents of the span. Other designers use acronym for everything, simply because it works in IE. Abbreviations and acronyms are two different things. The acronym tag should only be used when a new word is formed from the initials. "HTML" is not an acronym, whereas NATO is. Nesting the appropriate tag within a span is perfectly valid and will help IE users:
 
<span class="explain" title="HyperText Markup Language"><abbr>HTML</abbr></span>
 
renders as: HTML
 
Define the class in your screen and handheld style sheets:
.explain { border-bottom: dashed 1px #fff; cursor: help; }
 
To apply this to individual tags:
<span style="border-bottom: dashed 1px #fff; cursor: help;">
 
And finally, you could create a simple aural stylesheet for text readers:
abbr { speak: spell-out; }
acronym { speak: normal; }

Copyright © 2003-2009, 111Design.ca