thehappybit's avatar


The Happy Bit
22 Watchers
Page Views
15 Deviations
thehappybit's avatar
Originally posted on

When designing using text, no matter if it's for print or the Web, one vital thing to do is to ensure that the design stays harmonious in every aspect.

The best way to do so is quite possibly using a so called typographic scale, which means giving text portions precise, regular and linear dimensions, based on the hierarchical relationships they hold with other text elements.

This has been long known, of course, and we're not bringing anything new to the cause.

But being the Web one of our domains, we felt like managing the typographic scale in CSS could be done better, and in an easier, sort of automatic, way.

Our goal was to create a base-level CSS that could set a well thought series of values for the typographic scale, hence establishing a vertical rhythm, with absolutely no reference to pixels. Instead, we wanted it to graciously adapt itself when varying the font size declaration of the document's body.

Using ems and percentage we were able to create such base stylesheet, defining the headings (from h6 through h1) and paragraphs main proportions, relying on the body's font-size value, with a pre-defined line-height set at 1.5em.

Proportions are then extracted keeping the value of 14 pixels as the smallest value (paragraph); the biggest value, on the contrary, is 48 pixels, used for the primary level heading.

The scale would degrade as follows, from the biggest element to the smallest:

48, 32, 24, 21, 18, 16, 14

Should we want to get the code for our H1s to be properly styled according to our chosen rhythm, we could write:

paragraph = 14px
line-height = 21px (14px * 1.5)
h1 = 48px
line-height * 3 = 63px

font-size : 48 / 14 = 3,428571429em
line-height : 63 / 48 = 1,3125em

Basic text sizing
Set your main font size for paragraph

62.5%  => 10px
68.8%  => 11px
75%    => 12px
81.3%  => 13px
87.5%  => 14px
100%   => 16px
112.5% => 18px
125%   => 20px
Proportions based on typographic scale
14, 16, 18, 21, 24, 32, 48

body {
font-size: 87.5%;
line-height: 1.5;

h1 {
  font-size: 3.4285714285714284em;
  line-height: 1.3125em;

h2 {
  font-size: 2.2857142857142856em;
  line-height: 1.96875em;

h3 {
  font-size: 1.7142857142857142em;
  line-height: 1.75em;

h4 {
  font-size: 1.5em;
  line-height: 2em;

h5 {
  font-size: 1.2857142857142858em;
  line-height: 2.3333333333333335em;

h6 {
  font-size: 1.1428571428571428em;
  line-height: 2.625em;

p {
    -webkit-hyphens: auto;
    -moz-hyphens: auto;
    hyphens: auto;
    margin-bottom: 1.5em;

Again, the resulting values for line heights are a direct consequence of having set the base line-height at 1.5. In our next article we'll see how's possible to combine LESS and our typographic scale to get an even more flexible base stylesheet for typography.

Articles on the subject:
The typographic scale by
Five simple steps to better typography by Mark Boulton

Suggested lectures:
Elements of Typographic Style – Robert Bringhurst
Join the community to add your comment. Already a deviant? Log In
thehappybit's avatar…

The plugin adds cross-browser support for the HTML5 placeholder attribute functionality.


In order for the plugin to work, insert the following code inside your $(document).ready function:



The plugin comes with two customization options:

'className': 'placeholder',
'attrName': 'placeholder'

The className parameter lets you pick the class which is toggled on the input element that has the placeholder attribute specified.
The attrName parameter lets you choose which attribute to look for. For instance, you could make use of the placeholder functionality using an attribute different than placeholder, eg. data-placeholder.

Download for free from GITHUB
Join the community to add your comment. Already a deviant? Log In
thehappybit's avatar…

As front-end developers, knowing the instruments of our profession is crucial.

As when developing, as in our daily fights with browsers discrepancies, just a little time should be devoted to all of those activities that are repeated, or that can be standardized.

This is also the case with CSS frameworks. There is plenty of them out there, most of them are solid and useable out of the box, none of them will probably satisfy you one hundred percent.

As good as a framework can be, it'll always come up short at suiting your specific needs and it'll likely have to be tweaked a little bit.

One question could then arise: why should't I build my own, then?

In programming, this is a bad practice. If other frameworks, masthodontic in size most of the times, are in place, they'll surely be more solid and mature than your newly born baby will ever be in the short term: reinventing the wheel is always a painful, expensive and unproductive activity.

In CSS front-end development though, this might not be the case.

The existing CSS frameworks are generally pretty light and we know that the industry is fairly young and it is based on a solid set of standards which aren't all defined and carved in stone just yet: in this scenario, no CSS framework has gained a clear edge of advantage over its rivals, nor can it be considered a milestone in the field.

This is why building your own CSS namespace of meaningful class names for repeated tasks such as grid design might not be a bad idea after all.


A good framework should reduce modifications to the structure of the master stylesheet to the very minimum.

Most, if not all, of the frameworks available today limit themselves to adjusting column widths, margins, and horizontal shifts, and only a few more things after that.

Most of them, for example, choose not to implement column containers elements, other than the one that defines the main grid width.
< div class="grid_container" >
  < div class="grid_1" >< /div >
  < div class="grid_2" >< /div >
< /div >

If you're thinking responsively too nowadays, you can instantly grasp the importance of having such elements at disposal, especially when considering about changing margin when a responsive context switch comes into play.

This is something that normally would go in the main stylesheet, but that can actually be left to the framework to deal with; this way, the master CSS would be filled only with the implementations of details, not the structure itself.

Most of today's frameworks force you to base your grid at a fixed amount of pixels, with a predefined set of columns.

The point here is that if you really want your framework to be flexible and useable in the real world, you should be designing it with a single word in your mind, straight from the beginning. That word is modularity.


CSS pre-compilers such as LESS (our choice) or SASS, immensely help the writing of your CSS code, as they enhance the concept of DRY, and allow for code reuse, modularity and a better maintainability throughout time.

The biggest advantage when using CSS pre-compilers, though, is that you can create a dynamic infrastructure, enabling you to define parameters such as grid width and columns number from project to project, reaching a level of flexibility you couldn't when using other frameworks.


The real implicit value of using this kind of approach is that it forces you to actually think about the way you work everyday.

Putting yourself outside the specific problems you may find in your coding routine, allows you to perceive your own workflow more clearly: you can analyze your markup, highlighting the elements most commonly used, and put them in the framework, developing hence your own semantic namespace.

This way, you will not only speed up many tasks, but also produce a better end result, still retaining full control over your markup.
Join the community to add your comment. Already a deviant? Log In

Flexible CSS typographic scale by thehappybit, journal

jQuery HTML5 placeholder plugin by thehappybit, journal

Considerations about css frameworks by thehappybit, journal