This book is meant to translate into plain English the quirks of HTML, CSS, and the document tree that are hard to grasp without guidance or experience:
Choosing and using the ideal version of HTML for your project
Removing the obstacles between your current practice and consistently valid markup
Using HTML to implement for structure, rather than presentation, in ways that get the best out of CSS
Obscure-yet-useful HTML elements
Using tables properly, and getting the most out of them
The method behind the madness of CSS selectors, particularly descendant selectors
CSS selector precedence
The CSS block layout context
CSS margin collapsing
Bugs and other oddities imposed by Internet Explorer 6
Wrangling form presentation
The history behind the bugginess of web browsers
What HTTP does when your back is turned (and why it’s important)
This book tries to cover what all presentation layer developers should know. It aims to describe the many relationships between layers of the web technology stack that are touched by designers and presentation layer developers, and also to present the strengths of HTML and CSS.
This book will also introduce the less experienced reader to a long list of CSS layout “tricks” essential to the demands of presentation, accessibility, and Search Engine Optimization (SEO). These include:
Using enhanced Fahrner Image Replacement to implement bitmapped heading type
Creating well-aligned columns of equal (or apparently equal) height
Using the CSS
to get the best of both column presentation and markup source
Building versatile, visually rich navigation interfaces
Developing work habits that will make your sites Ajax-ready
Getting the most out of the CSS
Creating versatile grid systems for your sites
A full reading of this book should imbue the reader with the majority of the knowledge needed to transform nearly any consistent set of composites—no matter how far-out their apparent requirements—into the presentation and content layers of an accessible, usable, and “crawl”-able website.
This book focuses tightly on practices that maximize the effectiveness of markup and stylesheets. For that reason, a number of things are not included in this book:
You can do a lot of fun stuff with CSS…but unfortunately,
some of it relies on unevenly supported CSS selectors and
properties. Such cases will be handled in terms of
desired results: if an ActiveX filter
supported in Internet Explorer has an analog in Firefox, it might
be mentioned, or vice versa for
-moz-* properties that have analogs in
the IE runtime environment. The minimum
requirement for discussion of implementation techniques in this
book is reliable support in both Firefox 3 and Internet Explorer
8, and broader platform support for techniques that render obscure
This book will cover production techniques well suited to the creation of highly accessible sites, but it is only intended as an introduction to implementing sites that are accessible to impaired visitors.
The goal of this book is to help you burnish your skills in good faith so that the results on your résumé are pleasing not only to Human Resources evaluators, but to hiring managers as well. Therefore, reading this book should help you to better understand any CSS framework that you might be called upon to use, instead of instructing you on the use of any framework in particular.
Typical web server runtime configurations neglect a number of settings that can ease the achievement of usability, accessibility, and standards compliance objectives. However, these oversights fall more into the domain of system administrators. A number of other O’Reilly titles, particularly Webmaster in a Nutshell and Website Optimization, address this area of interest. A number of online communities and blogs also explore this topic from time to time.
This book has the misfortune of being written by a lifetime resident of the U.S., where the feature set and reliability of mobile web access has plenty of room for improvement. The iPhone’s popularity has improved the situation, but still has not made it entirely tolerable. As it stands, only a minority of the mobile device users in the U.S. can hold any realistic expectation of using the same Web as personal computer users. Meanwhile, the expense of prepaid device connectivity found in the U.S., and the wildly uneven availability of unencumbered emulators for mobile device platforms, further exacerbates the problems faced when developing mobile content for U.S. visitors. It is my hope that the next edition of this book will be able to include development techniques intended to benefit site visitors who use mobile devices.
If there is one omission from this book over which I agonize, it’s the omission of the Opera desktop browser from all discussions of browser behavior. Unfortunately, when I weighed Opera’s market share against the amount of testing its inclusion in the book would require, the results of the comparison were superlatively discouraging. Since I owe Chris Mills of Opera direct thanks for his role in helping me to secure the contract for this book, rest assured that I did not make my decision lightly. Given any more than the barest amount of reader interest, I won’t hesitate to discuss the Opera desktop browser at length on this book’s companion website.
Last but not least, there is the question of compliance with World Wide Web Consortium (W3C) Recommendations in commercial settings, particularly those environments that are nurtured in large enterprises.
I’ve always made it a point to distinguish between “standards friendliness” and “standards compliance.” The first obeys the spirit of so-called web standards and is easy to achieve with practice, while the second focuses on obeying the letter of the Recommendations and can prove impossible to achieve.
The effectiveness of a website is enhanced far more by standards friendliness than by standards compliance, with the greatest enhancements coming from adherence to both objectives. This book embraces the compromises and fallbacks that preserve standards friendliness in spite of adverse development conditions, with only the occasional twisted grimace.
You may have noticed that I referred to “so-called” web standards earlier. The underlying irony is that web standards…aren’t, at least not literally.
Standardization requires conscientious use of a formally defined system across an entire industry, typically (if not always) by standards bodies whose work contributes directly or indirectly to policies and publications of the International Organization for Standardization (ISO).
Another hallmark of true standards is an objective set of criteria and processes by which claims of compliance can be enforced—an asset that the W3C’s products very much lack.
For these reasons the popular definition of W3C Recommendations as standards is reasonable in spirit, but has no basis in literal fact.
That said, the practice of web standards development has evolved tremendously since the go-go era of the 1990s, a point that’s explored in greater detail on this book’s companion website.
Chapters 9 and 11 discuss image production techniques in some detail, and the procedures described there are based on the Adobe Photoshop user interface. I took this approach because in any moderately sized group of web professionals, you’ll find a wide diversity of preferred tools and implementation techniques…until you get to the question of working with graphics. Alternatives to Photoshop (particularly Fireworks, another Adobe product) claim their devotees, but even those operators will agree that a working knowledge of Photoshop’s toolset and user interface is immensely useful.
My choice was also based on slanted experience; I haven’t used anything other than Photoshop to manipulate web images since I was a full-on novice. My hope is that visitors to this book’s companion site will submit their own alternative-title cookbooks for the image manipulation techniques discussed in the book.
The matter of relying on Photoshop also illuminates the importance of tool choice with respect to team effectiveness. Chapter 4 introduces the value of production standards and code libraries, but the benefits of tool uniformity also extend to off-the-shelf software choices.
The companion website to this book, http://www.htmlcssgoodparts.net, contains a wealth of information. Among the goodies you’ll find are:
Errata and corrections
Blog entries about reader questions, current technical developments, and best practices
Staged demonstrations of techniques discussed in the book, complete with source markup and stylesheet rules and indexed to page numbers
Boilerplate and/or templates for multicolumn layouts and other widgets
HTML and CSS reference tables that link to multiple third-party documentation sources
Visitor-submitted reviews of books and software of interest to this book’s audience
Names for the various pieces of web technology sometimes vary from shop to shop and from place to place. To minimize the potential for confusion, the terms spelled out below in emphasis are used consistently throughout the book.
Files are discrete nodes on a server host’s native filesystem, while resources are documents or document fragments referenced by discrete Uniform Resource Identifier (URIs). Not all files are URIs, and not all URIs are files; a URI might contain several files, database query results, or data streams, while a file might amount to nothing more than the logic that determines the content of multiple URIs.
Pages or documents contain one or more resources of arbitrary classification and are the visitor-facing output of a request for a single URI (or perhaps multiple URIs, on sites where Ajax has been deployed). Finally, this book treats the differences between the terms “URI” and “URL” as minor to the point of insignificance, in part because the term “resource” itself has been so muddled it’s become functionally meaningless in the face of rapid evolution.
Stylesheets are the content of CSS files or
style elements. Stylesheet
rules assign presentation to one or several elements within a
page. A stylesheet rule contains a selector, which defines the
element(s) on the page to which one or more property/value pairs are to be
The Document Object Model (or DOM) is both the representation of a web document’s structure, and the definition of how that structure ought to be organized, queried, and altered programmatically. Several DOM specifications for web documents exist, though only one is developed and sanctioned by the World Wide Web Consortium as a body.
Copy and illustrations are to content what text and images are to data.
A doctype declaration can (and usually should) appear at the beginning of a given web document and identifies the version of HTML against which that document should validate. The document type definition (also called a DTD) is a machine-readable series of statements that defines validity for the applicable version of HTML. The values contained in a doctype declaration directly reference a specific DTD.
Project managers minimize the obstacles standing between a project team and the completion of their deliverables. Designers create the look, feel, and user experience of sites. Engineers and application developers design and write the code that makes sites go. Presentation layer developers as a group deliver everything that directly faces site visitors; of these, stylists create templates and stylesheets, and producers ensure that content gets placed into production. Most other roles commonly found in web project teams are titled here as they would be in an advertising/marketing environment.
Current browsers or user agents refer to the mass-market browser versions current when this book went to press: Internet Explorer 6–8, Firefox 3.x, and Safari 3.x–4.x.
Several of the terms listed here point to obscure processes with an impact on the web user experience; these processes will be discussed in more detail throughout this book.
When I first started working with the web platform in 1995, “Read the Source, Luke!” was easily the most popular advice given to the greenest newbies on mailing lists. This hearkens back to the climactic moments of Star Wars: A New Hope, and exhorts the petitioner to read through the source markup (and now, 13 years later, the stylesheet rules) of results they find admirable.
There’s more to this advice than sci-fi nerd humor. The best understanding of effective passages of markup and styles comes from reading through them without filters—in much the same way that “Force-sensitives” of the Star Wars milieu get the most out of their talents by letting go of their prejudicial thoughts.
If you try to puzzle out how somebody accomplished a presentation goal before you read his source, you might be badly disappointed…and if you never read his source, you might never figure it out for yourself.
However, before we can get into the finer points of learning from source markup and CSS, it’s best to look at the Web as a system—the relationships between the underlying conventions and technologies that make it go.