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 DOCTYPEs and px 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 div and span elements will be replaced by more meaningful elements such as nav, header, and video.
This means instead of marking up something such as
<div class="header">
<h1>Page Title</h1>
</div>or
<object><param><embed src="http://vimeo.com/3956190"></embed></param></object>we’ll be able to mark up the same HTML like this:
<header>
<h1>Page Title</h1>
</header>and this:
<video src="http://vimeo.com/3956190">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.
Additional resources:
- 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 (em or %) 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+ and Ctrl- (Windows) or Command+ and Command- (Mac).
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 Ctrl+/- and Command+/- 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 is 14px anywhere in the document, independent of parent elements whose font-size may differ.
Additional resources:
- 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.
78 Comments
Veer: Visual Elements for Creatives.Stock photography, type, and killer tees. Genuinely recommended by Authentic Boredom.
“The bad news is HTML 5 is not currently supported adequately by major browsers”
— and that’s the main problem!
We’re currently transitioning (arf) back to HTML 4.01 Strict from XHTML for exactly the same reasons. Seems like the logical thing to do, give the evidence of HTML5 slowing coming into being, while XHTML2 flops around gasping in the shallows.
As for the font size thing, I think we’ll stick with EMs for now. It’s not so painful once you get into the habit, and there’s something reassuring about setting tight typographic design using EMs to layout your pages. (Just a personal preference, however.)
I’m all for going back to px for font-size, but let’s refrain from ever go back to mind-numbing tables!
Great post, Cameron, but I actually disagree.
Isn’t the smartest to use the _best_ doctype, not necessarily the _newest_ (or, in this case, one that lends well to eventually switching to the newest)?
There have been plenty of vocal critics of HTML5, claiming that elements like and actually pigeonhole developers.
Your points are all valid, and when it comes down it, it’s a simple matter of preference. But I haven’t seen enough evidence to support moving toward HTML5 (and, therefore back to 4.01).
I’m not sure I follow the reasons for the move to HTML4 from XHTML1.0. Even if XHTML doesn’t go anywhere, there’s nothing particularly wrong with it is there? And it’s not like you can’t transition from XHTML1.0 to HTML5 when the time comes. Functionally from our perspective, there’s very little difference between HTML4 and XHTML1.0.
Great insight Cameron, back to PX it is. Your last comment about tables made my stomach a little sick though since I’ve got a few HTML emails to wrap up today.
It will be nice when email clients make the switch to common sense.
Nice post Cameron, I’m actually considering the switch ro HTML 4.01 myself. I’ve had to work on too many legacy sites to have the luxury of switching to ems instead of px so I’m quite comfortable with px.
Jon Tangerine has a great post about HTML 5 for semantics that I love revisiting as well.
http://jontangerine.com/log/2008/03/preparing-for-html5-with-semantic-class-names
I’m glad someone relatively noteworthy finally pointed this stuff out. Thank you! Now I can reference this when someone gives me hell for using px values or HTML doctypes.
I had read an article somewhere a while back, I believe it might have been Dave Shea’s article you referenced. I did research and see the logic in what was presented to me and do agree that XHTML was not ever implemented as it was intended to be used.
However, it seemed that when I tried to make the switch back, a lot of people frowned upon it like I was unprofessional or didn’t know what I was doing.
Hopefully some of them will see this post and be enlightened slightly so that they will refrain from wanting to use XHTML 1.0 for no reason at all; aside from because it’s “the standard” right now.
I agree re move back to px sizing, life was so much simpler in px land!
I suppose the only legacy practice left to switch back to at this point is tables…
We already can you tables again,
display: table
Good points all around. I have to say though, I never did fully agree with ems and % for type sizes - so I will gladly move back px. As far as DOCTYPES and HTML5 is concerned, let’s just get rid of IE - I’m sure that will solve at least 70% of the issue. :)
A variation on this theme that I’ve been looking at is using the HTML5 Doctype without using any of new HTML5 only tags. I like having a basic HTML template (that validates and puts browsers in standards mode) that I can easily remember:
http://josephscott.org/archives/2008/12/minimum-html-5-document/
I listen to the reasons people give as to why are they on the HTML5 wagon… and they say things like:
- Everybody else it doing it
- It’s the future
- xHTML2 is going nowhere
- 5 years ago we all thought that we’d have an XML web by now, and since we don’t, we never will, so we should just use HTML4 until 5 comes out.
- xHTML is dead
- HTML 5 has a <nav> element
- I’d love to use xHTML/XML, but why bother anymore?
These are all silly reasons.
All of my CSS heros, (Dave, Molly, Cameron, etc…), that inspired me to become what I am today, have jumped ship on an XML based semantic in favor of HTML4 and the upcoming HTML5. All for reasons that I do not yet understand. Perhaps I am too blind—or stupid—to grok your reasons.
Because I believe in perfection (getting as close as I can), I love XML from an ideological perspective. (although I have practical reasons too)
Now I am left with a minority, we will probably be mocked by the community at large. That sentiment will then flow to clients and Company leaders/bosses/managers. This minority does not believe in HTML5, but will may end up choosing between HTML5 and a job. Yes, this is a worse-case scenario, but I fear it nonetheless.
I hope those of us still believing in a semantic XML web will be able to band together, and keep each other alive during the dark times ahead. And, I hope that those who believe in HTML5 will not try to paint us as fools.
Take care,
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.
I’d be very careful in using this assumption to make the leap that designs no longer need to adapt to differing font sizes.
The default behaviour of page zooming rather than text zooming is just that - a default behaviour. Default behaviours can, by definition by changed. As can default text sizes (either in the browser or at OS level).
Both these factors mean that specifying 14px in a style sheet still does not necessarily mean text will be rendered at 14px, whether or not page zoom is set to 100%.
To clarify: there is certainly more reason now to use pixels rather than ems for text size, but designs still need to be able to accommodate varying text sizes.
While px sizing is so much easier and neater, I still can’t bring myself to do it.
There are just too many people who need text scaling who continue to use older browsers which scale rather than zoom (and I’m still not 100% convinced that zoom is better than scale, but that’s a whole other ball of wax).
While it’d be great for them all to upgrade, sometimes it’s just not feasible. Notwithstanding the whole corporate desktop thing, for some users, the learning curve for even something as simple as a new version of a browser is too high.
I’m not entirely sure what my inner criteria for when it’s okay to move the burden of inconvenience from the developer to the user is, but it doesn’t feel like its been met yet.
HTML rather than XHTML though - I’m all for that, and have started to make the switch back over the last few months.
@Ben, there is a great reason not to use XHTML. XHTML is ideologically broken. http://robertdot.org/2006/11/19/the-great-mime-type-swindle/
@ Niki Brown: I have no idea when HTML 5 will be fully adopted. As I mentioned, estimates range from months to years.
@ Richard Rutter: Good clarification/counter-argument.
@ pixeldiva: As with nearly all of the decisions we make as web professionals, you, me, and everyone else needs to make the right decision based on your audience and users. That is the one constant that will never change with all the changes that have occurred and are bound to occur in our industry. So, if relative sizing is the right choice for your project, no one else can tell you otherwise.
It’s amazing how much influence proiminent web designers have in this industry: A few blog postings and now the long championed XHTML is being tossed.
On the pixels: in my opinion, they were always the best choice.
What happens when people realise page zoom is actually just annoying as it forces you to scroll horizontally?
Shouldn’t we be coding websites to be as flexible as possible in the face of whatever people and browsers of the future throw at it?
With regards to text size Cameron, you are assuming visitors of the non technological mind actually update their browsers to the latest versions.
How do you propose accommodating for those still using Safari 3.X? Or (though I have dropped support for it) IE6, whose default action is to increase the font size.
Would you create more stylesheets? or would you simply design your sites for the latest browsers?
I only ask, as I tend to follow your design trends, always have done since I first got into web deisgn.
Maciej Stachowiak’s Understanding HTML, XML and XHTML (from 2006) seems fairly compelling in favor of HTML over XHTML.
But I’m waiting for someone to start walking the walk. This very page has a “XHTML 1.0 Transitional” Doctype declaration.
Cameron, as a prominent figure in the web community, and as a person with a great deal of influence. I wish you would be more careful as to what you say. Many people reading your blog may take it as gospel and not do their own research, assuming instead that you have done your homework.
The fact of the mater is, not all users use the keyboard shortcuts for zooming their browsers. Some people may use the text zoom features, or manually set the minimum base size to something larger. This is true for both mac and widows browsers that I have tested.
There was a time when I too thought that going back to pixels was the way to go. So this is not an original thought. I even changed my personal site to use pixels, and now regret making that decision. It wasn’t until after doing my own testing that I discovered that using pixels was still not acceptable for use by todays browsers.
My advise for all developers. Do your own research and not take the word of a select few at face value.
Cameron I’d love to hear your input on how zooming plays out on mobile devices if your site is using pixels. I’m working on something for my employer right now and we were unsure so we went with ems to be safe.
I don’t think changing from ‘em’ to ‘px’ is the better choice.
We don’t have only browsers that support zoom. We have IE6 yet which, for me, is a good reason to consider the ‘em’ unity.
By the way, we need to support other devices, so we need to care about our font size. 1px on a 19” display is different than 1px on a cellphone display.
@Jacob:
if you believe in perfection, you should not use XHTML.
First, in perfect world it should be served with an application/xhtml+xml MIME type which IE does not understand.
Second, when it is served with text/html MIME type, even browsers supporting XHTML (all, except IE) will use their
html engines to parse the code.
Third, in HTML “/>” means completely different thing than it does in XHTML, and it only works because nobody cared to implement that correctly and now it is to late.
Basically correct XHTML rendering in HTML mode relies on a missing feature at best, and on the bug at worst.
Fourth, XML is just a grammar. It has now semantics itself. Semantics is given to markup by specification, so good old HTML 4.01 is as semantic as XHTML 1.0 (they are the same thing, only use different grammars).
As for px unit, I will just repeat - there was never anything wrong with
pixels. The problem was with IE.
Ask Joe Clark if you don’t believe me.
I’m sticking with XHTML Strict until HTML5 is widely adopted. There’s nothing wrong with XHTML in real life: I mark up a page in valid XHTML, break it into pieces and use a CMS to render it, view source, and it’s still valid XHTML. (I know all about IE not handling the MIME type. People will say “spaghetti code” as if that had any effect on how the page renders in the browser. I just don’t care how many angels are dancing on the head of the pin.)
Most of the leading industry designers and developers were avid promoters of XHTML back in the day, and groups like WaSP got software vendors to produce XHTML. Now HTML5 is the wave of the future and we’re supposed to ditch XHTML. I’d have to recode ExpressionEngine, for example, and it’s not worth the trouble since there is no real-life practical difference between using HTML Strict and XHTML Strict.
@Jacob (#15) — I’m not sure where you’re getting your list, but a very simple reason why I’ve decided to switch back to HTML is: I make web sites for clients. Web sites that have to work today. That forces a healthy dose of pragmatism when I look forward.
What works (or will work very soon) in browsers is what drives my decisions, almost exclusively. I can pine away for a better future that will never arrive (XHTML2), or I can look at the trends around me and extrapolate where things are going in five years.
The best technology doesn’t always win. Maybe XML would be better for the web, but it’s not the way I believe the web is going.
Bring back the <blink> tag!
We found during usability testing for a site with a large proportion of users with vision problems that most of them preferred to use text zoom instead of page zoom because page zoom almost always means horizontal scrolling. Also, page zoom was only made the default in those browsers because of so many designers’ inability to understand the fundamentals of how the web works and create bulletproof layouts. If you text zoom and suddenly things start overlapping or escaping their containers then the web developer is, sadly, incompetent. On that note, I see that your site handles text zooming very well :)
Does the use of XHTML or HTML really matter right now? Like @Dave S. said, we build websites for today. The average shelf life of what we do is often 2 years longer than it should be, but still relatively short termed.
I’ve got to accommodate today’s browsers today, and I keep an eye on what I’ll have to do tomorrow. I expect that as time progresses, each designer will have to make the decision to start embracing the new spec on their own terms.
Until the brave few start pushing out the HTML5, we/our clients won’t see the benefits of choosing HTML over XHTML.
If you switch back to px you are losing the zoom in Explorer 6/7…and we know today more than 50% of people still using IE
By the way, if you wanna write your css in ems without the problems of the conversions u just have to normalize your body in the CSS like this:
body {
font-family: Arial,sans-serif;
font-size: x-small;
font-variant: normal;
font-style: normal;
font-weight: normal;
line-height: 1.5em;
color: #333;
}
with this you have exactly 1em = 10px in all browsers so its quite easy build a layout (for example of 951px ) like with: 95.1em.
I’ve been using HTML4.0 after moving back from XHTML for a while now, but not because of the advent of HTML5 but because there were no advantages to using XHTML, particularly as IE won’t understand XHTML served correctly (see Rimantas’ comment #27).
Recently, I have been taking the cue from Jon Tan and Andy Clarke with regards using class names that reflect the new elements.
I’ve also been adding in WAI-ARIA landmark roles even though they don’t currently validate against any doctype because I believe the extra accessibility outweighs the errors that the validator will report.
I’ve also come across the argument about going back to pixel sizes and if, as Richard Rutter points out, you take care that your layouts still scale reasonably with either page zoom or text zoom (I found out you can change Firefox’s default setting to use text zoom instead which I much prefer), I don’t see using pixels as being much of a problem (except for those still using IE6), but I’ve yet to go down that route yet.
I know you mentioned using tables in jest, but it’s really not much more of a hack than using floats for layout. Floats were originally intended (if I’m not reading too much into the spec) to position simple blocks of content within one-another, and not so much for layout as we use them today. Of course I’m not going to switch back to tables, but if the columns happen to fall into the correct source order I wouldn’t begrudge someone else for using them.
There seems to be quite a bit of indecisiveness around the future of HTML when there does not need to be.
I am excited about the future of the web and its great that we are passionate about where we want go but dumping XHTML just because HTML5 might be the standard of the future does not make sense to me. Just because the perception is that HTML5 will win over XHTML2 is not a reason to dump our current working practices.
I currently feel that pixel based designs are perfectly adequate as we are moving to having the browser zoom and not resize. The main point I want to raise here is that as Web designer/developers we do not need to jump on the bandwagon all the time.
We all want to work out the latest techniques and live on the cutting edge but practically we need use what works.
Just because you switch from XHTMl to HTML 4.1 strict doesn’t mean you have to lower your ‘standards’ (sorry) in the way you mark up your web pages.
A validating HTMl 4.1 strict page is equally as good as a validating XHTML one. You will still be warned of errors in your code or things you may have forgotten to close, but being a great web designer/developer you surly wouldn’t be writting sloppy code, right?
A change of doctype doesn’t mean a change in best coding practises.
@Jose del Corral: There’s no way to convert em to px. Just imagine an minimum font-size of 13px (quite common). If you rely on default browser settings, you’re not only ignoring your real users – your layout *will* break.
That’s why px for font-sizes ist still not usable. No one wants to zoom. We should not force our readers to adjust their settings – our layouts should adjust to *their* needs.
@Thomas Scholz: I disagree with your comment that you can not convert em to px, i always normalize my body with the params i wrote in the other comment and i can work easy with the equivalence 1em = 10px, so its easy to convert em to px, no matter the font-size.
Totally agreed on XHTML->HTML4; I see-sawed between the two for a period of time, but settled on HTML4 about 2 years ago. IE killed any hope we ever had of moving to XHTML, unfortunately.
However, I must take issue with the change from ems back to pxs, for the following reasons:
1. It completely breaks the accessibility of your site for users who change their default font size. If you know enough about your audience to live with that, fair enough, but I certainly don’t, and I don’t know many people that do.
2. Setting an absolute size for every element on your page is fair enough until you want to change the size of everything - either at the document level, or on any other ‘large’ container. A lot of style is actually inherently relevant rather than absolute.
It has been noted sideways by others already, There is one major issue with using px for font-sizing: with em or % you scale the font-size proportionally to the user’s default. At least there is a semblance of respect. With px you loose that relationship. That is: 12px is always 12px, where as 75% will scale to the user’s taste. 12px will look very small for a user who set up her base font-size to 24px. That happens more often than you’d wish.
Oh, and I meant to say, sometimes its desirable to have text on the page scaling whilst images remain a fixed size. In fact, for me, this is true most of the time. I don’t think we can write off text-zooming just yet. But all we need is for Microsoft to fix IE and that will be a non-issue.
@ Nik:
If you text zoom and suddenly things start overlapping or escaping their containers then the web developer is, sadly, incompetent. On that note, I see that your site handles text zooming very well :)
Interestingly enough, this site uses px for all of its font sizing.
@ Dave Bastian:
But I’m waiting for someone to start walking the walk. This very page has a “XHTML 1.0 Transitional” Doctype declaration.
That’s because the template for this very page was coded nearly 5 years ago :)
@ Bobby Jack:
Setting an absolute size for every element on your page is fair enough until you want to change the size of everything - either at the document level, or on any other ‘large’ container. A lot of style is actually inherently relevant rather than absolute.
Can you give a practical example of this?
Thanks for writing this one. I agree and was happily reading until that last line… Site Point recently mentioned the possibility of tables again with HTML5 and I shudder at the thought of having to work with someone’s badly coded tables again (or more of them since I still see them used). Please no more nested tables.
isn’t there an NL element for navigational lists?
Exactly what is not supported in HTML5 though? The main thing is that you can’t style the new “unknown” elements in IE if you don’t include a small JavaScript. For stuff like web applications dependent on JavaScript, that doesn’t matter much.
Also, you can, from what I understand, still use the new elements as selectors in IE, which would make it possible to do for instance <nav><ul> and nav ul { } instead of <ul class=”nav”>
If it works, and It’s The Future ™, why not use it?
Tim: That’s in XHTML2.
@Cameron: I knew you’d call me on that one! ;-) Something like image captions are a possible example: you probably want their font to be smaller than their container’s font. I’ll admit that’s a niche case, though.
I guess the main scenario I’m envisaging is a ‘scale up all my fonts by a factor’ which is trivial if you’re using relative fonts and a pain if not. Sure, it won’t happen a lot, but I just don’t see that many disadvantages to using ‘em’-based fonts.
The accessibility issues are far more important, in my opinion, anyway.
@Jacob Rask
nav ul li works:
(Haven’t included the IE js, so it won’t work in that).
I think I will stick with the XHTML 1.1 doctype.
According to the CSS 2.1 Spec pixels are relative units
I’ve been using HTML 4.01 Strict doctype for a couple of years for this very reason, and the fact that some versions of IE get all bent out of shape with XHTML.
On the question of using px for font-size, I understand the argument and now that we have page zooming in most browsers I see as perfectly acceptable, however I’ll stick with EM as it’s now second-nature to me.
What I would like to see though, is the ability to change line-height in a browser. Often it’s not the font that’s been set too small by the designer, but the line-height making it hard-going to read.
You can visit some brazilian website that use HTML5 in your markup. The Tableless.com.br is a brazilian website focused on tableless technicles, and it uses HTML5 in your markups…
Very nice article. Thank you for the insight. Woulkdn’t it make more sense though to have a markup as such if we are trying to get rid of redundancy:
<header>This is my h1 tag</header> ?
@Meshach:
I think I will stick with the XHTML 1.1 doctype.
Zero IE users in your target audience? Very enviable :)
@ Tim Akinduro:
Wouldn’t it make more sense though to have a markup as such if we are trying to get rid of redundancy:
<header>This is my h1 tag</header> ?
<header> can be used multiple times throughout the document, hence it’s still necessary to indicate the level of the heading. In other words, you can use it once at top of the document for <h1>, a second time for <h2>, etc.
Using fixed font sizes just “feels” wrong to me.
If we go back to print, everything is sized for the particular final size of the media it’s printed on. The fonts are fixed-sized. Let’s say I have a book with a 14pt header, for example. If the publisher later decides to make a large-print edition, someone needs to go in to InDesign and tweak the size of each font individually. But if books could be set with relative sizing then they could simply say “increase the base size by 200%” and everything would adjust accordingly.
Relative sizing seems like the proper way to do any kind of font sizing since that’s how we perceive the font anyway - that heading is twice as big as the body. And in most cases you to keep that proportion, no matter how you scale your original. Obviously if you go ridiculously large (billboard) or small (pocket sized bible) you probably will adjust those proportions manually.
I’m still not convinced that px are a viable way to size fonts just yet.
My biggest issue with page zooming is that on smaller resolutions it *may* cause horizontal scrolling which can be really frustrating!
I prefer to use “menu” instead of “nav”. I started using “nav” at first but I realized that “menu” is much more meaningful than using “nav” as a name for the main site menu.
Thanks for this article. I will definitely consider switching to pixel based font sizes but I’m not too sure about the strict doctype though.
@ Rob Cameron:
But if books could be set with relative sizing then they could simply say “increase the base size by 200%” and everything would adjust accordingly.
Your argument sounds reasonable, but have you ever done anything like this with a website? Do you ever see yourself doing this?
i do not really understand why zooming seems to replace text scaling as default in browsers. while my eyesight is still ok, i do have to enlarge text on web sites pretty often; and everytime this forces me to scroll horizontally i almost want to cry.
Cameron,
I think it’s good to see people such as yourself and Dave Shea moving back to html. With regards to your use of html5 why not use something like
<nav>
<ul class=”nav”>
….
</ul>
</nav>
you then have the hooks you need to style for IE but can retain the semantic value of the <nav> element. This futureproofs your site slightly. When the time comes, remove the class and you’re good to go.
By default most new html5 elements are treated as inline (even though some should be block) by browsers currently. Alternatively just include them in your reset styles so they are inline and have no margin and padding, border etc for when browsers update their default styles.
Also I would say be wary of some of the semantic class naming cheatsheets out there as some advocate using id=header but as Cameron points out you can use multiple <header> elements in a document so class=header is much more appropriate.
Re Font sizing, I think Richard Rutter makes a great point about users having the ability to overide the default. Does anyone know of any way to track if users resize text on your site?
I ought to add to the above, this all obviously depends on how much you are concered by validation. If you are steer clear, if not why not add it in.
Thanks for the useful info. It’s so interesting
@robert forkel
I’m with you there. I don’t understand why page zooming became so popular, especially since most GOOD browsers can resize fonts specified in px anyways.
I’ve already moved back to setting type in `px` for all my personal work (as well as projects I do in work for modern/specific browsers). We still fully support IE6 on client work, thus using relative font sizes.
As for HTML4, I don’t see any harm in this but I don’t see any advantage over sticking with XHTML and switching to HTML5 when the time comes. Although it might make the transition to HTML5 a little sooner and smoother.
Either way, it’s good to mix things up every now and again.
@Kyle Peterson: I’d have to dissagree. Surely if I set something to 14px it should remain as 14px? Controvertial I know, but in this case I think Microsoft got it right. If I remember rightly the CSS2.1 spec defines px sizes as relative to the display, not the browser settings?
I tend to use px for large headings (say over 20px) and ems for everything else. You can also combine an em text size with px line-height which works great for menus.
Text resizing is far more usable than page zoom and the only problem with using ems I’ve found is that it makes vertical rythm a pain. I’d say that a more accessible website is worth the lack of verticle rythm.
There is a law in Italy (Legge Stanca 04/2004) which states that institutional sites should be developed using XHTML 1.0 strict.
That law lead to a sellers’ generation of “tableless XHTML websites” which become a defacto selling standard: it’s not important about the lack of content or the ‘99 design style but the site (well the home page for sure) it is XHTML.
You are making a good point, but the real problem is how to say to stakeholders “Well XHTML is in fact, not so important…”
http://hixie.ch/advocacy/xhtml
Is the most compelling reasoning I’ve seen for ditching XHTML. To write comments that work in a mime-type outside of text/html (possibly required if file is used as XML) is very painful. Though I too cannot use HTML5 for my clients (too many IE6 users to ignore) I’ve been using HTML 4.01 where I can.
I’m sticking with ems though the designers I work with hate it. Often the designs that come by me have too small type for people with less than adequate eyesight.
won’t there be an xml-version of html5 like xhtml5?
great post, totally agree.
now that all modern browsers support zooming there is no need to use ems.. and calculate the sizes.
I’d noticed the recent trend for page-zooming myself recently. Made me remember many years back when I first incredulously learned “em units can do that??” and created my first truly accessible layout
I guess I’ll be going back to my pxs!
Regardless of which side of the fence you are on, can anyone explain to me why I shouldn’t mix ems and px within the same document? I’ve heard it’s a faux paus, but haven’t necessarily broken anything yet.
If it’s not an unpardonable sin, is there an appropriate way of going about it if one were so inclined (erm, lazy)?
Oh man, I just fought a month-long battle at work arguing against px in favor of percent or ems. Now I’m not to sure…
I’m staying xhtml strict until 5 comes out.
well, i have to say i’m not in agreement with these conclusions, but i like your viewpoint. this subject has too many variables and false info in the market that i do not know what to believe. i guess it’s a matter of being informed. buy acai
Looks like you made the right call, Camron. Zeldman is reporting that the XHTML 2 team has made a decision to not continue their work past the end of the year. It sounds like they will be joining the HTML 5 team and combining their efforts.
This is a pragmatic approach as much as it can get. Nicely done. Thank you.
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:
- Recent job listings, testimonials, and 100th Kiva loan
- The ISO50 Field Guide to Color Management
- Upgrading the hard drive and memory in a refurbished 13" MacBook Pro
- Inspiring type: Libro di M. Giovambattista Palatino
- Randomness, vol. IX
CSS Mastery: Advanced Web Standard Solutions A solid round-up of indispensable CSS design techniques by Andy Budd, Simon Collison, and Cameron Moll.
Mobile Web Design A guide to publishing web content beyond the desktop. Tips, methodology, and resources. Now available.
Letterpress Posters The unassuming beauty of a freshly letterpressed print.
That Wicked Worn Look. Techniques for that worn, aged, distressed look.
Mister Retro Machine Wash Filters Turn the dial to “Instaworn” with these filters.
Blinksale Dive in and enjoy shamelessly easy invoicing from Firewheel Design.
Basecamp My preferred web app for internal and client project collaboration.
HOW Conference Austin, June 24–27. Pentagram, Adobe, P&G, et al.
Web Design World Seattle, July 20–22. Practical sessions on web design.
Stimulate Salt Lake City, September 2009. Entrepreneurship and design conference.
Linkage:
Follow me: 
1 Niki Brown ~ 04 June 2009
Any guess or idea when HTML5 will be adopted?