Windy Barnacle

(this should be about a 10 minute read. if you don't have time, please jump to the conclusion )

The old fuddy-duddy days

we probably all started doing HTML years and years ago. if you're as old (and grumpy) as i am, you may have even begun "Web" development before there was even a graphical aspect to it -- for terminal-based programs such as gopher or lynx.

content meant for consumption by these browsers was completely free of pretense, and organized into simple structures meant to increase organization and readability. basic elements like Definition Lists, Ordered and Unordered Lists, Tables for displaying grids of data, and Paragraphs for content, were all we had to work with.

GUIs arrive and thrive

when graphical browsers were introduced (Mosaic, Netscape, Internet Explorer), the paradigm shift was dramatic. individuals, organizations and companies quickly realized that the web was medium to transmit information in a way that could be as visually appealing as a printed brochure or book, yet with a ubiquitous (and mostly free) channel of distribution.

the need to create complex graphical layout was immediate; the standard for the language in which to transmit it, however, could not be updated so quickly. we as Web developers took those logical structures of the past and manipulated them to create graphical layouts to match these needs.

HTML hacking becomes an art

no longer was a table a gridded container for displaying two-dimensional data; the table became the defacto standard for page layout. nobody was concerned whether the consumer would be able to receive and understand it, because there were a limited number of browsers available, and the capabilities of the consumer pretty closely matched those of the developer.

more importantly however, the consumer was someone who opted-in to the Web; nobody was using it for necessary things that had to be accessed by all varieties of people in society.

ADA - things change

as the Web grew more ubiquitous, Web-based applications came to replace older and more costly In-Real-Life processes. as more and more people were required to use the Web, a problem arose. some people with limited faculties had a hard time accessing these resources.

any tool devised to assist these users had to be able to intuitively parse the HTML received -- to present the relevant information, and help the user navigate. one big problem here - the HTML elements were no longer being used for their logical purpose.

Back to the basics

there was a backlash that led, in some sectors, to a dramatic ratcheting-back of functionality in order to make content and applications universally accessible. while not a bad thing, it did serve to temporarily stifle innovation. but it eventually led to a renaissance movement for Web application and browser developers, alike.

WCAG, web standards

yes! we've finally hit the meat of the article. from accessibility requirements comes the Web Content Accessibility Guidelines. in short -- a framework for the application developers and the browser/reader tool developers to meet somewhere in the middle. if both parties adhere to the same standard, then the end user experience should be positive, no matter what tool they're using.

what does this mean for the HTML code? back to the rigors of long ago - lists, data tables. containers for content. simple, semantic markup.

Wait, what happened to pretty?

let's look at that. how do we achieve design today? thankfully we've moved away from egregiously nested tables and other such deplorable hacks (i hope) to make our applications look good. the ability to apply Style attributes to nearly any HTML element means that we can use semantic markup, while still applying the appealing visual layout that our business owners and customers want. but how best to achieve this?

while it's easy to add a style="" attribute to an HTML tag, or even use the time-tested attributes for border="" width="", etc. these things should be avoided at all costs. why?

Good coding standards are universal

let's approach this like a programmer would. you have a value you need to display in your application, let's say -- it's a fee. this fee can change at any time. you may want the fee to be different based upon what area of an application you're in. you may want the fee to be different based upon who the customer is. you may want the fee to be different depending on the time of year, or due to a recent event.

would you hard-code that value into every .asp/.aspx/.jsp/etc. file, only to have to go find it later and change each instance? not only would this be tedious, it would open you up to the risk that the wrong fee might be displayed in some far off forgotten corner of your application.

painful to maintain + risk = bad coding practice. you would instead abstract the value of the fee out to a config file or system of record, and replace it in each .asp/.aspx/.jsp/etc with a token to be replaced when the page is loaded.

Apply the same coding standards to design

every time you put style="" or border="" into an HTML element - it's just like you're hard-coding that fee into every page.

please re-read the statement above. i can't emphasize this enough.

the business wants the flexibility to adjust the graphical presentation of our site based upon who the customer is, where they are in the application, the time of year, or due to events or changes in branding strategy. we need to have these style values abstracted out of the HTML and into CSS files in order to be able to re-style the website as needed.

moving all presentation-related variables to the CSS is good for:

developers

post-processed HTML code that is well-structured and easy to read helps developers understand how elements are rendered on a page

bandwidth

if you've heard the term "Gomez" at least a hundred times in the past year, you should understand that small, lightweight HTML pages benefit our customers! and additional benefit is achieved in page-over-page download times. think about it - the style information is downloaded once per browsing session. after that, it's just lightweight HTML that's being sent

accesibility

clear, semantic markup means that our applications can be used by anyone who has a web browser/reader that was written to meet the WCAG standards

ubiquity

small, lightweight HTML pages mean our applications will be able to move to new and emerging platforms like mobile phones and PDAs - and whatever interface is waiting to be invented in the not-too-distant future.

in conclusion

HTML should be simple and semantic. it should be well-formed, and elements should be used as they are intended (lists, tables, containers).

CSS should contain all design-related data, so that it can be universally and consistently changed.

our applications should be compact and maintainable. the HTML produced by them should be easily transmitted and parsed by the browser/reader.

the design of our site should be flexible so that it can closely match the brand strategy put forth by our business owners.

none of these things can happen until we stop using style and other in-line formatting.

thanks for reading!