Logical Breakpoints For Your Responsive Design

Advertisement

There are several tactics for deciding where to put breakpoints in a responsive design. There is the rusty idea that they should be based on common screen sizes, but this doesn’t scale well. There are no “common” screen sizes. Another popular tactic is to create a breakpoint wherever the layout breaks.

This sounds much better. But it still leaves us with the question, How do you determine whether the layout is broken? One logical answer is to look at classic readability theory and to define our breakpoints based on that.

What Do The Books Say?

According to Robert Bringhurst1, “Anything from 45 to 75 characters is widely regarded as a satisfactory length of line for a single-column page set in a serifed text face in a text size.” And Josef Müller-Brockmann2 writes that, “A column is easy to read if it’s wide enough to accommodate an average of 10 words per line.” A few variables determine the exact number of characters or words, but this is the basic theory: If you start with a small screen and you grow it, every time the width of the main content grows wider than either 75 characters or 10 words, something should happen. Simply said, these are your breakpoints.

Variables That Define The Ideal Measure

Many variables define an ideal measure. For instance, the German language has longer words than English, which could very well result in a wider column. Yes, you read that correctly: you could have different grids based on the languages for international websites. Font, font size, contrast ratio with the background, leading, kerning, type of text, etc. — all of these could result in different lengths of line.

Most importantly, the insights and experience3 of the designer are a major influence on the measure. You might very well decide that a measure between 75 and 90 characters is ideal. But I am not a designer, and I’m not a typographer, so I’ll just stick to the theory that I find in the books I read. Talented people who know what they’re doing are, of course, invited to play with the theory.

The international measure slider4

I created this simple international measure slider5 to give you an idea of how wide a measure can be. (Yes, I know, it’s weird.) This little tool looks only at language and font family, but you’ll see that these two variables alone can lead to some extreme results. Just compare German or Polish with English or, even better, German set in Verdana with English set in Georgia. The difference is huge: 10 German words set in Verdana can be 38.5 ems wide, while 10 English words set in Georgia are just 22 ems wide. In most default browser settings, that would be 616 pixels versus 352 pixels. You see, these two simple factors should have a major impact on the grid.

A good measure is essential for articles. I know that the Web is not just articles. You could very well be working on a Web app with very little text to read. But even then, starting with the measure when defining breakpoints might be a good idea.

A blogpost without any styling6

Our Example

As an example, I’ll be using a simple blog post. It’s a structured but simple article, with some common semantic elements in it. These elements are not necessary to define the breakpoints, but I think they might help; typography can be a logical starting point. I’ve left out the header and logo — let’s concentrate on the content first.

Of course, if you open this unstyled article7 in a browser, it will look ugly. There is no styling except for the default styling that the browser uses for the elements in the article. The text is as wide as the browser, which is probably too wide on a desktop. This could very well be what someone on IE 6 sees — a somewhat accessible article with rudimentary styling.

By adding just some basic typographic styling and a max-width attribute, the article immediately looks much better8. This page can now serve as a starting point to define all of the different responsive grids. This single column probably needs some adjustment for small screens9, and on wider screens10 we should probably add some columns, either to make things prettier or to show more information such as navigation or asides.

Some simple styling makes this article much more accessible11

Logical Breakpoints

I never paid attention in maths class before dropping out of high school a long time ago, so I’ll stick to a very simple grid that even I understand. Smarter people could probably use these same ideas for more complex grid systems. This article is about defining breakpoints; what you do with them is entirely up to you.

Small Screens

I’ll start with the small screen. One theory of Oliver Reichenstein12, a theory I really like, is that font size doesn’t depend on screen size; it depends on the distance between our eyes and the device we’re using. We tend to hold our phones closer to our head than our laptops, so this might warrant smaller fonts. The other theory of Robert Bringhurst, as explained above, is that an ideal measure should probably not be smaller than 45 characters. In our case, where we use a 16-pixel Georgia as the default font size, this would result in a slightly smaller font size. Both theories are fine, and they both tell us to reduce the font size on small screens. So, all of the code we’d need for small screens is this:

@media (max-width: 22em) {
   body {
      font-size: .9em;
      padding: 0 1.5em;
    }
}

This says that whenever the measure is smaller than 45 characters (according to our tool), show a smaller font size. I also reduced the padding on the body to create a bit more space for the content. See the example right here13.

Some adjusted styling for an smaller screen14

Big Screens

Sometimes, a single column is enough. Content-focused websites, such as blogs, could very well do with a one-column layout. But multiple columns on big screens are actually a good idea in many situations. You might want to show some navigation, or perhaps you’ve found some widgets that actually make sense. You could very well choose to show these next to the main content.

But you could do other things as well. For instance, right at the point where there is room for an extra column, we could play with the layout of our article. I added a 33%-wide column15 to the left, filled with the heading and the first paragraph of the article. Other elements, such as block quotes and images, could fill this gap as well.

The code gets a bit more complex here. And this is definitely not the only way, or the most maintainable way, to create a layout like this. But this is how I did it.

@media (min-width: 34em) {
   body {
      max-width: 51em;
   }

   article {
      width: 66.66666%;
      margin: 0 0 0 33.333333%;
   }

   h1, h1 + p {
      margin: 1em 0 1em -50%;
   }

/* And some font-size adjustments */
}

When the screen is wider than 34 ems (30 ems for the content and 4 ems for the margin), the maximum width of the body is increased to 51 ems: 34 + (34 ÷ 2). The article should now be two thirds of the total width, and the new column on the left should be one third. The h1 and p right after it should have a negative margin of one half the width of the content. This is where I really cursed myself for not paying attention in maths class!

On even wider screens we could show relevant content in the right margin16

Even Bigger Screens

We could add a third column, and a fourth and a fifth. We could also decide that we’re done. It all depends on the content. We could use that space to show some images or some relevant content. It’s really up to you and depends on the thing you’re creating. In our case, we could show the footnote to the right17 of the content. Now, stop laughing! I told you, I am not a designer! Here is the code for that work of art:

@media (min-width: 51em) {
   body {
      max-width: 68em;
   }

   article {
      width: 50%;
      margin: 0 25%;
      position: relative;
   }

   h1, h1 + p {
      margin: 1em 0 1em -50%;
   }

   .sidenote {
      position: absolute;
      right: -50%;
      width: calc(50% - 2em);
      font-size: .9em;
   }
}

The article is now 50% wide and has 25% of margin to the left and to the right. The side note is placed 50% to the right, outside of the content. It is 50% wide, minus 2 ems for good looks. The code for the h1 and p did not change. Note that calc does not yet work in all browsers18, so a fallback is needed. The real code for the width bit looks like this:

width: 45%;
width: -webkit-calc(50% - 2em);
width: -moz-calc(50% - 2em);
width: -ms-calc(50% - 2em);
width: -o-calc(50% - 2em);
width: calc(50% - 2em);

Yes, I know that not all of these prefixes are necessary, but I prefer to use them all, always. The other option is to remember by heart which CSS feature is supported by which browser, with or without prefixes. If I understand the cascade correctly, this is perfectly harmless. And besides, it looks good. I can clearly see that cool stuff is going on in this part of my style sheet by the pattern that it generates.

So, this is it. Here we have a responsive website, based on font size and measure19. The breakpoints are based on a logical unit, not on some random units like the screen sizes of devices that are in vogue right now. This scales — into the future and in the browsers of your users. Because everything is based on font size, it all responds to the preferences of the person visiting your website. The layout does not break when the font size of the browser is increased. On the contrary.

responsive-500px20
Breakpoints are not based on some random units like the screen sizes of devices.

Technically

When we started with responsive design a few years ago, we created a desktop website first and then added media queries for smaller screens, overwriting the styles for the desktop version. We found out that that’s not the right way to work. We all know by now that the best way to set up CSS is by starting with a small screen first. After all, growing is easy — trees grow, babies grow — and shrinking is hard. Ever tried to compress a car? It’s possible to a certain extent, but also very hard.

In most cases, starting with a small screen is a logical thing to do. As we make things bigger, we only need to add some media queries every now and then to adjust the layout for bigger screens. But I think it’s not really about small screens — it’s about defaults.

Defaults First

The first thing we need to define is not necessarily the styles for a small screen, but the defaults: the styles that are used throughout the website, regardless of screen size. These are things like the relationships between font sizes, white space and brand-related styles like borders and backgrounds. These styles should not be inside a media query because they are used everywhere. What we want to define in media queries are the exceptions (like a smaller font size) or additions (like grids) to these basic styles.

This could very well mean that we have to use a media query for small screens only if a certain element behaves differently. When you think about it, this happens a lot: page headers, navigation and other complex components are often radically different on small screens. It makes sense to put the code for these components in a @media (max-width) query, as I did in the example, because it’s an exception to the default.

Some Final Details

The example I showed you is very basic, and I did not explain many details. Two of them are rather important, so I’ll add them here. One is about using ems for media queries, and the other is about breakpoints.

Break Ranges

There has been some discussion lately about the term “breakpoints.” Mark Boulton21 and Ben Callahan think22 we should call them “optimization points,” and Jeremy Keith distinguishes between breakpoints and “tweakpoints.”23 In this article, I’ve been focusing on breakpoints — i.e. major changes in the layout when the content asks for more or less space. And now I introduce yet another term: break ranges.

We use the term “breakpoints” for media queries that make the layout completely different. We tend to use them as direct changes: when a layout reaches its maximum width, we immediately switch to the next layout. Waiting a while and adding some white space first before switching is often better. For instance, the switch between the one- and two-column layouts results in a rather small main column. Instead of switching at the exact moment that the content reaches its maximum width, we could just wait a while, as I did here24. This is a very simple trick to never break the layout.

Ems in Media Queries

Using ems in media queries can be weird. You might assume that they respond to the font size specified in the CSS, but they don’t. They react to the font size of the browser that the visitor is using. This is actually logical when you think about it. If they reacted to the font size in the CSS, you could actually disable a media query from within a media query by increasing the font size. This piece of code would create an endless loop:

html {
   font-size: 100%;
}

@media (min-width: 20em) {
   html {
      font-size: 200%;
   }
}

If the media query reacted to the font size defined in the style sheet, then what would happen as we slowly increased the width of the browser? As soon as the screen got wider than 20 ems, the font size would grow twice as big. This means that the width of the page would now be 10 ems, which would mean that the browser should now ignore the media query. This would result in the smaller font size, which would immediately trigger the media query again. That’s an endless loop.

But it’s logical not only from a technical perspective, but from the user’s perspective: If the user prefers a bigger font, then the layout would always be optimized in a way that’s relative to the font size. And that’s what we’ve been doing here all along. At the same time, it can also become a pretty big mess for people like me who should have paid attention in high school: The ems that the media query uses could have a completely different size than the ems inside it. This is complex. If you want to learn more about this, definitely read Lyza Gardner’s classic article on the subject, “The Ems Have It: Proportional Media Queries FTW!25.”

One thing that really bugs me is that we need a silly tool to estimate the number of characters on a line. WebKit has only now implemented the “ch” unit into its nightly builds; it will probably take some time before we can actively use it. One ch is the actual width of the 0 (zero) of the font in use. It sounds like an incredibly useful unit for responsive design, but I’m not sure how it will work with media queries. We’ll see.

Conclusion

In an ideal situation, the different grids for the various screen sizes would be defined by the content alone. There are, of course, situations in which other elements, such as banners, would more heavily define the width of the content. Even in these situations, readability theory might help; you could increase or decrease the font size of the body copy in order to stay within the margins of an ideal line width. Just don’t make the text too small — people want to read it.

Fortunately, in most other situations, classic typographic theory can help you determine the right breakpoints for your responsive website. You could even go so far as to create different layouts for different languages. When you’re working on large international websites, this might actually be a good idea. Most importantly, use the theory in this article to better design your content for all different screen sizes, on both current and future gadgets. The example I’ve shown uses a very simple grid, but in combination with more complex grids26, this theory can help to create wonderful, and logical, websites.

(al)

Footnotes

  1. 1 http://en.wikipedia.org/wiki/The_Elements_of_Typographic_Style
  2. 2 http://www.amazon.com/Systems-Graphic-Systeme-Visuele-Gestaltung/dp/3721201450
  3. 3 http://www.smashingmagazine.com/2013/02/18/designing-reading-experience/
  4. 4 http://nerd.vasilis.nl/code/measure-help/
  5. 5 http://nerd.vasilis.nl/code/measure-help/
  6. 6 http://nerd.vasilis.nl/code/smashing/typo-grid/step1.html
  7. 7 http://nerd.vasilis.nl/code/smashing/typo-grid/step1.html
  8. 8 http://nerd.vasilis.nl/code/smashing/typo-grid/step2.html
  9. 9 http://responsivepx.com/?nerd.vasilis.nl/code/smashing/typo-grid%2Fstep2.html#340x480&scrollbars
  10. 10 http://responsivepx.com/?nerd.vasilis.nl/code/smashing/typo-grid%2Fstep2.html#800x800&scrollbars
  11. 11 http://nerd.vasilis.nl/code/smashing/typo-grid/step2.html
  12. 12 http://informationarchitects.net/blog/responsive-typography-the-basics/
  13. 13 http://nerd.vasilis.nl/code/smashing/typo-grid/step3.html
  14. 14 http://nerd.vasilis.nl/code/smashing/typo-grid/step3.html
  15. 15 http://nerd.vasilis.nl/code/smashing/typo-grid/step4.html
  16. 16 http://nerd.vasilis.nl/code/smashing/typo-grid/step5.html
  17. 17 http://nerd.vasilis.nl/code/smashing/typo-grid/step5.html
  18. 18 http://caniuse.com/#feat=calc
  19. 19 http://nerd.vasilis.nl/code/smashing/typo-grid/step5.html
  20. 20 http://www.smashingmagazine.com/wp-content/uploads/2013/03/responsive-500px.png
  21. 21 http://www.markboulton.co.uk/journal/theinbetween
  22. 22 http://seesparkbox.com/foundry/there_is_no_breakpoint
  23. 23 http://adactio.com/journal/6044/
  24. 24 http://nerd.vasilis.nl/code/smashing/typo-grid/step6.html
  25. 25 http://blog.cloudfour.com/the-ems-have-it-proportional-media-queries-ftw/
  26. 26 https://gridsetapp.com/

↑ Back to topShare on Twitter

Vasilis van Gemert is the Principal Front-end Developer at Mirabeau in The Netherlands and a board member of Fronteers. His aim is to close the gap between design and (front-end) development. He believes the excess of knowledge he has can be better used by others, by more creative and smarter people. You can follow him on Twitter.

Advertising
  1. 1

    Mad response on twitter for this post, I could hardly click a link to come here! must have been 5 a second for search “responsive” Well done.

    4
  2. 2

    “The other option is to remember by heart which CSS feature is supported by which browser, with or without prefixes.” …or simply write a mixing in SCSS or LESS or use a snippet manager like DASH but of course that’s totally up to you.

    More importantly: Thanks for the great article, really freshens up my library. (Why won’t those bookmarks sort themselves!)

    7
  3. 3

    Kenneth Bernholm

    March 2, 2013 7:52 am

    So many articles on web design are based on the idea that content is a big body of text supported by sidebars and menus. Maybe this is because text is easy to scale according to screen size, but a lot of real life websites do not have large bodies of text.

    Most of my web work is forms, maps, images and interactive functions. I have to present user friendly access to huge datasets over limited bandwidth. My users needs to navigate several layers of data with a minimum of clicks and without getting lost. And most importantly they require fine grained access privileges combined with fast and easy navigation from one function to another.

    Because my websites and webapps are used on all types of devices from small smartphones to large desktop screens, I use responsive design but without breakpoints. Forms and functions quickly becomes squashed or stretched beyond acceptable bounds when breakpoints defines screen size but not resolution.

    Instead I base everything (and I mean *everything*) on rem and two simple media queries:
    In landscape mode I set the page to minimum 50 percent width and maximum 75 percent width. In portrait mode I just set the page to a minimum of 95 percent width.

    This is not perfect, but it’s simple (KISS, you know) and the result is acceptable on all screen sizes.

    20
    • 4

      A very good point. Whilst this is a good article, I also believe the example is too simple for real world purposes. Many web layouts are far more complicated than the content-centric classic “blog” example shown here.

      7
      • 5

        > Many web layouts are far more complicated..
        But there are a huge number of news-articles-gathering sites that exactly fits classic blog layout. For more comlicated apps in a first approximation can be used sliced layout.

        6
  4. 6

    Great write up; been looking for some solid documentation on breakpoints.

    Interesting point on including language based responses. Never considered that.

    10
    • 7

      Vasilis van Gemert

      March 3, 2013 9:30 pm

      Thanks! I’m not sure if you should use different layouts for different languages, but it’s definitely something you could consider.

      -3
  5. 8

    GREAT ARTICLE! I think anyone that does anything for web should read this! …

    3
  6. 10

    THOMAS UNTERSTENHOEFER

    March 3, 2013 3:37 pm

    Thanks Vasilis for this interesting information. As a newbie to the blogosphere focussing just on the contents of my blogs your analysis was really depressing for me. I will never reach this level of perfection when creating articles.
    On the other hand I see many articles in magazines and even on websites of bloggers that use a perfect design but the contents weakens slightly.
    Thanks again. Your contribution raises my awareness for a more intense engagement with layouts.

    1
  7. 11

    THOMAS UNTERSTENHOEFER

    March 3, 2013 3:54 pm

    Thanks Vasilis for this interesting information. As a newbie to the blogosphere focussing just on the contents of my blogs your analysis was really depressing for me. I will never reach this level of perfection when creating articles.
    On the other hand I see many articles in magazines and even on websites of bloggers that use a perfect design but the contents weakens slightly.
    Thanks again. Your contribution raises my awareness for a more intense engagement with layouts. However I see a big problem in presenting the same article on a PC, a Tablet, and a Smartphone.

    I’m sorry. I tried to comment on my iPhone but that didn’t work.
    So I moved over to my iPad. Maybe there is a duplicate copy now.

    2
    • 12

      Vasilis van Gemert

      March 3, 2013 9:27 pm

      You shouldn’t compare the things you write on your blog to this article. This article was reviewed by professional editors and I updated it a few times before it was published. And apart from that: a while ago I was a newbie too. Keep writing, keep asking for feedback and in a few years (or faster, why not) you’ll publish here too.

      The point you make about presenting the article on different devices is a good one. Especially the example: you can’t view the layouts for wider screens on a device with a small screen. And the tool probably doesn’t work there either. That’s why I added some screenshots of these layouts to the article, so at least you can see what it looks like.

      2
  8. 13

    Have you considered rolling out other languages for this tool?
    I reckon it would be a really good tool for Asian languages like Japanese, Chinese, Arabic, Tamil (and all the South Asian languages) and even Northern European languages like Russian etc..

    Would your current tool now be able to extend for R-L languages too? Just curious. :)

    0
    • 14

      Vasilis van Gemert

      March 4, 2013 10:44 am

      I have considered extending it to other languages. But I used a text from a Dutch website that was translated to just these languages. But apart from that, I am not sure if the same typographic rules apply to all different alphabets.

      But I should probably put the tool up on Github so others can easily extend and improve it.

      4
      • 15

        Yeap! I would be more than willing to contribute Malay translations for this :D

        Do keep us updated when you get on .git. :)

        1
  9. 16

    Lucky Balaraman

    March 4, 2013 12:31 pm

    Discrete breakpoints make me think of… Newton.

    When he was figuring out integral calculus, he approximated the area under a curve as the sum of a series of rectangles… then decided to make those rectangles have infinitesimally small widths for the best results.

    Likewise, I’m thinking (even though I’m less than a slug compared to the brilliant Isaac) why not have a breakpoint at every em of media width?

    1
    • 17

      Because you’d end up with a massive bundle of media queries and a huge css file size for no real benefit. If you want to see a creative use of a very similar thing though go to http://arleym.com/ and resize the window slowly.

      4
  10. 18

    I really agree with the concept of using measure as the starting point for a design. For a very long time, the “fluid width” content area was the most stupid, most cherished and least questioned pattern in website design, and, noteably, Wikipedia still uses this abomination.

    It makes me cringe though, when you write “[…] on wider screens we should probably add some columns […]”. This is very backwards reasoning in my opinion.

    Consider the following two definitions of a (seemingly) related problem:

    1. “We have some free space here. What should we fill it with?”

    2. “We have this critical interface element. Where should we put it?”

    We need to be careful of how we approach a project, or risk it turning into a bad case of feature creep.

    Those are my 5 cents. Thanks for a great article!

    2
    • 19

      Vasilis van Gemert

      March 4, 2013 8:22 pm

      Thanks for the compliment. And I totally agree with you. I had to look up the sentence you’re quoting because it doesn’t sound like me at all. You forgot to quote the rest of the sentence which goes like this: “…either to make things prettier or to show more information such as navigation or asides”.

      I love free space and I never understood widgets. I don’t think we should fill up the empty space with crap, I think we can use it for either some very useful stuff, or to make the content stand out even better. We definitely agree on that, I probably should have chosen my words more carefully on that point…

      4
  11. 20

    Vasilis,

    I am impressed to say the least. I have been working with responsive designs for a while now; using em’s in the media query did not dawn on me until reading your article.

    I certainly appreciate your little language measuring tool: that is a clever piece of code.

    I am going to start experimenting with this approach; thank you for writing such a detailed article.

    0
  12. 22

    Really interesting article Vasilis. Thanks!
    What are your thoughts on responsive layouts for content that is image-heavy? What do you think the best solution is?

    0
    • 23

      Vasilis van Gemert

      March 4, 2013 8:29 pm

      Thanks for the compliment, Susan. As to your question, I really wouldn’t know. It totally depends on what kind of images you want to show. If one image is the content you might want to try to show the image as full-screen as possible. If a series of images is the content, you might want to present them in columns, based on a percentage of the width of the viewport. If the content consists of a series of images with a caption or a small article you might consider using the measure of the text to define the breakpoints. But there are many more options here, these are just the first things that pop to mind.

      2
  13. 24

    Very inspiring, thank for this small masterpiece, Vasilis. I’m playing with the ideas you exposed straight away.

    As a note, I would appreciate a few more sources and links to go further on the same topic. But, so far, you already triggered a small revolution in my code and css ;) Thanks!

    1
  14. 25

    As much as I agree with the concept of your article, you must understand one undeniable and unchanging fact: PEOPLE USE MOBILE DEVICES!!! Once we can all accept this fact it makes the

    And not all devices are going to be as popular as others. Some devices are going to carry more sway than others e.g. iPad and Kindle market share is very significant and doesn’t really expose you to that many breakpoints, but of course media queries is not robust enough to deal with device form factors.

    I feel that a lot of frustration stems from the fact that CSS media queries is not as robust a solution for Responsive Design as we would all like, so there seems to be a push to “Blur the Breakpoints” and reduce the bloat brought about by the extreme fiddling that media queries forces you to do. Nothing wrong with this but it’s not very realistic given the sheer variety and complexity of web apps that need to work well across various devices.

    I’m launching a JQuery Plugin for Responsive Design this month that I believe will help designers and developers use breakpoints with way more power and flexibility and less code.

    People Use Devices AND Content has to Look Good on these Devices. Until we have web standards that are designed to cope with the variety of devices out there, it’s going to be a while before we can get past the hacks that are breakpoints.

    1
  15. 26

    Smashing Magazine’s own responsiveness has much to be desired. Change your browser size from small to large and you’ll see the menu flip from the left to top to left to not-so-left at different sizes. And why does the search box blow up huge at a certain range. Responsive is not only about appearance at fixed device sizes but also the transition between sizes in a browser.

    1
    • 27

      Dominor Novus

      May 8, 2013 8:39 pm

      I feel the logo should be replaced rather than scaled. The smallest logo size looks pixelated.

      0
  16. 28

    You really make it seem so easy with your presentation but I find this topic to be actually

    something that I think I would never understand. It seems too complicated and very broad for

    me. I’m looking forward for your next post, I’ll try to get the hang of it!

    -3
  17. 29

    Excellent article – well organized, clear and concise, with great examples. Keep up the great work!

    0
  18. 30

    Don’t use pluralise abbreviated measurements.

    1em, 2em, 3em is correct

    1em, 2ems, 3ems is wrong!

    3ems = 3 em seconds (which is meaningless)

    similarly;
    1m = 1 meter
    1ms = 1millisecond

    lets do things the right way :)

    -2
    • 31

      I’ll rise to this!

      Ems are not an abbreviation, it literally means the width of the letter M, its not an E.M. it’s an em.

      1
  19. 32

    some very interesting posts here.. it wd be swell if u could add a font size (in %) to your slider so we could compare different em sizes for the variations (assuming base font size has been left @ 16px – default):) Since (base) screen, etc em’s are calculated by the base copy size (set in body{ } ) starting from 16px(default on all browsers), this is crucial in understanding how em’s affect everything else – use pxtoem to convert to appropriate em’s for break points. (Base) Em screen breaks are only proportional to the base font size u set in your body tag (set in % of course).

    The body font size is the root of em calculations – be it device/page, they all get it from there. Just my 2 cents.

    0
  20. 33

    There seems to be very few sites (including this one) that have an average of ten words per line – the average seems much higher.

    From a readability standpoint is there also a rule for higher word per line averages – like readability dramatically decreases in English over 16 words per line or something similar?

    0
  21. 34

    Great points. However, who’s “We”???

    “We found out that that’s not the right way to work. We all know by now that the best way to set up CSS is by starting with a small screen first.”

    Umm No. “We all” know that there is more than one way to skin a cat. “We” also know there are multiple creative solutions for various problems… not just one writers opinion of THE best way. “We” find that it is a bit presumptuous to think one has landed upon the one right way to do things.

    0
    • 35

      “Mobile First” has become a pretty common mantra in web development. That common opinion is the “we” he’s refering to. So its a valid presumption to make. Starting from small and simple and building up from there has so many benifits. I mean it’s a physical law really!

      0

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

↑ Back to top