You are previewing HTML & CSS: The Good Parts.

HTML & CSS: The Good Parts

Cover of HTML & CSS: The Good Parts by Ben Henick Published by O'Reilly Media, Inc.
  1. HTML & CSS: The Good Parts
    1. SPECIAL OFFER: Upgrade this ebook with O’Reilly
    2. Preface
      1. The Who and What of This Book
      2. Objectives of This Book
      3. Conventions Used in This Book
      4. Using Code Examples
      5. Safari® Books Online
      6. How to Contact O’Reilly
      7. Acknowledgments
    3. 1. Hypertext at the Core
      1. The Web Without Links
      2. URIs
    4. 2. Working with HTML Markup
      1. HTML Syntax
      2. Rendering Modes, Flavors of HTML, and Document Type Declarations
      3. Beautiful Parts: Universal Attributes
      4. Separating Content, Structure, Presentation, and Behavior
      5. Browsers, Parsing, and Rendering
    5. 3. CSS Overview
      1. Connecting Stylesheets to HTML Documents
      2. Choosing the Elements You Want to Style: Writing Selectors
      3. Rule Conflicts, Priority, and Precedence
      4. CSS Property and Value Survey
      5. CSS Units
      6. Key CSS Layout Properties
    6. 4. Developing a Healthy Relationship with Standards
      1. The Broad Landscape of Web-Related Standards
      2. Why Web Standards?
      3. Taking the Middle Road: Standards-Friendliness
    7. 5. Effective Style and Structure
      1. The Four Habits of Effective Stylists
      2. CSS Zen and the Stylist’s Experience
      3. Information Architecture and Web Usability
    8. 6. Solving the Puzzle of CSS Layout
      1. The CSS Box Model and Element Size Control
      2. Quirks Mode and Strict Mode
      3. auto Values
      4. Margins, Borders, and Padding
      5. Element Flow
      6. Using the display Property to Change an Element’s Flow
      7. The float and clear Properties
      8. Implementing Multicolumn Layouts
      9. CSS Positioning Properties
      10. The visibility and z-index Properties
      11. Obtaining Precise Navigation Source Order and Layout
      12. Layout Types and Canvas Grids
    9. 7. Working with Lists
      1. Ordered and Unordered Lists
      2. Other Uses for Lists
      3. Styling Navigation Elements
      4. Definition Lists
    10. 8. Headings, Hyperlinks, Inline Elements, and Quotations
      1. Headings and Good Writing
      2. Styling Heading Elements
      3. Link Markup
      4. Styling Links
      5. Adding Semantic Value with Inline Elements
      6. Quotations
    11. 9. Colors and Backgrounds
      1. Color Theory and Web Color Practice
      2. CSS Backgrounds
      3. Composing Background Images
      4. Bitmapped Copy and Fahrner Image Replacement
      5. Reducing Server Load with Sprites
    12. 10. (Data) Tables
      1. The Disadvantages of Layout Tables
      2. The Parts of a Data Table
      3. Composing Cells
      4. Table Headers, Footers, and Heading Cells
    13. 11. Images and Multimedia
      1. Replaced Elements
      2. Preparing Images for Production
      3. Image Production
      4. Working with Color Profiles
      5. Image Optimization
      6. Publishing Images
      7. Styling Images and Plug-in Content
      8. Adding Motion and Sound: Using SWFObject to Insert Flash Videos and Presentations
      9. Inserting Unwrapped Multimedia
    14. 12. Web Typography
      1. A Brief History of Letterforms
      2. A Visual Glossary of Typography
      3. Aliasing and Anti-Aliasing
      4. Type Styles, Readability, and Legibility
      5. Sizing Type
      6. Working with Typefaces and Fonts
      7. Character Encoding in Brief
      8. Creating Balanced Type Treatments
      9. Typographical Miscellany in CSS
      10. The Practice of Good Web Typography
    15. 13. Clean and Accessible Forms
      1. Building Effective Forms
      2. Assessment and Structure
      3. Basic Form Structure, Presentation, and Behavior
      4. Prototyping and Layout
      5. Required Fields and Other Submission Constraints
      6. Creating Accessible Forms
      7. Form Features in HTML5
    16. 14. The Bad Parts
      1. The Numbing Nature of Internet Explorer (Especially IE 6)
      2. Systemic Ugliness
      3. HTML’s Bad Neighborhoods and Cul-de-Sacs
      4. CSS Travesties
      5. The Awful Parts
      6. Picking Up the Pieces
    17. A. URIs, Client-Server Architecture, and HTTP
      1. The Underlying Client-Server Architecture
      2. What Every Web Developer Should Know About HTTP
      3. MIME Types, in Brief
      4. Controlling Request Volume
    18. Glossary
    19. Index
    20. About the Author
    21. Colophon
    22. SPECIAL OFFER: Upgrade this ebook with O’Reilly
O'Reilly logo

Why Web Standards?

Since the publication of the first IETF draft specification for HTML, browser vendors and site developers have made a frequent bad habit of disregarding published web standards. At the same time, the community of developers who make a point of respecting those standards (of which this author considers himself a devoted if usually quiet member) has never been anything but vocal and predictable, if not actually disciplined. There are a number of issues at work behind the scenes of the ongoing debate.


This section addresses web standards as they are typically promoted.


Untested assumptions about visitors are a big mistake. Common adherence to standards would reduce the number of assumptions. Developers could build their sites and deploy them with a minimum of platform testing. And who doesn’t want that?

Market Forces

The virtues of interoperability do not, however, harmonize easily with the hot desire for bells, whistles, and pretty things often felt by artists and marketers. Browser vendors cannot ignore the imperative to innovate, and the market usually works on a shorter life cycle than the standards acceptance process.

Market forces are what drove the prospect of common standards compliance off the rails in the first place. In early 1995, table support was introduced in Netscape 1.1, while codification of earlier enhancements brought to market by Mosaic 2.0 was still awaiting acceptance. In effect, Netscape—then still deserving of the “startup” label and two years from its groundbreaking entry into the equity markets—was capable of running circles around the standards adoption process, and the market responded. The resulting conditions nurtured a diffident attitude toward web standards that persists more than a decade later.

Forward Compatibility

It is often argued that standards compliance ensures the longevity of sites that respect it; while features are often added to user agent platforms, they are rarely removed or disabled (the blink element being a notable but absurd exception). Older standards, meanwhile, tend to lie within the lowest common denominator of features supported by all user agents. The upshot of these two facts is that standards compliance allows sites to better survive across browser versions.


Standards compliance tends to make materials more accessible to impaired users, many of whom rely on various forms of third-party assistive technology to ensure a meaningful experience. The standards are a useful guide in this respect for a number of reasons:

  • While not enforced by an impartial body, W3C Recommendations are authoritative and as such are incorporated into requirements of statute law relating to accessibility, especially in the United States.

  • The published Recommendations provide vendors of assistive technology with baseline expectations for their customers’ browsing environments, even when that baseline follows lowest common denominators.

  • From the beginning, one of the principal design goals of HTML has been cross-media compatibility, which makes it easier to create technology.

Vendor Priorities

After the release of Internet Explorer 6 in 2001, Microsoft’s attention to the web user experience entered an era of somnolence that has only just definitively ended with the release of Internet Explorer 8, a substantial upgrade.

IE6 was released at a time when market shares of competing user agent platforms were on the wane, and the public understanding is that Microsoft made a strategic decision to rest on its laurels until developer community outcry—driven by an official United States Government recommendation to stop using Internet Explorer altogether, among other factors—encouraged it to resume significant ongoing development of Internet Explorer.

A similar incident illuminates Netscape 4’s poor support for CSS. When CSS 1.0 was in development, Netscape and Microsoft offered competing proposals to the W3C, and Netscape’s proposal was rejected outright. It’s apocryphally understood that because Netscape 4 was about to pass its RTM (release to manufacturing) milestone, frantic last-minute engineering of Netscape 4’s rendering engine was required in order to provide any support whatsoever for the W3C-mandated CSS—a necessarily slapdash effort that had long-term consequences for the quality of the browser, to say nothing of Netscape’s viability.

Legacy Asset Inertia

During the era of the Web’s fastest growth, standards were barely on the proverbial radar, and the cost of putting sites into production was high because the tools available at the time were quite primitive.

As a result of those adverse conditions, tremendous investments were made in poorly built web properties and the software that made them go. These properties continue to be nurtured because the cost of replacing them—measured in terms of institutional politics and capital investment—is seen as too high.

This phenomenon most strongly affects typical web developers in the area of third-party content and solutions, particularly news publishing and advertising platforms.

Best Practices (and Lack Thereof)

Web shops and solo web developers can be found under a wide variety of institutional umbrellas: solo freelancers, specialist boutiques, large advertising agencies, mass media outlets, online businesses, medium-size businesses, information technology and information services departments of every imaginable size, and departments that have one or two developers fully responsible for the breadth of that unit’s web presence. In addition, there are legions of do-it-yourself-ers, who can be undercapitalized, bloody-minded, or both. Websites are built by all kinds of people, and everyone has different notions of what makes a website good or bad. That difference in judgment of quality and choice of tools, which in large enterprises is compounded by interdepartmental confusion and infighting, results in widely varying ideas of best practices.

An individual’s most valuable web development qualification is neither her level of skill nor her degree of talent, but instead her ability to interact agreeably with teammates and others in order to be effective at her job, a quality frequently called “team fit.” That dynamic is made still more complex by the fact that there is a high incidence of introvert personality traits amongst the population of professional web developers. Finally, the reluctance of many employers to take responsibility for their employees’ ongoing skill development puts considerable drag on the momentum of median skills growth—sometimes to the point of eliminating that momentum completely.

As you can imagine, such an environment can result in wildly differing opinions regarding good and bad.

Strict Constructionism

The most passionate dispute that many developers have with the prospect of standards compliance is that it’s an all-or-nothing affair. The most visible requirement of standards compliance is valid markup, which is too often impossible to publish because of the many challenges explained earlier.

In addition to meeting the extreme challenge of genuine standards compliance, well-intentioned development teams must tolerate the rather shrill and morally superior attitude of many self-styled standards advocates, and the result is a large cadre of professionals who couldn’t possibly care less about standards compliance.

The best content for your career. Discover unlimited learning on demand for around $1/day.