Thursday May 3, 2007
Web Standards Basics
If you’re a technical architect, you’re probably already familiar with the general idea behind distributed architectures such as Service-Oriented Architecture (SOA), model-view-controller (MVC) or other multi-tier (n-tier) architectures. There’s a wide range of definitions for these, but they’re similarly minded toward a set of loosely-coupled layers. Put another way, the system is comprised of several smaller and more specialized components that work together to form the system as a whole. With a standard means of communicating between components, it’s not that hard to make changes to a single component if business rules change. If there wasn’t that separation between layers, it could be more costly to track down and implement changes within the system.
There’s a similarly modular approach specific on the presentation-layer side of the fence, “Web Standards”. An approach based around Web Standards allows for the separation of the components within the presentation layer into their own specialized layers, yielding benefits along the same lines as those on the SOA side.
The term “Web Standards” refers in part to specifications published by the World Wide Web Consortium (W3C), an industry standards body established in 1994. Web Standards are more than just following a set of rules, however — it focuses on accessibility to users with disabilities, ease of maintenance, and a flexible structure which to accommodate design adjustments.
Let’s take a closer look at the three primary components on the browser (client) side of an application and the benefits to keeping them separated.
Content is the message that you’re trying to get across. If your application were a movie, the content would be the typed script. For a website, this would include the copy, form fields, and data for each page.
Styling is the pretty stuff — the fonts, colors, and general look-and-feel on a page. Of course, the page’s layout (the way the content is visually organized on the screen) is also an element of visual style.
Behavior refers to how the page interacts with the user. For example, a page may include real-time form validation (did the user remember to enter his or her last name? ) or more elaborate features such as realtime calculations.
Markup Over The Years
Content is represented in code through markup, most commonly HTML or XHTML. Back when HTML started, it was used as a way to describe the structure in a page. Over time, however, demand swelled for prettier pages and, without a means to separate presentation from structure at the time, browser makers took things into their own hands. This happened around the same time period as the browser wars of the mid-to-late ’90s. In all, this brought about a fierce battle of one-upmanship as browser-makers cobbled together presentation and styling features into their products. Though the browser wars are now ancient history, it’s not uncommon to encounter code that uses these techniques of years past rather than their more modern equivalents. Though it’s getting more and more rare, you may come across the occasional font tag to change the color of the text on a page. Or, you might see some inline JavaScript to provide simple interactions like mouse-over effects or field validation. While it may be tempting to reach for additional attributes, using them is equivalent to gathering debt — it may seem harmless in the short term, but you can very quickly to dig yourself into a hole which can be deceptively difficult to climb out of.
Tip 1: Use Validated XHTML Exclusively for Content
Rather than letting the markup become cluttered with styling and behavior-related code, web standards allow the markup to focus on the content alone (without the styling and behavior bits getting in the way). With the addition of few classes and IDs in the mix, CSS can contribute styling to the document, while DOM Scripting can add in some interactivity.
Tip 2: Use Validated CSS for Layout and Styling
With Cascading Style Sheets (CSS), developers can gather a set of rules for visual styling and page layout all in one place. Quite a few benefits come out of that:
- Visual styling can be applied consistently across a site based on a centralized set of rules.
- Page layout can be much easier to maintain when all the layout-related code is separated from the structure of the page. This is in contrast to table-based layouts, where the layout-related code is entangled within the structure of the page.
- Media-specific style sheets allow for a page to be rendered differently in situations where it’s not being read off a monitor, such as when it’s printed or viewed on a PDA.
There are many other advantages of CSS. See the notes at the end of this post for other helpful references.
Tip 3: Use DOM Scripting for Behavior
Taken as a whole, a document’s tree-like structure of elements and attributes (including classes and IDs) is known as the Document Object Model. This, of course, is what allows CSS to act on a document; in the same way, JavaScript can also reference the elements based on these hooks. Through the use of DOM Scripting, CSS and JavaScript alike can be associated with classes and ids within a document. With DOM Scripting in place, a page avoids the need for any JavaScript-related code within the body of the document, relying instead on a script tag pointing to an external JavaScript file.
Web Standards Saved Us Time On Our Last Project
You may be surprised to learn that it doesn’t take any more time to plan and design web standards compliant code. Once that’s in place, additional time savings add up quickly as the project moves along and business requirements change. Compared with coding techniques of years past, Web Standards offer a significantly reduced maintenance footprint. On my last project Web Standards came through for us several times, especially later on in the schedule.
A few simple examples:
- When a requirement was introduced that we implement a 3rd-party web analytics tool, DOM Scripting allowed us to write a single portion of code which could derive each page’s individualized page-level data necessary for click-path reporting. If we had followed the vendor’s recommended instructions, we would have ended up touching every page in the site only to add some nearly-redundant code that was ever so slightly different from one page to the next.
- With the addition of a requirement that all external links open in a new browser window, DOM Scripting allowed us to keep the markup clean. We were able to make use of a simple
rel=”external”attribute on links to assign that new-window behavior as needed.
Get Started With Web Standards on Your Next Project
It’s generally easier to make use of Web Standards right from the start of a project (as compared with trying to recode an existing site or application). If you’re on board with Web Standards from a project’s design phase forward , a little planning will ensure that developers are up to speed on the concepts. From there, you’ll have a foundation for a clean separation between content, styling, and behavior. It’s a lot harder to dig yourself into a hole if you’re not even taking the shovel out of the garage.
Web Standards Resources
- The Web Standards Project FAQ has a great overview on “What are the standards?” and “What are the advantages of using Standards?”.
- Russ Weakley’s Selectutorial and Floatutorial offer excellent introductory tutorials on CSS selectors and CSS floating, respectively.
- The Web Standards Project’s JavaScript Manifesto provides more on JavaScript and DOM Scripting.
- Jeremy Keith’s article “Behavioral Separation” on A List Apart walks through these ideas with actual code samples.
- Michael Montgomery’s presentation “Web Standards for Skeptics” from RefreshMiami on May 16, 2007.
Special Thanks – Alex Bischoff was a great help with this article, loaning his editing talent for both the content and (grammatical) styling. Thanks, Alex!
Comments on “Web Standards Basics”
EMC helps organizations create superior IT environments, from infrastructure solutions all the way up to software development and user experience design.
Learn more…About This 404er
Mark Kraemer
Mark is an Information Architect and Principal Consultant at EMC in Dallas. His professional life is a Venn diagram, where he lives in the intersection of the folks who wear suits and the designers who wear flip-flops. You can catch his other ramblings on user experience and design at his personal blog, Mark-up.
Great article!
I was a bit surprised to find this article here
I’ m not really sure which audience is reading the Geniant Blog, but I thought it was mainly web-developpers who knows advantages of separating content from style etc ..
Whatever, it’ s a good article to sum up the “valid” behaviour we all should use.
@dagobert renouf – As for the audience of the Geniant blog, and our reasons for writing, I would refer you to Dave’s initial article Why Are We Blogging.
Realizing that most of the people who read blogs related to web design and development are themselves either web designers or developers, we also think of our blog as a venue to informally inform clients about our methods. While some of these articles may be more basic, I am glad you appreciate their inherent value as well.
@Nathan Smith – My aplogizes, I did not read this “prologue” article. Writing a blog is a good way to show clients what web constraints are and how web-developpers do improve user experience.
@dagobert renouf – No apology needed. :)
Thanks for the replies, Nathan and Dagobert. Indeed, this article was targeted towards technical architects and developers who already embrace the value of separation elsewhere in the technical architecture, but are not familiar with ways to apply separation on the front-end. While our community of web developers and designers are already familiar with these concepts, the IT industry as a whole is not. As a quick example, 4 of the Fortune 5 sites are still using tables for layout on their home pages. That’s a small but telling example of how the global IT industry is a long way from universal adoption of web standards.
An interesting article for the future might be the evolution of the role for “front-end developer.” Before I joined Geniant, I worked for a mid-sized consulting firm with lots of very talented people. The area of CSS and DOM Scripting was almost a no-man’s land between UI designers and application developers. Both parties dabbled in front-end development, but usually did just enough to deliver the application. Neither side owned the craft of good code on the client-side the way I have seen the UXD group step-up at Geniant. I haven’t seen developers at any of my previous clients that have been dedicated to front-end code either.
Other than design/web-development firms, does anyone out there have an example to share from industry of a company with an individual or team that’s focused on front-end development, separate from general application development?
I’m soooo referencing this in my upcoming presentation on WHY WE SHOULD BE following web standards in our site & application development to my development team. I’m a lonely advocate (and the only real web designer) in my large corporate setting & trying to get them to go forward with accessibility & standards in mind. The issue we have here is that we have so many custom apps in place that retrofitting everything would be impossible. Or at least I’ve been told it would be near impossible…if anyone has any insight on that…I’d be game to listen.
Anyway, thanks for the article.
Deanna – Refactoring is almost never a viable option. A more feasible goal, as we’ve found, is to expect a constant movement in the appropriate direction. As different pieces are being built and or rebuilt for other reasons, it’s important to build them correctly at that time. There’s generally not a financial justification just for retro-fitting, but if it can be done as pieces of the sites or applications are being updated, it's usually justifiable. Of course, this isn't as easy as rebuilding from scratch, but if it's the only option, then it's better than nothing.
Rome wasn’t built in a day. :)
@Deanna – you mentioned that you’re presenting to your technical team? That’s exactly who this article is geared to. Many architects already understand the value of separation. Just showing them that it’s possible (and beneficial) to separate the functions of the presentation layer should go a long way towards convincing them to re-factor and move forward with web standards.
Good luck! Let us know if we can help.
Great article! really informative!!
This is a good introduction to Web standards.
There is others :
* the presentation “Basic Webstandards Workshp” by Russ Weakley http://www.maxdesign.com.au/presentation/workshop/
* the Kit Maccaws http://www.maccaws.org/kit/.
Thanks for this comprehensive web standards review!