Sounds good to me! This has always been a frustration for me when creating web sites. Mr. Nielsen strongly encourages relative font sizing so that a page can be massaged for bigger monitors or people that just like (or need) big text. But in practice this proves to be very difficult because of the wide range of different renderings found within different browsers and different operating systems. Sometimes the text is huge.. other times the text is tiny. The most common fallback was to just hardcode everything to a specific pixel size and be done with it.
I've read through Mark's tutorial, and don't doubt that the solution works, but have to admit the style of the solution makes me wary. Essentially the fix relies on some obscure bugs that exist in Netscape 4.x and Mac Opera 5. It exploits these bugs to trick certain browsers into ignoring some CSS and forcing others to parse it. The biggest advantage of this approach is that it avoids the need for browser detecting and the use of multiple CSS source files. One CSS to rule them all.
All well and good, until a new browser is released that is (or is not) fooled by the syntactic tomfoolery causing a wide range of participating websites to fail in a potentially unpredictable way. New releases of software rarely aim to be backward compatible as far as bugs are concerned.
The other gotchya is how potentially unmaintainable the code becomes. Looking at the mix of CSS, specific spacing and unusual comment usage that forms Mark's solution it all feels so random and fragile. If you were not aware of the problem it was solving, you might look at the code and think the developer's cat walked over the keyboard while he was off getting a Jolt™.
I don't mean to pick at Mark's solution. It seems to work and once explained makes a reasonable amount of sense. I think I am more frustrated by the complexity of a cross-browser solution to do something as simple as provide a predictable relative font sizing scheme. Ugh.