When the first visual browser (Mosaic) was released, things started to go wrong with web building: web technologies started to be misused, to achieve effects they were not (yet) designed to achieve. While a very common and natural drive, this creative use of technologies has got negative consequences on the quality of web products.
At that time, nobody talked yet about the layout of pages. It was a graphical user interface for an essentially text-based browser, and it was all about content (and ASCII art). The first additions like the ability to add inline graphics still served information purposes, although I suspect there were already some creative uses. Netscape 2.0 introduced tables, and things started to evolve dramatically. Proprietary extensions that were soon turned into the official HTML standard allowed webmasters to display tabular data, but their use was quickly repurposed. Tables and images and frames and font colors, designed as containers for a certain type of information, were being used for visual purposes.
The frame was supposed to separate independent elements of content and to allow the rational display of content and navigation, or more generally of pieces of content that are related but of a different nature. The actual use was pretty close to the original idea: here the content, there the logo and main nav, here the footer and copyright notice. However, empty frames were quickly added to emulate various behaviors deemed desirable by someone on the project team: to display only one URL for the entire site (at some point, some considered it clean!), or to center the site’s content in the browser window.
Similarly, tables were meant to organize information in lines and columns. However, it became clear pretty quickly that with invisible borders, tables could be organized to cut out regions of a controlled size in pages, to hold together in a visually satisfying manner various pieces of text or images, to selectively apply a background image or color, etc. More than abundant literature was written on the topic, and some graphic design packages even included the ability to produce table-based web layouts on the fly.
Again, inline images (i.e. embedded in the text) were intended to display, well, visual information: graphics, photos, logos, and the like. But those were soon repurposed to participate in layout and branding. A logo belongs to a page “this company’s logo”, but was instead being inserted on all pages of a site. Overall page visuals, as created by graphic designers, were being built out of bits of images put together in a totally meaningless manner–which looked good in a graphical browser. Large images containing everything (from the site’s identity to its textual content) were a way to fully control the layout. But the crowing glory of this practice was the spacer gif, a 1×1 pixel image which conveyed strictly no information at all, but enabled HTML coders to control the behavior of tables quite finely.
I’ll skip layers and scripts, <font> tags and other remnants of the first browser wars. The repurposing pattern is the same.
Creative (but unorthodox) use of technology
Creative minds were applied to the problem of creating visually appealing pages with the limitations of the very inappropriate tools we were given. And creative solutions were found. And the web started to look good. Designers became more and more astute at using those tricks, and attained a certain balance in the efficient but totally unorthodox usage of the technologies.
The problem here is that each site was creating its own standard of information encoding. This essentially defeated the original purpose of HTML and neutralized one of its most powerful uses: packaging information in a way that the computer can process. Basing their work on the reality that most users would access the content via a certain browser, web builders started tweaking their input until they were happy with the output.
What we want, ideally, is structurally correct markup: <h1> describing a top-level header, <blockquote> wrapping a quotation block, headers organized in a logical way, <strong> or <b> applied to mark emphasis, tables to display tabular data, etc. When you have this, any program capable of parsing HTML can be made aware of much of the content’s context, structure, and highlights.
But the actual practice was use to those structural elements for the visual effect they were having. And we would mix and match happily until the desired effect was reached, when viewed in a particular browser. Besides the enormously costly cross-platform discrepancies that arose from that practice, the consequence was HTML code that did not separate the content and its structure from the presentation.
Terrible consequences
All sorts of bad things happen when you do this, most of them related to the usefulness limits of non-intended use of technology:
- lessened impact on search engines, as related information may be technically unavailable for searches despite being visible to most of your visitors
- access difficulty for people with another browser than the one(s) you used as your reference target, such as people with a handicap
- bandwidth waste, as the ratio between content and markup in your HTML code plunges to abysmal levels
- terrible difficulties in maintaining the content, changing the layout, and dealing with new access technologies (mobile phone, PDAs, RSS feed readers).
Content may be pulled from the database of some Content Management System, and the ugly structural-markup-for-visual-purposes could be part of the display template. In that case, the last consequence obviously no longer applies. But then you get something else:
- content delivery must be handled on a per-method basis, with a different template handling the display for each different access method
And that does suppose that you only used clean markup when maintaining content in your CMS, which is not always possible (for example, browser-based rich-text editors such as the very clever and powerful HTMLArea deliver terrible code).
So the case behind standards-compliant, structurally correct HTML markup is the following: because it makes use of the features of HTML as they were designed, it is efficient in what it does (describing the nature of various pieces of content that compose a document), and it is future-proof (if need be, good but deprecated markup can be converted to a newer version).
This does matter
In the practice, this must serve as a warning against creative and entirely unintended uses of a technology in the domain of content management, storage and maintenance. Of course, we’re talking here about taking this element into account in your decision process: in some cases, the short-term benefits may outweigh the long-term drawbacks. Sincerely going through the list of negative aspects above with then next few years in mind may help finding a site’s sweet spot in this compromise.
One should be careful to not misunderestimate the costs of the drawbacks above:
- “searchability” (increasing your site’s affinity with search engine spiders, ensuring that the site’s information registers in search engines) greatly increases the impact of a site, and is a very affordable improvement. Many other factors are important, such as the number and wording of links leading to your site, but this can still help very much, particularly for specialized content (business-specific vocabulary, original content, etc.).
- while a limited population might not seem to be worth the effort, bad press, customer complaints and legal pressure may force you to produce that effort in the end. And then, patching things up once the site is up is often more expensive than planning them in the first place.
- bandwidth waste may sound ludicrous now, in our days of cheap and plentiful broadband access. But bandwidth usage is not always free (and I contend that it shouldn’t but that’s another issue), and if it is, the hosting provider may choose to shut down your site for abuse.
- at this point, many sites are generated from the database of a CMS, and therefore the impact of the content repackaging issue is limited. However, the arrival of new browsing methods (say the iMode deal between mm02 and DoCoMo) may be important for a given site, and the repackaging trajectory may be more or less costly depending on the current state of the site.
Assessment
In the context of a particular web site, the web builder will have to assess the importance and relevance of the various factors influencing the technical realization. The checklist above can help, but many other factors come into play, such as the intended audience and its social and technical characteristics, the expected lifetime of the site, as well as its lifecycle (the way it will be built, used, reused, and archived or destroyed). And the cost of standards-compliant building must be taken into consideration.
In this regards, here are a few hints:
- if your provider charges you an arm and a leg, he’s probably doing it for the first time and will need the money, as habits die hard and several jobs need to be done in a radically different manner
- if your provider charges something extra, I suppose that’s fair game: tables-based layout is easy to build and rather reliable, while CSS-based layout on the top of structurally correct HTML is still quirky
- if your provider does not insist you should go the standards-compliant way, he’s not being serious, or he hasn’t understood the long-term implications for you (that’s unless it clearly doesn’t matter for your site)
Building for an intranet with a very controlled park of machines and browsers is not really an argument against standards-compliant building, but may only be considered in combination with other, more compelling factors.
As I see it, the single most relevant reason for building a site that is not standards-compliant is time: if you are creating an event site which will be taken offline within a few weeks or months of its inception. In that case, layout and content will probably be extremely tightly integrated (as in “rich media” sites…), and you won’t care much about the drawbacks mentioned above. In that case, you’ll possibly even want to go down the Flash road, which is a topic I won’t cover now.
But in most other cases, there is simply no reasonable business case to be made for non-standards-compliant web building, as it is simply too costly in the long term, while not being necessarily expensive in the short term.
What can you do
The first piece of advice is: find a web agency that understands the value and the challenges of standards-compliant design.
At Splandigo, we have learned the hard way that just switching over to such building methods wasn’t simply a case of reading a few good books and “doing it”:
- the graphic designers should be aware of and familiar with the characteristics and peculiarities of good HTML+CSS web sites, to use it at its best
- someone has to be responsible for content markup and structure, which is a different job than HTML coding (but requires the same understanding of the technology), and a different job than copywriting (but requires the same understanding of the content and the communication objectives)
- the technology must be tamed for that specific use: some CMSs simply can’t handle this in a proper way
- all stakeholders should be (made) aware of the benefits and requirements
In this document, I have specifically not covered what was actually needed for standards-compliant web building. This could be the subject of another post, but much is already available on the topic, particularly from A List Apart and Zeldman.
The business case for standards-compliant code
When the first visual browser (Mosaic) was released, things started to go wrong with web building: web technologies started to be misused, to achieve effects they were not (yet) designed to achieve. While a very common and natural drive, this creative use of technologies has got negative consequences on the quality of web products.
At that time, nobody talked yet about the layout of pages. It was a graphical user interface for an essentially text-based browser, and it was all about content (and ASCII art). The first additions like the ability to add inline graphics still served information purposes, although I suspect there were already some creative uses. Netscape 2.0 introduced tables, and things started to evolve dramatically. Proprietary extensions that were soon turned into the official HTML standard allowed webmasters to display tabular data, but their use was quickly repurposed. Tables and images and frames and font colors, designed as containers for a certain type of information, were being used for visual purposes.
The frame was supposed to separate independent elements of content and to allow the rational display of content and navigation, or more generally of pieces of content that are related but of a different nature. The actual use was pretty close to the original idea: here the content, there the logo and main nav, here the footer and copyright notice. However, empty frames were quickly added to emulate various behaviors deemed desirable by someone on the project team: to display only one URL for the entire site (at some point, some considered it clean!), or to center the site’s content in the browser window.
Similarly, tables were meant to organize information in lines and columns. However, it became clear pretty quickly that with invisible borders, tables could be organized to cut out regions of a controlled size in pages, to hold together in a visually satisfying manner various pieces of text or images, to selectively apply a background image or color, etc. More than abundant literature was written on the topic, and some graphic design packages even included the ability to produce table-based web layouts on the fly.
Again, inline images (i.e. embedded in the text) were intended to display, well, visual information: graphics, photos, logos, and the like. But those were soon repurposed to participate in layout and branding. A logo belongs to a page “this company’s logo”, but was instead being inserted on all pages of a site. Overall page visuals, as created by graphic designers, were being built out of bits of images put together in a totally meaningless manner–which looked good in a graphical browser. Large images containing everything (from the site’s identity to its textual content) were a way to fully control the layout. But the crowing glory of this practice was the spacer gif, a 1×1 pixel image which conveyed strictly no information at all, but enabled HTML coders to control the behavior of tables quite finely.
I’ll skip layers and scripts, <font> tags and other remnants of the first browser wars. The repurposing pattern is the same.
Creative (but unorthodox) use of technology
Creative minds were applied to the problem of creating visually appealing pages with the limitations of the very inappropriate tools we were given. And creative solutions were found. And the web started to look good. Designers became more and more astute at using those tricks, and attained a certain balance in the efficient but totally unorthodox usage of the technologies.
The problem here is that each site was creating its own standard of information encoding. This essentially defeated the original purpose of HTML and neutralized one of its most powerful uses: packaging information in a way that the computer can process. Basing their work on the reality that most users would access the content via a certain browser, web builders started tweaking their input until they were happy with the output.
What we want, ideally, is structurally correct markup: <h1> describing a top-level header, <blockquote> wrapping a quotation block, headers organized in a logical way, <strong> or <b> applied to mark emphasis, tables to display tabular data, etc. When you have this, any program capable of parsing HTML can be made aware of much of the content’s context, structure, and highlights.
But the actual practice was use to those structural elements for the visual effect they were having. And we would mix and match happily until the desired effect was reached, when viewed in a particular browser. Besides the enormously costly cross-platform discrepancies that arose from that practice, the consequence was HTML code that did not separate the content and its structure from the presentation.
Terrible consequences
All sorts of bad things happen when you do this, most of them related to the usefulness limits of non-intended use of technology:
Content may be pulled from the database of some Content Management System, and the ugly structural-markup-for-visual-purposes could be part of the display template. In that case, the last consequence obviously no longer applies. But then you get something else:
And that does suppose that you only used clean markup when maintaining content in your CMS, which is not always possible (for example, browser-based rich-text editors such as the very clever and powerful HTMLArea deliver terrible code).
So the case behind standards-compliant, structurally correct HTML markup is the following: because it makes use of the features of HTML as they were designed, it is efficient in what it does (describing the nature of various pieces of content that compose a document), and it is future-proof (if need be, good but deprecated markup can be converted to a newer version).
This does matter
In the practice, this must serve as a warning against creative and entirely unintended uses of a technology in the domain of content management, storage and maintenance. Of course, we’re talking here about taking this element into account in your decision process: in some cases, the short-term benefits may outweigh the long-term drawbacks. Sincerely going through the list of negative aspects above with then next few years in mind may help finding a site’s sweet spot in this compromise.
One should be careful to not misunderestimate the costs of the drawbacks above:
Assessment
In the context of a particular web site, the web builder will have to assess the importance and relevance of the various factors influencing the technical realization. The checklist above can help, but many other factors come into play, such as the intended audience and its social and technical characteristics, the expected lifetime of the site, as well as its lifecycle (the way it will be built, used, reused, and archived or destroyed). And the cost of standards-compliant building must be taken into consideration.
In this regards, here are a few hints:
Building for an intranet with a very controlled park of machines and browsers is not really an argument against standards-compliant building, but may only be considered in combination with other, more compelling factors.
As I see it, the single most relevant reason for building a site that is not standards-compliant is time: if you are creating an event site which will be taken offline within a few weeks or months of its inception. In that case, layout and content will probably be extremely tightly integrated (as in “rich media” sites…), and you won’t care much about the drawbacks mentioned above. In that case, you’ll possibly even want to go down the Flash road, which is a topic I won’t cover now.
But in most other cases, there is simply no reasonable business case to be made for non-standards-compliant web building, as it is simply too costly in the long term, while not being necessarily expensive in the short term.
What can you do
The first piece of advice is: find a web agency that understands the value and the challenges of standards-compliant design.
At Splandigo, we have learned the hard way that just switching over to such building methods wasn’t simply a case of reading a few good books and “doing it”:
In this document, I have specifically not covered what was actually needed for standards-compliant web building. This could be the subject of another post, but much is already available on the topic, particularly from A List Apart and Zeldman.