Adapting to Web Standards: CSS and Ajax for Big Site pot

First, on the UI layer, conforming to Web standards means 100% separation of presentation from content and structure, as well as the scripting behavior of UI elements.. The distinct area

Find us on the World Wide Web at: www.newriders.com

To report errors, please send a note to errata@peachpit.com

New Riders is an imprint of Peachpit, a division of Pearson Education

Copyright © 2008 by Christopher Schmitt and Kevin Lawver

Project Editor: Victor Gavenda

Production Editor: Hilal Sala

Development Editor: Wendy Katz

Copyeditor: Doug Adrianson

Tech Editor: Molly Holzschlag

Proofreader: Doug Adrianson

Compositor: Kim Scott, Bumpy Design

Indexer: Emily Glossbrenner

Cover design: Charlene Charles-Will

Interior design: Kim Scott, Bumpy Design

Notice of Rights

All rights reserved No part of this book may be reproduced or transmitted in any form by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the publisher For information on getting permission for reprints and excerpts, contact permissions@peachpit.com.

Notice of Liability

The information in this book is distributed on an “As Is” basis without warranty While every precaution has been taken

in the preparation of the book, neither the authors nor Peachpit shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the instructions contained in this book or by the computer software and hardware products described in it.

deadlines often crush progress

Written to empower the individual designer and the large organizations to start working in the

cor-rect dicor-rection, Adapting to Web Standards required the involvement the hands of a great number of

professionals

If you know Rob Cherny, you know a true Web specialist He seems to cover every aspect of the DOM His

presence is felt in the core of this book from the introduction up through the fourth chapter

I’m not sure how Kimberly Blessing came into the book project I believe it was during one of those mad, late night pushes to get edits and reviews out the proverbial door when she chimed in to offered to write about managing Web standards That turned into Chapter 5 of the current book I’m grateful for her time and sup-port for this project

Special thanks go to Meryl K Evans, the content maven She stepped in at the right moment to help tackle the Tori Amos chapter

I was honored when I talked to Kevin Lawver about building off his panel idea and turning into a book, he not only supported it, but also wanted to be a part of the process He did an amazing job in capturing a small part of the Web standards process at AOL

Thanks to the illustrator Rebecca Gunter for the illustrations for Kimberly’s chapter You can find more of her work at http://soap-committee.deviantart.com/

Many thanks go to Molly E Holzschlag for doing the technical editing chores of the book Not sure how she had the time to do this among her various other activities, but I’m sure someone who has written thirty-plus books on Web development like she has could find the way See http://molly.com

Wendy Katz and Doug Adrianson helped guide the creation of the book with their timely questions and editing skills

Thanks to Victor Gavenda and Michael Nolan from Peachpit Press/New Riders for guiding the book from concept to reality

As anyone who has ever written a chapter for a book, it’s not easy It’s a commitment demanding time and focus that keeps people away from weekend getaways or get-togethers with friends and loved ones I want

to let the ones closest to me know that I’m looking forward to our seeing you all and not boring you with talk about Web standards

For a while, at least

Christopher Schmitt

christopherschmitt.com

Lead Author

An award-winning web designer who has been working with the Web since 1993, Christopher interned for both David Siegel and Lynda Weinman in the mid 90s while he was an undergraduate at Florida State University working on a Fine Arts degree with an emphasis on Graphic Design Afterwards, he earned a Masters

in Communication for Interactive and New Communication Technologies while obtaining a graduate certificate in Project Management from FSU’s College of Communication

In 2000, he led a team to victory in the Cool Site in a Day competition, where he and five other talented developers built a fully functional, well-designed Web site for a nonprofit organization in eight hours

He is the author of CSS Cookbook, which was named Best Web Design Book of

2006, and one of the first books that looked at CSS-enabled designs, Designing CSS Web Pages (New Riders) He is also the co-author of Professional CSS (Wrox), Photoshop in 10 Steps or Less (Wiley) and Dreamweaver Design Projects (glasshaus) and contributed four chapters to XML, HTML, XHTML Magic (NewRiders)

Christopher has also written for New Architect Magazine, A List Apart, Digital Web and Web Reference

At conferences and workshops such as Train the Trainer, Web Visions and SXSW, Christopher demonstrates the use and benefits of accessible and standards-based designs He is the list moderator for Babble (www.babblelist.com), a mailing list community devoted to advanced web design and development topics

On his personal web site, www.christopher.org, Christopher shows his true colors and most recent activities He is 6' 7" and doesn’t play professional basketball but wouldn’t mind a good game of chess

Kimberly Blessing is a computer scientist, technical leader, and Web standards

evangelist At PayPal she leads the Web Development Platform Team, which is responsible for driving the creation and adoption of standards through training and process She co-leads The Web Standards Project, a grass-roots organization that advocates standards-compliance and use to browser manufacturers and developers alike A graduate of Bryn Mawr College’s Computer Science program, Kimberly is also passionate about increasing the number of women in technology Her on-line presence is at www.kimberlyblessing.com

ambiguous space between the creative and technical teams

Rob has introduced Web standards-based solutions as both an employee and a

consultant for a broad range of clients including Sallie Mae, Sunrise Senior Living,

the American Red Cross, Discovery, Weatherbug, Marriott, Freddie Mac, GEICO,

the US Department of Health and Human Services, and the US State Department

He lives outside Boston, Massachusetts with his wife, two dogs, and three cats

While not obsessively multitasking online in front of his computer he enjoys

mov-ies and hikes with his wife and dogs He periodically blogs about Web design and

development on his personal Web site, www.cherny.com

Rob holds a Bachelor of Arts in History degree from Towson State University in

Maryland

Meryl K Evans is a content maven and the author of Brilliant Outlook

Pocket-book She has written many articles and contributed to books covering Web

design, business, and writing Meryl has also written and edited for The Dallas

Morning News, Digital Web Magazine, MarketingProfs.com, PC Today, O’Reilly,

Pearson, Penguin, Sams, Wiley, and WROX You can contact the native Texan

through her Web site at www.meryl.net

Kevin Lawver has worked for AOL for over twelve years, building all manner

of web applications He is a passionate advocate for standards-based

develop-ment and is currently AOL’s representative to the W3C Advisory Council and a

member of the CSS Working Group He spends his time writing code, blogging,

preaching the gospel of web standards, and speaking at conferences about

stan-dards, mashups, best practices and Ruby on Rails You’ll find Kevin on the Web at

http://lawver.net

Mark Trammell has been chasing function and usability as a standard for Web

design since 1995 Mark has served as Web Standards Evangelist at PayPal and

directed the Web presence of the University of Florida In his tenure at UF, Mark

led a widely acclaimed standards-based rebuilding of www.ufl.edu To download

Mark’s interview with Jimmy Byrum, who is the Web developer at Yahoo!

respon-sible for the home page at yahoo.com, be sure to register this book online at

www.webstandardsbook.com

Introduction 

What Are Web Standards? 6

Basic Benefits of Web Standards 6

Web User Interfaces 7

User Interface Planning 8

Web Site Planning Today 9

A New Approach: UI Architecture Plans 11

Chapter : Coding the Front End  Where To Start 14

Document Structure: Markup Language Choices 15

HTML vs XHTML 15

DOCTYPE Switching and Browser Rendering Modes 21

To Validate or Not To Validate Markup 32

Content and Structure: Design to Execution 34

Chapter : Presenting Cascading Style Sheets  How Many CSS Files? 48

CSS File and Linking Strategies 49

Microformats for Conventions, Meaning, and Utility 55

Microformats and POSH 56

Too Much Class 59

Classic Classitis 60

Curing Classitis 61

CSS File Content Structure 65

Alternative Media CSS 67

Presentation Set Free 72

Chapter : Integrating the Behavior Layer  Modern Ajax Methods 76

Modern, Progressive, and Unobtrusive Scripting 78

JavaScript Requirements: File and Function Inventory 80

Bad Script, Bad 80

Unobtrusive Improvements 85

Pop-Up Windows 88

Dynamic Elements and innerHTML 91

JavaScript Behavior with CSS and Presentation 93

Large Sites and Support for Multiple OnLoads 96

Custom Scripts vs Frameworks 98

Example of jQuery Framework Code 100

Frameworks Make Ajax Easy 104

Frameworks in a Nutshell 106

Chapter : Developing Web Software Applications  Web Apps Stuck in the Past 110

Software Quality and Inventory Analysis 110

Guidelines, Rules, and Web Standards 112

Rules To Code By 113

Better Forms with Modern Markup 113

Server-Side Frameworks and Template Tools 117

Microsoft ASP.NET Framework 121

ASP.NET Data Output 124

ASP.NET HTML Controls, Web Controls, and More 130

Content Management 135

Baseline Content Management 135

Content Management and Clean Content 136

Content Management Output and Modules 136

Content Management Templates 137

WYSIWYG for Content Authors 141

Third Parties 143

How To Approach Web Apps 144

Chapter : The Circle of Standards  Organizational Inertia 148

Introducing the Circle 150

The Standards Manager 150

Standards Creation and Documentation 151

Training and Communication 154

The Quality Review Process 155

Setting the Wheel in Motion 157

Keeping Up Momentum 158

Conclusion 158

Part 2: Case Studies 161 Practice Doesn’t Make Perfect  Communication 164

Adaptation 164

Persistence 165

Trials and Tribulations 165

Chapter : EverythingTori.com 

Backstage 168

Digging into the World of Tori Amos 168

Putting the Design Process to Work 170

Building the Wireframes 170

Designing the Site 177

Behind the CSS Scenes 180

Launching the Site 190

Meet the Designer, Philip Fierlinger 191

End Song 195

Chapter : AOL.com  Setting Your Team Up for Success and Avoiding Failure 199

What Went Wrong 199

Designing for Performance 220

Estimating Performance Before You Write a Line of Code 221

Performance Concerns 224

Interview: David Artz 229

Repeatable Steps 231

System Design and Architecture 232

The Buddy System 232

Get the Stubs Out 233

Thinking About Workflow 234

Front-End Wizardry 235

Making Your Markup Sing with DOCTYPE 236

CSS Best Practices 239

Accessible CSS 242

Performance in the Real World 248

Conclusion 250

Afterword 253

Appendix A: Targeting Web Browsers 254

Appendix B: Accessibility 259

Appendix C: Web Site Performance Tips 261

Appendix D: CSS Selectors Reference 270

Index 273

Constructing

Standards-Based

Web Sites

Building Web sites has changed, and someone forgot to tell the architects Web browsers’ support for modern techniques has allowed a new degree of discipline and control in coding the front end of a Web site These new best practices are those dictated in what is commonly referred

to as “Web standards-based” design or development

A Web standards-based approach has countless benefits The larger or more complex a Web presence, the more critical Web standards become This is particularly true for an enterprise with many different properties, channels, or brand considerations Add to this the prospect of critical Web-based applications and content management, and it becomes a man- date to ensure a high level of quality at every tier of an online presence

To embrace standards is only the start Some planning must occur to create a standards strategy that will endure over time, be applied gracefully, and scale within an organization, team, or enterprise A solid foundation should be created

by getting back to the basics and building with deliberate choices instead of dental decisions

acci-This book will help a Web team reexamine why they are creating standards-based Web sites and how best to do it It will help evaluate what is in place now as well

as the impact of Web standards on a team or a Web site as a whole It will also assist with staying organized over time and in finding ways to improve stability and reduce risk in Web applications It will help create techniques that leverage the unique strengths of Web standards in a CMS (Content Management System) Finally, this book will finish by examining some process and staffing consider-ations of Web standards

What Are Web Standards?

Web standards is a term used to mean Web pages built using the open and patible recommendations from the World Wide Web Consortium (W3C) and other standards bodies as opposed to closed, proprietary, corporate feature sets These recommendations, combined with modern best practices, exploit the stan-dardized power of the modern Web browsers that dominate the market today,

com-as opposed to out-of-date browsers that were feature-rich but inconsistent and often incompatible Placing a graphic that reads “This site designed for Netscape Navigator” on the main page of a Web site should be a thing of the past

Web standards fail gracefully when encountered by out-of-date browsers The standards are also intended to provide greater benefit for accessibility and for other types of media These techniques are built with intentional side effects that can benefit users, the company, and the team responsible for creating the sites Whole books have been written on the subject

Basic Benefi ts of Web Standards

Sites built with Web standards have many benefits, right out of the box, virtually without robust technique or experience These include

❖ Style and script reuse and consistency

❖ Reduced bandwidth use and caching of style and script files

❖ Faster rendering of pages

❖ Cleaner, easier-to-maintain code

❖ Easier to make accessible for assistive technologies

❖ Easier to make search engine-optimized

❖ Increased compatibility between browser vendors

❖ Improved chances of document legibility for the next generation of browsers

❖ Increased readership for your site!

Web User Interfaces

In simple software terms, the front end of a Web site can be referred to as its user

interface (UI) layer The UI layer of a Web site includes all the artwork, text,

for-matting commands, interaction instructions, and controls sent from a Web server

over the Internet to be viewed by a user inside a Web browser A user may interact

or “interface” with the resulting Web page UI by clicking objects or typing, thus

providing input for a new request, which is then sent back over the Internet to the

Web server to start the cycle again (Figure in.)

Contrast this front end to server-side programming, which includes business logic

and direct interactions with databases or other data stores Oftentimes a

server-side program must render a UI layer By the same token, the UI layer can send

Figure in. The user

interface of a Web page

is composed of several layers of technologies

User Interface (UI) Layer

Web Server:

server-side scripts, databases, business logic

directives or input to a server-side program and may contain some business logic This demonstrates how pervasive a UI is and how it touches every aspect of Web sites, from the simplest static marketing page to intricate business logic.

When Web authors build a modern UI layer, they may include complex tions or share code between pages and server-side programs to be more efficient Therefore, a redesign, or modifications to the UI, can get complicated or far-reaching Or both

instruc-How can this code be managed in an effective manner, shared among large teams, and remain efficient from a productivity standpoint over time?

User Interface Planning

The 1990s dot-com boom introduced horrible UI practices that led to bloated, unstructured, risky, and inefficient construction of Web sites The structure of a simple Web page became an ugly mess referred to as “tag soup”—a virtual train wreck of nested HTML tables and single-pixel transparent spacer GIFs that had

to be designed before work could begin on the page’s content or an application

JavaScript was also a hack, with embedded event handling and code forks based

on proprietary browser techniques Finally, to control any of the output on your

Web site or application required intertwining your content, presentation, and

application logic all together in layers, which introduced business risk and

man-agement hassles

Web Site Planning Today

The vast majority of the effort and project planning on large-scale Web projects

today trivializes the UI layer and treats it as an afterthought, when in fact it can

deeply impact content management, Web applications, search engine

optimiza-tion (SEO), bandwidth costs, site performance, and maintenance efforts Plans

typically start with the back-end software and only touch on the UI in terms of

design

Fortunately, there are ways to pare down the long-term risks and remove the

constraints of traditional Web coding Embracing modern techniques starts with

the W3C and its recommendations, often called Web standards

The issue should be considered not only in terms of your design, but also where

the content management, applications, and other dynamic systems are

con-cerned If a Web site is to reap the benefits of a Web standards-based UI, it needs

to be considered at all levels, and plans should be introduced that will allow the

site to grow intelligently

The Keys to Web Standards

What, exactly, changes when you’re planning a site with a Web standards-based

approach?

First, on the UI layer, conforming to Web standards means 100% separation of

presentation from content and structure, as well as the scripting behavior of UI

elements Second, on the back end, this means limiting the mixing of UI code in

the Web applications and CMS code that may need periodic updates, and

apply-ing the same strict separation as to any other static screen

The distinct areas to concentrate on are

❖ Content and structure—the markup layer, usually made up of HTML

(Hyper-Text Markup Language) or XHTML (eXtensible Hyper(Hyper-Text Markup Language)

❖ The presentation layer—consisting of CSS (Cascading Style Sheets), which is

referenced from the markup and the sites scripts

❖ The behavior layer—the JavaScript elements that enable user events and

interactions

❖ The software and CMS layers—these have a UI of their own and often produce the above UI layers

❖ The teams and processes that help to build all of the above

It is not difficult to attain UI layer separation in a static setting devoid of software

or large teams The key is that the Web software needs to respect these tions as well, and the project plans need to consider the UI layer as a first-class citizen that needs to interact with all systems in an intelligent and thoughtful way, not as a second-class citizen that is simply an afterthought

distinc-Software Architecture Patterns

Layers of code serving different purposes are not a new concept for the software industry In fact, there are numerous examples of architectural design patterns that software students have been studying for years A good list with links to examples of architectural design patterns can be found on Wikipedia at http://en.wikipedia.org/wiki/Architectural_pattern_%28computer_science%29

An example of a popular pattern called “model-view-controller” is, in simple terms, something like the following:

❖ Model: Logical meanings of raw data used for various business purposes

Think of the model layer as an application program interface (API) for other parts of a program to connect with it This layer is responsible for the compu-tational footwork we rely on computers to do for us, like adding up the cost of items in a shopping cart or determining if today is our wedding anniversary

❖ View: This is the eye candy one sees when the model is rendered into a UI

layer or part of the UI layer Think of an HTML+CSS web page from a Web application as the view

❖ Controller: Frequently event driven, it interprets and responds to user actions

and may drive changes to the model Think of this as the layer responsible for handling user actions which include, but are not limited to, mouse clicks or Web-based form submissions

To extend this model to Web software and Web standards, some have labeled the UI layer separation of content, presentation, and behavior as a parallel to this pattern, using the model (content and structure), the view (presentation), and the controller (behavior) Experienced software architects are often quite eager to embrace a layered front end whether they are familiar with Web design or not

A New Approach: UI Architecture Plans

A traditional plan starts with back-end requirements and then builds on a UI layer

code as an afterthought Today, using a modern Web standards-based approach,

teams should ask themselves the following:

❖ Is the UI layer built and structured for easy maintenance?

❖ How does the UI layer impact SEO?

❖ How does the UI layer interact with the site’s content management

system (CMS)?

❖ Is it possible to redesign or make simple design changes without deep

CMS impact or the need for CMS staff?

❖ What happens when it comes time to modify or enhance the UI?

❖ How do you integrate a UI with a Web application?

❖ What happens when the application logic changes?

❖ How risky is a design change to an application?

❖ Should mission-critical applications buckle under the pressure of needlessly

risky design, simple content, or script changes?

A well-planned Web standards approach will mitigate these risks at two levels:

first, the front-end code; and second, where the back end meets the front end

Over time, for any site, these questions become big issues Larger enterprises often

have a Web presence in place, and mass change will not be possible or will be too

difficult to achieve overnight Incremental change may be required Where the

line is drawn will be different in almost every case

When planning for change, first figure out what needs to be designed, whether

it’s marketing content or an application, and how it needs to be rendered in the

browser Second, make reasoned decisions based on the pros and cons of each

option Finally, figure out how to get a site to its standards-compliance goals and

how to keep it that way

Coding the Front End

Advocates of Web standards tend to be passionate, but far from mous Disagreement is nothing new The concept of “Web standards-

unani-based” Web sites means different things to different people Web

standards is the subject of many an argument online, and, to some, almost

a religious crusade This is in part because there are many myths that round Web standards To those who think they know what Web standards are all about, it’s important to filter truth from all the noise.

sur-The most important aspects of Web standards-based Web sites are the separation of content and structure (HTML or XHTML) from presenta- tion (CSS) and behavior (JavaScript) These key characteristics are by far the most critical ones, and will help provide most of the advantages of standards-based code, in particular easier site maintenance.

One of the most intensely debated subjects within the realm of standards is the myth that all code must be validated Validation is seen as a critical aspect of Web standards-based development, with its noble purpose of ensuring compliance and compatibility, and providing help with debugging Although no one would ever suggest that the creation of invalid documents is a good thing, realities need

to mitigate this process, and be tempered with project priorities as necessary Both the advantages of easier maintenance and the realities of external factors that impact validation may occur (and therefore conflict) in any development environment

Separation can coexist with legacy content and applications that are migrating to

a more standards-based approach, often preventing pure validation

While this perhaps should be true in an idealistic sense, in reality Web standards need not be all or nothing Web teams can ease into standards and have them coexist with legacy content and applications It’s all really just about improving your code If legacy content exists or is full of markup that contains presentation attributes, it doesn’t mean that new code needs to be the same way Fix what can

be fixed and move forward in a methodical way Some environments may not be able to validate right away; that’s just fine, and is to be expected during any transi-tion Transitional specifications exist for those very reasons

Other myths or exaggerations are that Web standards-based development means not ever using tables and that design can be only “DIV-based.” This is a gross sim-plification Tables can be perfectly valid, and a bunch of DIVs in a document can likewise be perfectly invalid and just used wrongly Web standards-based markup means using elements and attributes for what they were intended to be used for: Tables are for tabular data, not for layout; headers are content headers; para-graphs are paragraphs; and presentation of all elements should be controlled with CSS The truth of standards is in using code as it was intended to be The project’s success depends on being realistic

There is no standards on-off switch for a Web team Technique is everything, and

that discussion starts now Looking deeper, there actually is a standards on-off

switch: It’s built into the Web browser To learn about that, keep reading

Where To Start

A Web standards strategy needs to start at the markup level, since that’s where the offense of mixing HTML markup with presentation details is usually com-mitted Allowing a team to evaluate existing code and look at Web standards for direction will shed light on what the ultimate standards strategy should be The

more complex a site, the more barriers to an absolute pure standards approach

may exist This may lead to compromises and a phased approach that moves to

standards over time Such compromises are not ideal but sometimes they are

unavoidable

Document Structure:

Markup Language Choices

Back in the day, building Web sites meant only one thing: using HTML Over

time, some who took notice might have included features from HTML 3.2, 4.0, or

even 4.01

Creative techniques were invented using HTML to design high-end sites involving

single-pixel GIFs and massive amounts of nested tables, which resulted in bloated

and inefficient front-end code These techniques worked but were difficult to

maintain, because the technology was being used for things it was never intended

to do Basic layouts and design treatments were effectively code hacks Today

these hacks have been worked into marketing Web sites, Web software

applica-tions, and content management alike Web browsers today can support a more

modern and disciplined approach that can help simplify all of these environments

through the adoption of Web standards-based code

A Web standards-based approach means creating markup that conforms to the

spec as closely as can be accomplished This typically means well-formed,

cor-rectly nested tags; accurate quoting of attributes; and properly structured code

At first, these parameters sometimes put off Web authors who are caught off

guard by them, but oftentimes they find that following the guidelines actually sets

them free

Choosing a markup language can be a tough decision, because there are multiple

options and some aspects are subjective at best, but in the end it is still technique

that matters

HTML vs XHTML

Today, the two basic choices are HTML 4.01 or XHTML 1.0 Both specifications

have gone a long way to improve the structure of Web markup and move

presen-tation information out of the markup and into separate files Both languages are

recommended by the W3C and fully acceptable for producing Web sites In fact,

the two languages are not that different, with the exception of some attributes,

deprecation of presentational elements, and XHTML’s adherence to XML syntax

HTML vs XHTML Syntax Differences

There are a number of differences between HTML and XHTML The bottom line is that XHTML uses a stronger, XML-like syntax, whereas HTML is more forgiving with optional elements Assum-ing the document is valid:

• XHTML is XML, as well as being XSLT and XML tool-compatible

• XHTML elements are lowercase

• XHTML attribute names are lowercase

• XHTML is case sensitive

• XHTML elements match CSS selectors on a case-sensitive basis

• XHTML attribute values are quoted, with single or double quotes

• XHTML elements are all closed, including single, empty (also known as “replaced”) tags with a trailing slash such as <br /> and <img />

• XHTML requires that all non-empty tags, such as <td>, <p>, <li>, have corresponding closing tags </td>, </p>, </li>

• XHTML block-level elements generally do not appear inside inline elements

• XHTML optional elements such as tbody are not represented in the DOM unless they are ally in the document

actu-• XHTML features XML’s “well-formedness,” meaning that tags are correctly nested in a tree ture where starting and ending tags do not overlap out of order

struc-• XHTML empty (single-tag or singleton) elements are closed with a trailing slash preceded by a space for compatibility reasons (e.g., <br />, <hr />, etc.)

• XHTML attributes may not use HTML attribute minimization; rather attributes must be fully specified and quoted like others (e.g., selected=”selected”)

• XHTML elements are returned and specified in DOM JavaScripts in their correct case, whereas in HTML they are always uppercase

• XHTML 1.0 and HTML 4.01 Strict deprecate a number of tags and attributes that are allowed in transitional varieties

• XHTML-embedded CSS and JavaScript blocks are considered #PCDATA, and their content may need to be wrapped in XML CDATA blocks; consider external scripts and style sheets

• XHTML can, under some circumstances, force JavaScript to behave much differently than in HTML (e.g., document.write sometimes will not work, etc.)

• XHTML name attributes are deprecated; use id attributes instead of, or in addition to, the name

attribute, depending on the need

For more information, please see the W3C: www.w3.org/TR/xhtml1/#diffs

XHTML 1.1 has been defined; however, by the specification it must conform

so closely to XML that the majority-share Web browser today has significant

trouble with it This is, of course, Microsoft Internet Explorer, which has

incom-plete support for XML That leaves HTML 4.01 and XHTML 1.0 as the most

realistic options

For years, many Web standards advocates insisted that XHTML was the next

logical step for the Web and that it should be used for all markup Some still feel

strongly that this is the case Exceptions among experts exist, and in fact many

of the creators of browser software today favor HTML and consider most of the

XHTML on the Web to be invalid due to its being served from Web servers in

an incorrect manner (see sidebar “Controversy and the History and Future of

XHTML”) Everyone has an opinion, and a developer should always weigh the pros

and cons against the goals of his or her particular project

Whatever option is subscribed to, HTML is here to stay, and it will be a very long

time before any Web browsers drop support for it In the end, though, what really

matters is how a developer codes her or his language of choice, and in particular

how it relates to presentation and behavior

Pros and Cons of HTML vs XHTML

Here are a few of the many opinions about HTML and XHTML, starting with some

pros of HTML:

❖ HTML has an established authoring base with a smaller learning curve than

other markup languages Most content authors understand the basics of

HTML syntax and need only learn the subtle nuances of using CSS as opposed

to presentational HTML They need to unlearn a few bad habits and stop

thinking that elements and tags look a certain way because this will be

con-trolled via CSS They will also need to learn to code the markup in a semantic

style, which will be explained further later

❖ HTML is easier to integrate with legacy systems’ markup This is a

compel-ling case in a large-scale enterprise environment that has lots of legacy code

Some software simply will not produce valid XHTML and in situations like this,

HTML may be the only way to go

Controversy and the History and Future of XHTML

The specification for XHTML states that since XHTML is XML it should be served over HTTP by Web servers as application/xhtml+xml Now, the major browser on the market, Microsoft Internet Explorer, does not support XHTML served as XML and will only accept it served as text/html, like traditional HTML For this reason many advocates of XHTML promote some-thing called “content negotiation,” which means serving the content with the types the browser says it accepts This is all fine, but others point out that there are XHTML/HTML compatibility guidelines in the XHTML specification that will allow XHTML to be served as HTML It is important to note that

in these cases the browser sees the XHTML content as nothing more than HTML with invalid attributes that are ignored, not as XHTML A search online for “XHTML considered harmful” will yield many results and much debate on the matter

In the meantime, HTML was left years ago without much of a future at the W3C, XHTML was defined and embraced by standards advocates every-where, and then XHTML 2 came along, breaking every imaginable rule of backwards compatibility It was practically ignored

In 2004, staff at several browser companies, including Apple, the Mozilla Foundation, and Opera, formed the WHATWG (Web Hypertext Application Technology Working Group) when it seemed that the W3C was no longer interested in a future for HTML The WHATWG began to define a specifica-tion called HTML 5 (and XHTML 5, not to confuse anyone) as well as exten-sions to the way forms and Web applications might work in the future The W3C did not really comment on the new working group for several years.Fast forward to 2006, when the W3C finally announced a new HTML work-ing group of its own to help address the future of HTML and XHTML The WHATWG has offered up its specification, which blurs the lines between HTML and XHTML considerably The specification has been accepted by the W3C as a starting point, and the debate has begun on the future of both HTML and XHTML Only time will tell

For more information on both working groups:

www.w3.org/html/wg/

www.whatwg.org

Anyone can participate in either of these groups

Some cons of HTML might be:

❖ Some consider HTML less robust and more prone to error due to its more

relaxed syntax requirements This can lead to bad practices and confusion

❖ Extraction, parsing, or manipulation of HTML content from existing

docu-ments or systems for other purposes is more difficult than with XHTML

because of the unpredictable nature of the markup

❖ Staying with HTML as opposed to XHTML might indirectly discourage some

content production authors from learning more strict standards and adopting

best practices

Some pros of XHTML are:

❖ XHTML is an XML-ready language It follows the rules of XML and is therefore

compatible with XML-compatible tools, such as XSL parsers or other software

used to syndicate, parse, or manipulate the content

❖ The rules that XHTML uses are often easier to learn and remember than those

of HTML; consistent XML rules are less prone to error than the flexible rules of

HTML, and XHTML has no optional closing tags or attributes

❖ XHTML syntax is close to the XHTML-MP (Mobile Profile) and XHTML Basic

used by many mobile or handheld devices

❖ Most authoring tools today support creation of valid XHTML

And finally, some cons of XHTML might be:

❖ While some portions of the syntax are easier, other aspects, such as character

encoding and entities, are more difficult to grasp

❖ Some find the controversy over mime-types not worth the trouble or too

difficult to deal with (see sidebar “Controversy and the History and Future of

XHTML”)

❖ Strict HTTP serving of XHTML as XML introduces issues that will catch some

authors off guard, such as JavaScript document.write statements not

work-ing, different interpretations of CSS, link target attributes being obsolete, and

IFRAME not being supported.

❖ XHTML may not be an option for legacy content stores in CMS tools or content

being served by third parties such as advertising servers (banner ads and so

forth) However, an author may opt for transitional code in some of these cases

❖ XHTML 2.0 has called into question the “future proofing” of XHTML as a

language This specification is hotly debated and may be radically reworked

or even abandoned (see sidebar “Controversy and the History and Future of

XHTML”)

Transitional vs Strict Flavors

Both HTML and XHTML have two “flavors” called Transitional and Strict, with significant differences in syntax The language and version flavor is specified at the start of the document by a Document Type Definition (DTD) that identifies which language the document is written in

Transitional language versions:

❖ Include more presentation attributes and elements than the Strict, because the intention is that in a strict mode the presentation information is fully pushed out to the CSS files

❖ Are considered to be a transitional bridge specification intended to move from the lax rules to the more specific ones in the strict variation

❖ May be used when there is legacy code that can’t be made fully Strict

A common issue in an organization is that content is marked up with atrocious code in a CMS because it has been around for years The important thing to note is that just because the legacy content stored in a CMS is a wreck, it doesn’t mean new code needs to be This should apply even with a transitional DTD: Just because the presentational attributes and elements are valid, it does not mean developers should use these presentational attributes and elements Any new code should use CSS This begins a migration path where any new code is using the strict rules

The following table outlines attributes and elements that are invalid in strict documents

Table . Strict vs Transitional Attributes and Elements

Strict Elements Deprecated Strict Attributes Deprecated

Strict Elements Deprecated Strict Attributes Deprecated

Picking the language is the difficult part of the decision, but it’s important to

make a reasoned comparison of strict or transitional against the nature of the

destination environment

NOTE

Some organizations will invest effort or time in using or writing software to

parse legacy content in HTML to convert it over to XHTML With careful

execution, these techniques can also strip <font> tags and other presentational

elements This can be done typically through generous usage of regular

expres-sions or other string-parsing algorithms Results may vary with this approach,

however, and great care should be used

DOCTYPE Switching and Browser

Rendering Modes

Something that often comes as a surprise to Web authors switching to Web

stan-dards is that modern Web browsers have different rendering modes This means

that based on the DTD, or Document Type Definition, the browser calculates and

interprets Web pages differently

DOCTYPE Presence

DOCTYPE presence, commonly called the “DOCTYPE switch” or “DOCTYPE sniffing,” is the ability to assess and change the browser mode In order to snap a browser out of its old methods of rendering Web documents and into standards-compliant rendering mode, the placement of valid DOCTYPE within a Web docu-ment becomes exceptionally important

Starting back in 2000 with Internet Explorer 5 for the Macintosh, the rendering engines of most browsers toggle between what is commonly referred to as “quirks mode” and “standards mode.” Netscape, Mozilla, Safari, Konqueror, Opera, and Internet Explorer (for the PC above version 6.0) all have this feature built into their rendering engines

Any of the following will cause standards-compliant rendering in most browsers today:

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01//EN”

for-Standards mode, on the other hand, introduces more rigid understandings of the specifications Based on further research of the standards, browser manufacturers have attempted to get closer to the strict exactitude of the specifications This has had the effect of changing what Web authors had come to expect in many cases

The typical practice in a Web standards-based approach is to strive to keep the browser in standards mode at all times for more consistent behavior across browsers and across platforms

Determining the Browser Rendering Mode

Web authors can be sure they are in standards mode by using the DOCTYPEs with URIs, as specified above However, sometimes layout issues may arise because an HTML element or comment is inserted prior to the DTD or due to other unpredictable scenarios—which may trigger quirks mode There are several

ways to tell which rendering mode the browser is using One easy way is to open

the page in Mozilla Firefox, right-click (or Control-click on Mac) and select “View

Page Info.” The resulting dialog displays a number of pieces of useful information,

including the browser’s current render mode (Figure .)

There are subtle differences in DOCTYPE switching methods that force some

browsers into quirks mode while others are still in standards mode At the code

level for most browsers, including IE, JavaScript can also be used to display the

rendering mode of the browser Try out the following code:

function testRenderMode(){

alert(document.compatMode);

}

window.onload = testRenderMode;

The possible values resulting from this code include “BackCompat” for quirks

mode and “CSS1Compat” for standards mode

Oops, the Wrong Rendering Mode Broke the Page

It is not unusual to have a site or a series of templates built in a carefully crafted

Web standards-based structure, and then something just goes wrong,

push-ing the browser into the wrong renderpush-ing mode The result is an entire page or

Figure . In Mozilla

Firefox, the Page Info dialog shows the render mode for the currently visible page

series of pages with widespread layout and alignment issues that were not there a moment ago.

This can leave a whole team scratching their heads wondering what is going on Usually something has happened in terms of the design being incorporated with some software backend or a CMS tool, or someone just inserted an HTML com-ment before the DTD without realizing it

Take, for example, the popular CSS gallery site CSS Beauty, designed, built, and

maintained by designer Alex Giron (Figure .).

Figure . Alex Giron’s

<meta http-equiv=”Content-Type” content=”text/html;

charset=utf-8” />

For the sake of argument, assume for a moment that a mistake is made, and the

DOCTYPE declaration is removed from the site in its development environment

(this would never happen in production, unless he was editing live, which should

always be avoided) This would leave the document starting out raw with the

HTML element rather than the DOCTYPE

Alex would see something that was close to his normally appearing site for the

most part; however, a number of rendering issues would spring up (Figure .)

The result is an oddly mixed-up layout with changes all over the place, as opposed

to in one small area How the introduction of quirks mode will affect page

render-ing will vary from site to site Similarly, switchrender-ing to standards mode from quirks

can also yield unpredictable results

Figure . cssbeauty.

com breaks if the DTD

is removed and the browser enters quirks mode

Adding back the DOCTYPE declaration is a simple thing in this case, but the lesson to be learned is that when widespread layout issues start happening, these problems are often symptomatic of a document-wide issue, such as the render-ing mode, styles not being linked correctly, or missing tags in a sensitive location Quirks mode in particular can wreak havoc on a well-structured page Using a val-idation tool to check the syntax of the page can be a huge help in cases like this.

There are specific documented issues, some of which will be discussed below, that exist for quirks and standards rendering modes These often surface when code

is being mixed with legacy markup, when browsers are reviewed, or when new designs are being produced This is particularly an issue when looking at Internet Explorer 5.0 and 5.5 because although they do not feature multiple rendering modes, they are essentially always in “quirks” mode This means designs will dis-play differently than even in IE 6.0 as compared to 5.5 when working in a “stan-dards” mode document because they are interpreted differently

Figure . In quirks

mode, the information

footer on the home

page of cssbeauty.com

is broken

For starters, there are extra background graphics behind the headers at the top of the page Additionally, the layout seems to have shifted up the page slightly and the “Recommended” column is way off in the middle left compared to its usual symmetrical alignment Scrolling down the page, things get even worse The entire information bar at the bottom of the page has lost its background color, except

on hover, and the font sizes are off (Figure .).

Legacy Markup and DOCTYPE Switching

In the 1990s Web authors often ignored the DOCTYPE declaration, since at that

time it was largely meaningless to Web browsers and was used simply for

validat-ing the document Yet only a select few were dovalidat-ing this because the languages

were being used in odd ways, and much energy was being expended on catering

to the proprietary features of browsers Most Web authors either misunderstood

or ignored the DOCTYPE, which in today’s world is in fact one of the most critical

parts of the document So now, many of those authors spend their time dealing

with migrating from legacy markup to semantic markup

Several common scenarios may come up while migrating to Web standards in

environments where legacy content and valid markup are mixed:

❖ Web standards means switching a Web site’s UI templates from an often

com-plicated HTML TABLE structure to a layout using clean tagged elements

with-out presentation attributes and CSS for positioning However, some authors

might insert a new, valid DTD at the top of an existing page whose design uses

sliced images and a TABLE structure, only to discover that their layout shatters

❖ New CMS templates might be introduced using modern layout code for the

page wrapper containing the branding, main, and global navigation Then,

when this is applied to content areas coming out of the CMS, that content can

break

❖ Web application developers might be using a new CSS-based design template

with a strict DTD for their application pages, and find that integration of these

pages with the new design template might break existing HTML

The Boxes Were Measured All Wrong

When IE 4 came out in 1997, and when IE 5 for the Macintosh came out in 2000,

Microsoft seemed to be doing fairly well with its Web browsers Not that they

were great, but in terms of CSS support and user adoption, they were simply

doing much better than Netscape 4 had fared Netscape 6 was poorly received,

and Microsoft had essentially won the so-called “Browser War.” With

Inter-net Explorer 5 and 5.5 (the only games in town for many Web authors), it was

assumed by most developers that the CSS support that they were getting used to

was in fact correct But just because something’s better or more popular doesn’t

mean it’s correct

Building a CSS-based layout using the building blocks contained in IE 4 and IE

5.x was misleading A layout on a Web page is described with elements and tags

representing a series of boxes and objects on a canvas—the document body A

CSS layout is defined by a box composed of an element that has a content area;

padding around the top, right, bottom, and left; borders around the same areas; followed by margins around the object as well

The width of an object is technically defined by the content area alone; however, these older versions of IE defined the width incorrectly, so any CSS object set with

a width is actually measured incorrectly This can wreak serious havoc on layouts, since the measurements for the dimensions of objects on pages are all wrong

IE 6.0 in “standards” mode fixed this However, it is now different from Internet Explorer 4 and 5, so Web authors have to deal with more than one measurement

model while laying out pages using CSS (Figure .).

the size of its content

plus its border and

padding The CSS layout

box model, on the

other hand, measures

the box and padding

separately from the

content

CSS Layout Box Model

CSS Width is Content Only

Content Padding Border Margin

Web authors new to building Web standards-based layouts, but who may have built pages using Internet Explorer 5.x’s CSS box model, are in for a surprise when other browsers render the pages differently Oftentimes, the belief is that other browsers were getting it wrong, or something broke in IE 6.0 The truth is, some-thing was fixed, and the other guys had it right

Unfortunately for the industry as a whole, the majority browser is Internet

Explorer, and so everyone suffers from different measurements, leading many to

believe that CSS support is hopelessly broken There are ways to cope with these

differences, from sending different style sheets to IE 4 and 5 to creating special

selector “hacks” to be read only by specified browsers

TIP

There are many, many references for quirks and standards modes in browsers,

but this is a good one:

www.cs.tut.fi/~jkorpela/quirks-mode.html

A Web search for “CSS box model hack” will yield many techniques for

provid-ing different measurements to different browsers

A preferred method today for serving different styles to IE is using Conditional

Comments, described in the next chapter

MSDN published an excellent document on the CSS changes in Internet

Explorer 6.0, which were significant and introduced the correct box model:

http://msdn2.microsoft.com/en-us/library/bb250395.aspx

The Table Gap

Another major area where the change to standards-based layout can cause

significant confusion is where TABLEs are being used for layout—they

no longer behave in the old, expected manner CSS guru Eric Meyer has

explained some TABLE and image layout scenarios in an article online called

“Images, Tables, and Mysterious Gaps” (http://developer.mozilla.org/en/docs/

Images,_Tables,_and_Mysterious_Gaps)

In particular, he describes the trouble that can happen when a Web author takes

a site that originally used tables for layouts and converts it to strict mode with

XHTML or HTML This usually results in some of the tables and images having

gaps where they used to be flush against one another

The reason is that the correct default bottom alignment for images is on the

base-line of the text, leaving room beneath for the descenders (such as the letter “y”)

that hang below the line of text When it was common to build Web sites with

images sliced up and set flush in tables against one another, Web browsers were

actually interpreting the specification and images behavior incorrectly by leaving

out this space By default, images are inline elements intended to align with text

Here is an example of a table with two rows, with a 50px by 50px black graphic set in a table with the cells set to be flush using a 50px height and all the spacing removed, much like graphics were frequently set back in the day:

td { font-size: 200%; height: 50px; } >

<td>The quick brown fox jumped over the lazy </td>

<td><img src=”quirks-block.gif” width=”50” height=”50” alt=””> </td>

</tr>

<tr>

<td>The quick brown fox jumped over the lazy </td>

<td><img src=”quirks-block.gif” width=”50” height=”50” alt=””> </td>

</tr>

</table>

</body>

</html>

The document above renders in quirks mode because it lacks a DOCTYPE

decla-ration, and has the graphics flush against one another, row to row (Figure .).

Figure . A common

technique in the 1990s was to use tables to place graphic elements flush against each other

Taking that very same document without any modifications and slapping a strict

DOCTYPE declaration on the top of the file switches the document to be

ren-dered in standards mode in today’s browsers:

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01//EN” “http://www.w3.org/

TR/html4/strict.dtd”>

<html>

<head><title>

Opening up the file in a standards-compliant browser yields some surprising

results that include extra gaps appearing under the graphics in each row, blowing

out the carefully crafted and beautiful black square boxes (Figure .).

The quick and dirty lesson here is that a few simple rules in the CSS can address

these problems:

td img { vertical-align: bottom; }

Or even:

td img { display: block; }

Which solution is appropriate depends on the circumstances, and sometimes

it’s easiest to simply use both In the end, however, these treatments are quite a

common scenario in a standards migration, which is exceptionally tricky to debug

unless the developer is intimately familiar with box model and alignment

charac-teristics from the specifications Fortunately for everyone, experts like Eric Meyer

are around With the small corrections applied by Meyer’s technique, the table

and graphics’ layout and rendering is fixed (Figure .).

Figure . A browser

in standards mode can create gaps between artwork in table cells

Figure . Table

artwork gaps are easily fixed with a little CSS