Coding like it’s 1999
~ 04 June 2009 ~
UPDATE: Please see The debate over page zooming vs. text scaling.
Recently I made the switch back to HTML 4 for
font-size (sound like 1999 again?), and I’ve tweeted about it occasionally. I’m documenting the switch more thoroughly here.
HTML 4.01 Strict
I’ve chosen to go with HTML 4.01 Strict as the
DOCTYPE in my projects moving forward, favoring it above XHTML 1.0 Strict and HTML 5. I’ll briefly explain my reasoning.
XHTML 1.0 Strict – This is what many of us in the industry, including myself, have been using for the past few years. However, Dave Shea offers a compelling argument to drop XHTML with an eye towards HTML 5:
“Six years ago, many of us thought XHTML would be the future of the web and we’d be living in an XML world by now. But in the intervening time it’s become fairly apparent to myself and others that XHTML2 really isn’t going anywhere, at least not in the realm that we care about…. I’m not ready to start working through the contortions needed to make my sites work with an HTML5 DOCTYPE yet, which leaves me with the most recent implemented version of the language…. [U]ntil I get a better sense that HTML5 has arrived, 4.01 will do me just fine for the next four or five years.”
HTML 5 – In a nutshell, HTML 5 is the next major version of the hypertext markup language. The good news is meaningless
span elements will be replaced by more meaningful elements such as
This means instead of marking up something such as
<div class="header"> <h1>Page Title</h1> </div>
we’ll be able to mark up the same HTML like this:
<header> <h1>Page Title</h1> </header>
The bad news is HTML 5 is not currently supported adequately by major browsers (notably Internet Explorer). Estimates range from months to years before HTML 5 is fully supported and therefore a viable option for all of us creating websites.
An alternate approach is to maintain that same watchful eye towards HTML 5 by writing markup using current
DOCTYPEs but with semantic, HTML 5-like
class names. Jon Tan covers this approach beautifully in “Preparing for HTML5 with Semantic Class Names”.
For example, using the
nav element, HTML 5 markup would be
<nav> <ul> <li><a href="">Item 1</a></li> ... </ul> </nav>
while our semantic, HTML 5-like markup using HTML 4 or XHTML 1 would be
<div class="nav"> <ul> <li><a href="">Item 1</a></li> ... </ul> </div>
However, the drawback to this approach is you potentially end up with a lot of extra
divs. If our goal is meaningful and lightweight markup, the most optimal markup right now would instead be the following:
<ul class="nav"> <li><a href="">Item 1</a></li> ... </ul>
So, my opinion about HTML 5? We’ll all adapt just fine when it’s ready for prime-time and fully supported. The mental shift will be minimal. Until then, I’ll keep coding the way we’ve always done it.
- 12 resources for getting a jump on HTML 5
- Wikipedia: HTML 5
- Adactio: The Rise of HTML 5
- O’Reilly: Google Bets Big on HTML 5
- Webmonkey: Google Throws Its Weight Behind HTML 5
px for font-size
For a number of years,
px was the de facto standard for sizing text with
font-size. It gave designers transferring their design from Photoshop (or other software) to HTML a consistent, absolute unit for text size. Then, as we became more knowledgeable of and concerned with accessibility, relative text size (
%) gradually became the preferred unit. This enabled low-vision users, and really anybody, to change their browser’s default text size permanently via the browser’s settings, or on-the-fly using the keyboard commands
Ctrl- (Windows) or
Accordingly, and up until recently, all major browsers would scale up or down the size of the text while retaining the formatting and layout of the page. This is commonly called text scaling or text zooming. This adaptation required us to create markup that allowed for relative sizing of any elements containing text. For example, if a
div contained text set atop a background image, we would have to either repeat the image as the
div grew larger with text scaling or create the image larger than necessary to compensate for growth. This is something I covered in detail in my “The Highly Extensible CSS Interface” series of articles.
However, recent versions of every major browser — Safari, Firefox, Google Chrome, Opera, and yes, Internet Explorer — now default to page zooming instead of text scaling for
- commands. Page zooming literally zooms the entire page — layout, formatting, and text size — in unison. Elements retain their size and shape, which greatly reduces the need to compensate for text scaling. In effect, the browser assumes the burden of relative sizing.
What does all this mean? It means
px can again be considered a viable value for
font-size. It means the difference between setting text with absolute units or setting text with relative units is negligible for users. For you and me, however, the the difference is substantial. The burden of calculating relative units throughout a CSS document is replaced by the convenience of absolute units —
14px anywhere in the document, independent of parent elements whose
font-size may differ.
- Wilson Miner: The problem with pixels
- 456 Berea Street: IE 7 does not resize text sized in pixels
- Mezzoblue: Zoom
- Ordered List: Hello Old Friend
I suppose the only legacy practice left to switch back to at this point is tables…
UPDATE: Some of you may have been led to believe I’ve given a mandate for the industry to move to HTML 4 and px. Please note I’ve documented only my switch here and the reasoning for it, and that px can be considered a viable value for font-size. As I mention in the comments, you need to make the right decision based on your audience and users. If XHTML and relative sizing is the right choice for your project, no one else can tell you otherwise.
Stock photography, type, and killer tees. Genuinely recommended by Authentic Boredom.
Authentic Boredom is the platitudinous web home of Cameron Moll, designer, author, and speaker. More…
Full-time and freelance job opportunities. Post a job...
A selection of fine reading, available for a limited time only: