Pragmatic, practical font sizing in CSS

One thing I’ve been thinking a lot about lately is how to build sites properly. Not what we have been told is proper, but what actually makes sense for us as developers. I recently spoke at The Digital Barn on exactly this; my talk—Breaking Good Habits—dealt with how we as developers need to solve problems not only for our users and clients, but for ourselves as well.

Nicole Sullivan—who totally rocks—has laid a lot of new foundations for us in her work on OOCSS and her ‘unconventional’ but absolutely spot-on approach to building websites. Gems like the media object have seriously changed how I build websites and, if you take the time to study it for yourself, I think it might just do the same for you as well.

Double-stranded heading hierarchy

Another absolutely stellar nugget of wisdom she’s given us is what I call double-stranded heading hierarchy. This is the practice of defining a class every time you define a heading in CSS.

For example, if—for whatever reason—we want our h2s in our sidebar to be the same size as a h1, and the h4s in our footer to be the same size as a h3, we might have had some code like this:

<!-- HTML -->
<div class=content>

<div class=sub-content>

<div class=footer>

/* CSS */
.sub-content h2{ [font styles] }
h2{ [font styles] }
.footer h4{ [font styles] }
h4{ [font styles] }
h5{ [font styles] }
h6{ [font styles] }

But now we’d have:

<!-- HTML -->
<div class=content>

<div class=sub-content>
  <h2 class=h1>Lorem</h2>

<div class=footer>
  <h4 class=h3>Lorem</h4>

/* CSS */
h1,.h1{ [font styles] }
h2,.h2{ [font styles] }
h3,.h3{ [font styles] }
h4,.h4{ [font styles] }
h5,.h5{ [font styles] }
h6,.h6{ [font styles] }

As you can see, the former is far more arbitrary and those lists of selectors can soon become unwieldy, especially over a larger project. By assigning a class along with each heading style we now have those styles attached to a very flexible selector that can be moved anywhere, rather than to a very specific and non-movable one.

Now, I’m not such a fan of the .hN notation, I much prefer a solution that I believe to have been suggested by Mr Jeremy Keith, and that is to use abstract classes made up of the first six letters of the Greek alphabet, thus:

h1,.alpha   { [font styles] }
h2,.beta    { [font styles] }
h3,.gamma   { [font styles] }
h4,.delta   { [font styles] }
h5,.epsilon { [font styles] }
h6,.zeta    { [font styles] }

Which now gives us:

<div class=content>

<div class=sub-content>
  <h2 class=alpha>Lorem</h2>

<div class=footer>
  <h4 class=gamma>Lorem</h4>

Neat, huh?

So now .alpha can carry the style information of a h1 wherever you wish; it doesn’t depend on location or a type of element. A double-stranded heading hierarchy; lovely.

Extending this?

Okay, so now we have our heading styles all nice and portable we’ve won most of the battle. I’ve been using this method for months now and I love it. My CSS is so much more efficient, more portable, more powerful, I can build faster, I’m not repeating font styles over and over, but what next?

The other night whilst working on faavorite with Nick I came up with a full on font-sizing micro-framework.

The problems I found I had with font-sizing on any site include (but are not limited to):

And a few important things to remember:

With this in mind, I decided that I wanted to use font-sizing much like a grid system; define it once in the stylesheet and just constantly reuse it.

Preset font sizes

Like colour palettes are, font sizes should be strict, predefined and intentional. From both a code and design point of view, you shouldn’t deviate from your scale—you shouldn’t really ever need to and doing so will just make code harder to work with.

Presetting your font sizes is pretty easy; typically you might have requirements for:

Setting the base font size is simple, just pop it on the html and everything will inherit it, paragraphs, lists, tables, you name it.

For your headings you define a series of hN and its corresponding Greek letter class, e.g. h1,.alpha{}.

Non-standard font-sizing

You ever had that need to turn a design up to 11? When you have a masthead promo and even a h1 ain’t big enough? I think we all have…

It’s tempting to create a new, unique selector to cater for this new requirement, perhaps something like:

.masthead h1{ font-size:5em; }

And whilst this will work, you’ll only ever get that 5em goodness if you use specifically a h1 that is specifically in a .masthead. This isn’t very reusable at all. Sadface.

To combat this, I decided to create some new abstract classes, this time borrowing SI prefixes. Now we have the h1,.alpha{} through to h6,.zeta{} that we did before, but as well as those we have:

.giga{ [font styles] }
.mega{ [font styles] }
.kilo{ [font styles] }

These classes are the ones above h1 and are the seldom used ones that make stuff massive!

Going the other way?

Okay, so far we’ve worked with body copy to headings to beyond; what about small print? Well I opted to use:

small,.omega.milli{ [font styles] }

small has been redefined in HTML5 so that’s an element we can use again freely and .omega is simply the last letter in the Greek alphabet.


That there genius and awesome chap Tom Hudson suggested I use .milli for this as it goes below the regular scale. So, anything on the normal scale is Greek letters, anything off the scale (above or below) is SI prefixes.

Vertical rhythm

To maintain vertical rhythm we need two key ingredients; consistent line heights and consistent bottom margins. We need a magic number. This number is typically defined by the line height of your body copy, so if you have html{ font-size:16px; line-height:1.5; } then your magic number is 16 x 1.5 = 24.

Now you know that all your line heights and margin bottoms have to be a multiple of 24px.

Bringing it together

It really is imperative to take a look at an actual example of all the above brought together in order to fully ‘get’ it. I made this jsFiddle demo of just CSS; you can add HTML and tinker with it yourselves, combining elements with classes to create double stranded, portable font sizing framework stuff!

Where does that leave us?

We now have a self-contained font-sizing framework which should hopefully mean we never need to define another font-size declaration again! We can manage our brand specific type rules from one place, we can build stuff faster, we can build faster stuff, we can keep our code DRYer, we can keep our styling a lot more consistent, we can keep styling location independent and we can make far reaching changes in one fell-swoop!

Feel free to take the code and modify or improve it.

Also please note that I am not suggesting we all use these specific classes; experiment, find your own, see what you’re comfortable with and report back!

By Harry Roberts on Wednesday, February 29th, 2012 in Web Development. Tags: , , , , | 48 Comments »


48 Responses to ‘Pragmatic, practical font sizing in CSS’

  1. Win said on 1 March, 2012 at 12:02 am

    I’m not sure I get the part of the double-stranded heading hierarchy, why assigning the font style to h1 and the sub-content h2.

    Do you have any more info or post about it?

  2. Matt Berridge said on 1 March, 2012 at 12:07 am

    I do a similar thing to what you described using Less.

    Declare “font-X” as a mixin then just add .font-24 for example where needed.

    Allows font size to be managed in one place, but it does keep the rules specific I guess.

  3. Mike Stezycki said on 1 March, 2012 at 9:29 am

    I really enjoyed this post Harry! I’ve adopted your heading styles technique and it really does make a big difference to how flexible and re-usable the css is.

    I hope we can use something like this for common layout patterns too, that have to be nested with added padding and margins etc.

    Brilliant read, as always!

  4. Matt Wilcox said on 1 March, 2012 at 1:34 pm

    I’m still unconvinced by this “litter classes everywhere” method of building sites.

    It ties presentational elements directly into mark-up, which is something the whole standards movement was about undoing. Yes, this renders your CSS more portable. But it renders your mark-up a lot less so.

    That said, I’ve not got too much of an issue with your specific examples, what you’re doing here is not the same as littering .col_1 or .float_left into the HTML – which is (for me) unforgivable.

  5. Nicolas Gallagher said on 1 March, 2012 at 1:44 pm

    Nicole wrote about this concept too:

    > It ties presentational elements directly into mark-up…

    CSS classes are meant to be used as hooks for presentation and behaviour – not to reflect the nature of content. They are distinct from the semantics of HTML elements and any attributes designed to be connected to the semantics of content.

  6. Brett Jankord said on 1 March, 2012 at 1:56 pm

    This is an issue I’ve been curious about for sometime. Abstracting the names of the classes for font sizes is brilliant. I like that with that you can choose any font size for the class, rather than a class like .font-24.

    I prefer the .hN classes to the greek letters. I also prefer using different names for the font-size classes, such as .small-txt, .medium-txt, large-txt, or xs-txt, s-txt, m-txt, l-txt, xl-txt. To me, those are more familiar, and remind me of the keyword syntax when setting font sizes: p { font-size: small; }

  7. seutje said on 1 March, 2012 at 2:00 pm

    Even though I agree with the underlying logic, I don’t like to riddle my markup with classes that aren’t really necessary. I much rather style things based on context, as that is what defines their meaning and (largely) their style.

    I agree with Matt Wilcox on the point that it does make your markup a lot less portable.

    Also, @Matt Berridge: Not entirely familiar with LESS, as I use SASS. But I was wondering, does LESS have a concept similar to SASS’ extend (google-fu is failing me right now)? Because when I use SASS, I avoid using mixins when there aren’t any variables involved, and try to use extend instead. Allow me to illustrate:
    On large projects, I’ve noticed this can significantly reduce your compiled CSS size. If prop:value pairs don’t change, they shouldn’t be repeated!

  8. Matt Wilcox said on 1 March, 2012 at 2:10 pm

    The problem I have with using CSS like this is best explained by considering this:

    What happens when you redesign? Your archived mark-up now has loads of hooks in to old design parameters. And the same argument can be made for responsive adaptions, is .delta going to *be* a .delta presentationally when you’ve adapted that page to a narrower design?

    As I say, in this specific example I don’t think it’s *too* bad, unlike if such a method was trying to solve layout issues. But even with this, imagine a client has used a CMS to style their content. Because that client has buried classes into the markup, it’s entirely possible that it won’t play nicely with re-designs later down the line, and what then? Are you going to trawl through all the old content re-applying class names to suit a new design?

    I think this is a kludge solution, but then I think a lot of HTML, CSS, and JS is a kludge solution.

  9. Harry Roberts said on 1 March, 2012 at 2:12 pm

    You will always have a typographical scale, you will always have h1 through h6 and body copy and small print. Always. When you redesign you simply alter what those sizes are, but there will still always be a scale.

  10. Matt Wilcox said on 1 March, 2012 at 2:16 pm

    I wrote about decent naming conventions and use approaches for markup a while back:

    This was my conclusion on using CSS classes in HTML:

    “If the mark-up is not enhancing the semantics or accessibility of the document, that’s bloat. If it still needs another hook for the design, then name the hook based on the semantics and put it as far up the DOM tree as possible (to act as a hook for more objects) and avoid entangling the different roles of CSS and HTML. Bloat in mark-up is my least tolerated bloat because it is the least necessary and has the largest impact on future work and ‘higher level’ technologies like CSS and JS.”

  11. Geoff said on 1 March, 2012 at 2:20 pm

    I’m not sure I like either approach to this double-stranded heading hierarchy. Perhaps something like:

    h1, .header-xl
    h2, .header-l
    h3, .header-m etc…

    …would be more semantic. (or .venti .grande and .tall if you are designing a Starbucks website!)

  12. Matt Wilcox said on 1 March, 2012 at 2:24 pm

    @Harry – yep, I agree, which is why I don’t have too big a problem with your particular use of this technique (although I still find it a bit uncomfortable). That said, I have experienced plenty of times clients using a h2 instead of a h4 simply because of the way it looks – they happen to prefer that style in that document at that time. Using classes stops the semantic problem but it’s still going to be an incorrect hook come the time to re-design.

    If it was just web developers making websites and adding content, there wouldn’t be much of an issue because we generally know to do it right.

    In many ways, when thinking about clients using CMS’s to create styled content, we could do with CMS’s that style sections by creating <style> in the head – so we can wipe those database fields when it comes time to re-design.

  13. Keith Streble said on 1 March, 2012 at 2:41 pm

    This method should not be recommended, period. The practice of separation of style and content–along with semantics–is extremely valuable. These are fundamental principles that need to be understood before advocated against. Shame, Smashing–this article is an embarrassment.

  14. Harry Roberts said on 1 March, 2012 at 2:46 pm

    “The practice of separation of style and content…”

    They are separate; your CSS is in your CSS file, your markup is in your HTML file, we tie the two together with classes.

    “…along with semantics…”

    Classes and IDs are not subject to semantics. They are neither semantic or insemantic, merely sensible or insensible.

    “These are fundamental principles that need to be understood…”

    The sad fact is that the majority of developers have these principles misunderstood.

    “…this article is an embarrassment.”

    I’m sorry you didn’t like it.


  15. Andy said on 1 March, 2012 at 3:11 pm

    Great article, i;ve done similar myself on previous projects. Shame that Keith Streble didn’t like it (or understand it), he is a big silly ^___^

  16. Rick Lowes said on 1 March, 2012 at 3:11 pm

    Hey Harry just a quick question – how do you feel it is best to handle if I am looking to reuse a specific style, but want to say make it normal weight vs. bold? Or to us a different the font-family? I’ve thought about applying a “.weak” class to make something normal weight (although not sure I’m comfortable with the granularity of that class), but no idea what to do about the font-family issue, as I’m definitely not liking the notion of a .font-family-name class…

  17. Rick Lowes said on 1 March, 2012 at 3:13 pm

    Wow I had some brutal typos/grammar in that last post – sorry about that :) Hopefully it still made sense.

  18. apnerve said on 1 March, 2012 at 3:18 pm

    Dear Keith Streble, you seem to be still living in 2003 or totally misunderstood Harry’s article.

    classes are just like hooks and have nothing to do with semantics.

    @Harry : Great article! Keep them coming.

  19. Mark S said on 1 March, 2012 at 3:19 pm

    My only real thoughts towards this are the difficulties when dealing with CMS inputs.

    I can inform editors that the highest heading to use in a section is a h3, to keep the hierarchy of the site; I can also style that h3 to look however I want in that section. (I can also style h1, and h2 to look the same as h3 in that section to avoid it breaking if someone decides to use them )

    Getting editors to use classes is more difficult and less necessary and that’s why I won’t use the method on externally edited sites.

    I’m also not a fan of the method for setting up vertical rhythm but I agree it’s important, and this is probably the simplest method

  20. Ian Feather said on 1 March, 2012 at 3:23 pm

    Not really sure what everyone’s issue is with this approach. To me it makes sense and I’ve utilised the same methods in the past (and still do).

    We’ve all been in the position where you have a heading which semantically should be a h5 but the design portrays it as an h3. This is an issue that you can solve by using an OO approach similar to the one written or by adding more declarations to your css. One place or many.

    Come the time to redesign you can then update it once in the css and dictate the rhythm of the whole site quickly and easily. You may have to update the html in several places (maybe not) but I don’t believe a redesign exists these days without a change to the markup.

    Maintainability is key. Semantics are maintained by the use of the correct element. Less bloat to the CSS.

  21. Scott said on 1 March, 2012 at 3:27 pm

    I don’t get some of the negative feedback on here. This seems pretty straight forward to me, and an over-all good idea.

    Even for CMS’s. Having the CSS set up as

    h1, .h1{}
    h2, .h2{} etc.

    that should make it super easy for styling the areas that the CMS wouldn’t touch, and then the areas that the CMS does touch, the H tags are already styled appropriately, so no re-assignment of classes is needed.

    Or am I just completely missing something that everyone else is having a problem with?

  22. emtwo said on 1 March, 2012 at 3:30 pm

    Great post my man, weirdly I’d employed similar principles after your talk at Digital Barn; except I’d just named them differently. it made everything so much more efficient, but seeing someone like yourself adopt and derive these techniques too, really helps validate the process.

    Top work buddy.

  23. Harry Roberts said on 1 March, 2012 at 3:31 pm

    @Rick Lowes: That is a very very interesting question! I advocate the use of .brand to hang colours from but yeah, yours is a little more interesting than that.

    Let me ponder it, cheers!

  24. Mark S said on 1 March, 2012 at 3:32 pm

    No, no confusion Scott.

    As an example, a contact page I’ve recently built has multiple (wysiwyg added) h3s that look like the h2s, as such my style sheet has

    h2, .contact-area h3 { … }

    which is what this is trying to avoid, all I was pointing out is that the solution doesn’t solve all situations. I agree when completing non editor areas the solutions great.

  25. Mark S said on 1 March, 2012 at 3:33 pm

    (In hindsight, re-reading my original comment, I said I wouldn’t be using the method on externally edited sites, when actually that’s just for WYSIWYG areas)

  26. Will Moyer said on 1 March, 2012 at 3:40 pm

    Great article Harry!

    One thing, your demo ( raised a question for me, something I’ve always wondered about: what’s the point of the unitless line height?

    I’ve read Eric Meyer’s original post about it, and many others recommending it, but I just don’t understand how it helps those of use who are concerned with well-set type.

    If I do this `html { line-height: 1.5 }` then the line height is going to increase proportionately on all my other type elements. If my h2 font size is set to 1.5em (24px if we’re assuming the default 16px) then the proportional line height is going to be 36px, which will throw off the 24px rhythm I’m trying to establish. So, like you did in your demo, I’m going to have the re-declare the line-height anyway in all my other typographic elements.

    I’d rather have the html element passing on a strict number rather than the multiplier, at least that way the default is to NOT mess up my rhythm.

    But everyone is always saying that unitless line-heights are the way to go. Am I crazy or missing something obvious here?

  27. Brett Jankord said on 1 March, 2012 at 3:42 pm

    I agree with Ian, a redesign without a change to the markup is rare. This approach helps reduce duplication in your stylesheet and keeps the file size small. This is especially important when thinking about mobile users.

  28. Rick Lowes said on 1 March, 2012 at 4:54 pm

    Hi Harry – yes in fact I have thought about using .brand for the actual font-family in my case because it is a custom font for our specific brand that I would be switching to in some cases – however the reverse is also something that may come up as well where I have our custom branded font already defined in one of our heading styles for instance that I might need to switch to a standard one like Arial.

    At any rate there may be no super-clean solution to this, however I do believe that what you’ve outlined still goes a long way to keeping your CSS minimal and DRY – I like it.

    For non-standard font sizing, I had actually simply defined a set of classes that were .x-small, .small, .large, .x-large, .xx-large – since my team have a number of developers that may be working with these styles on an infrequent basis, I thought this naming convention was a bit more inherently understandable.

  29. Rodney Weis said on 1 March, 2012 at 5:47 pm

    Thanks for presenting your ideas on practical font-sizing, Harry – I’ve found myself jumping through all sorts of hoops when attempting to do the same thing by appending classes to the h1..h6 tags themselves. This quickly devolved into a quagmire of code that was absolutely opaque the next time I looked at it.
    You’ve come up with an ideal compromise between markup bloat and CSS portability, and I look forward to applying these techniques.

  30. Patrick Samphire said on 1 March, 2012 at 7:01 pm

    I do like this method, and I think it can really clean up the messy, tangled, confusing CSS that otherwise results from complex layouts. I’m going to be adopting it. Like Mark S says, the main proviso is that if you’re using it in a CMS site that you’re not updating solely by yourself, you can’t really do this in editable areas.

    What I’m not convinced by is this argument (which I’ve seen a lot recently) that there’s no such thing as semantics in class names. I think this comes from a strangely limited use of the term ’semantics’ which has been adopted in computer science. Semantics, at its most basic, is simply about meaning.

    Mark-up has clear, defined semantic meaning (well, in most cases…), and we need to adhere clearly to that. But while class names don’t have any pre-set, defined meanings, it’s not the case that we can’t provide meaning through careful use of class names. It’s certainly not a good idea to just use absolutely anything for a class name. That’s why there’s a degree of semantics in your using ‘mega’, ‘kilo’, etc. in this example. (Although, obviously, you’re not actually using the real semantics of those prefixes).

  31. Todd Wolfson said on 2 March, 2012 at 8:14 am

    Great article and love the semantic choices. I was trying to figure out what comes after something like ‘textBig’ or ‘textDark’ and neither ‘textBigBig’ nor ‘textDarkDark’ make sense. But at least this article solves the first half of the problem with ‘textMega’.

    By the way, a definite read should be SMACSS. It takes OOCSS and gives somesolid examples to the concepts as well as builds out its own style guide/semantics. It is available for free at:

    Anyway, love the post and the blog. Keep up the awesome ideas!

    – Todd

  32. Oskar Rough said on 2 March, 2012 at 9:29 am

    Using the greek alphabet instead of the number ordering, we’re already using in this case – why?

    .h2 vs .beta? To me, the former describes exactly what we want. It’s shorter as well. Bonus!

  33. Cindy said on 2 March, 2012 at 3:10 pm

    Interesting, but why not just simplify the class titles?

    h1, .one
    h2, .two

    and so on…..

  34. Keith Streble said on 3 March, 2012 at 7:42 am

    Ok, I may have come off a little harsh earlier. My apologies for that, but I asure you that I did not misunderstand your blog post or the methods presented. Your writing was very clear. Kudos to that.

    To clarify my comment from before, here are the weaknesses I recognize in this method:

    Class names are more valuable when semantic.
    I agree with your your Web Design+ blog post which states: “The fundamental aspect of a maintainable project is well structured and semantic markup. Proper indentation, semantic ID and class names and valid markup all lead to better code. A general rule is to name classes and IDs after their purpose rather than appearance.” And yet above you contradict yourself in saying “Classes and IDs are not subject to semantics.” You had it right the first time–this is one of the fundamentals I alluded to earlier. Sidenote: Your credibility would be stronger if your value system didn’t change to suit each article.

    Style should be separate from content.
    When tying an insemantic class to an element for style purposes only, it becomes style added to content. Sure it’s just a class name, not “technically” content… but it’s living in the content document (HTML) and serves no other purpose than changing the text style. Bad practice. This could easily be avoided by handling styling via the cascade. The way CSS was designed to be used.

    Visual and semantic hierarchy no longer in sync.
    So, you want an H2 to look like an H5? Why not just make it an H5? A typographic hierarchy is only as valuable as it is consistent. Set up a system that works, and stick to it. Sidenote: Taken to the extreme, this method could also be considered a black-hat way of manipulating search engines. Why not make everything an H1, but manipulate the appearance with styles? (I doubt you would advocate this extreme, but I can’t be sure, given the philosophy presented in this article.) Thankfully, google is smart enough to penalize this behavior.

    Trouble with content management.
    What if your client needs a CMS-driven website? Now you need to set up the CMS so users can correctly reproduce the desired style. (Two variables instead of one: 1. The semantic tag, and 2. The insemantic class.) No problem if you are the only one populating content, but what about clients, or an entire company of individuals who have access to the CMS? You are putting design control in the hands of non-designers, who will (I guarantee it) use the wrong combination of tag and class name in the wrong spot, screwing up your page design.

    Unnecessary data being transferred.
    Imagine a large-scale website: thousands or millions of pages, all filled with repetitive extraneous class names. These class names are not being downloaded once. Over their lifespan, they are being downloaded millions of times each. This translates to increased data costs, overworked servers, wasted electricity, increased server maintenance (hard drive replacements, etc.), all paid for by someone other than you. Sidenote: Download time for individuals in first-world countries may not be affected, but what about those using slow connections in developing nations?

    Debt-ridden / less portable markup.
    It’s time to redesign. So, now it’s time to clean out all those class names and replace them with ones that fit the new design. This is a pain even on small websites, but exponentially worse with anything of scale. Oh yeah, don’t forget to re-configure the CMS and re-train all of it’s users.

    Food for thought. Cheers, Keith.

  35. Keith Streble said on 3 March, 2012 at 7:48 am

    Yep, I missed an “s” in “assure”. Calling it out before the spelling police do.

  36. Boromino said on 3 March, 2012 at 11:15 am

    I agree with Keith Streble.

    “it doesn’t depend on location or a type of element.” You don’t use CSS selectors like first-child, nth-child then, do you? Instead you add an extra class for these elements, wright?

  37. Harry Roberts said on 3 March, 2012 at 12:35 pm

    Cheers for the comment, Keith.

    You do make valid points, and this in particular your remarks on Web Design+. I have changed my mind, I have reevaluated my opinion on what makes a decent, sensible build. Our best practices of yesteryear aren’t suitable any more; we were barking up the wrong tree with a lof of the things we used to do.

    However, if you don’t like or agree with the points I outline that’s fine. Don’t use them, I’m not saying everyone will like this, I’m not saying everyone would or should use it. We need write code for ourselves, stick with what you like/are comfortable with :)


  38. Shane Hudson said on 5 March, 2012 at 11:23 am

    I agree that this is a good system, but I am not sure it is the best one. I am going to explore the options, I have been thinking for a while that I need a new system for my own CSS.

    Cindy – While .one and .two would work well, many people always use them for grid systems and the like.

  39. Jacob Rask said on 6 March, 2012 at 2:27 pm

    This approach combined with SASS is neat.

    .sidebar h2 {
    @extend .h4;
    color: orange;

  40. Art Lawry said on 6 March, 2012 at 6:34 pm

    I’m glad Jacob pointed out SASS. Whether you use

    @extend .h2;


    @mixin h2();

    the goal is to maintain semantic markup in the SASS file and not care about the CSS output layout. As Paul Irish would say, keep your original CSS neat and well structured an f*** the generated CSS. You want that code as small as possible anyway.

    @extend may save you a few characters in the long run, but it actually depends on the markup. If your rule is only defining the size, use @extend. If your selector is extremely long, @mixin could actually perform better.

    Unless you’re willing to do the painful math, use whichever you prefer :)

  41. Matt Wilcox said on 12 March, 2012 at 2:34 pm

    Getting back to your font-sizing classes… I like the idea itself but don’t like the practice of putting them in HTML as classes.

    So, what about taking that idea but keeping it server-side using SASS? i.e., create a mixin for each heading style, and in your CSS selectors simply import the appropriate heading mixin. This brings the benefits of a DRY workflow without messing the mark-up.

  42. Musterknabe said on 12 March, 2012 at 6:32 pm

    Keith Streble has nailed it. Sorry to be so blunt, but the article’s approach is shit.
    One more con: If your markup is used by multiple themes/customers you are out of luck with this approach anyway.

    Matt Wilcox has the solution if you want to keep your CSS DRY.

  43. fjpoblam said on 13 March, 2012 at 2:47 pm

    Partially sensible, yet, if used on the website I am now reading, ineffective. It is rigid. I am not allowed to resize the text on this page on my iPad (whereon I am now typing this comment in a very tiny font-size).

  44. Ben said on 15 March, 2012 at 12:30 pm

    Hey Harry,

    Really like this.

    Would you apply this concept to actual element on the page too? e.g. headers, articles etc.

    At the moment if I have multiple headers on the page for example I use the following;



  45. Matt Dryden Dryden said on 23 April, 2012 at 6:32 pm

    Excellent article, Harry. Some very good points you make, I need to really start improving my CSS and this article is a great start.

    Cheers, Matt.

  46. Bart said on 30 April, 2012 at 6:57 pm

    Seems like there is a lot of semantic meaning attached to class names used in microformats.

    If you want complete separation, styles would have to be assigned through XPath-like selectors. This way your HTML would be clear of class attributes, but your CSS would be a lot more complex.

    I’ve always considered the sidebar as a compound module (containing other smaller modules) so to me descendant selectors were OK. The portability of presentation of headings between modules didn’t really matter to me since I’ve grown accustomed to expecting change when the context changes. I never expect h2 to be the same no matter where it is placed. Ex. If I use a testimonial module in main content and one in a sidebar, I’d expect/want the headings to be appropriate for the context they live in. This may be different for CMS authors and new CSS coders. It certainly is a different way of thinking/looking at things.

    Also, I’ve always have to touch the HTML when redesigning. The more extensive the redesign, the more HTML had to be touched.

  47. Larry Botha said on 31 July, 2012 at 1:42 pm

    Podio’s using rems with px fallback…

    Exciting to see great techniques being used in great applications!

Leave a Reply

Respond to Pragmatic, practical font sizing in CSS

Hi there, I am Harry Roberts. I am a 21 year old web developer from the UK. I Tweet and write about web standards, typography, best practices and everything in between. You should browse and search my archives and follow me on Twitter, 7,791 people do.

via Ad Packs