11 comments

  • Peiran TanPeiran Tan, 7 years ago

    1. Web Typography is not broken. We simply had limited support.

    2. Fix your straight quote in the huge headline first.

    1 point
  • Thomas Bredin-Grey, 7 years ago

    Bit of a summary: There is little concept of the typographic baseline on the web — but maybe we can correct for it. In this post I've explored a number of vertical rhythm systems and writings that have influenced how we set type on the web. It's clear that there's a disparity between the way designers set type and the way browsers render text — so I'd like to introduce our solution — a new open source tool we've named MegaType.

    1 point
    • Simon LarocheSimon Laroche, 7 years ago

      I still don't understand the need for an overly complicated system. Why is there breakpoint support at all?

      2 points
      • Thomas Bredin-Grey, 7 years ago (edited 7 years ago )

        Hey Simon! Long story short: if we want to redefine a baseline grid at wider breakpoints then we have to store/retrieve/provide some information about the size of the grid at that width; otherwise it is impossible to calculate an offset that will put the type correctly on the baseline. I was really keen to make the system as simple as possible, but there really isn't a way to do it without knowing a minimal set of information about the type at a given size, which is why we kept a map of breakpoint information (the alternative is to provide it when calling the mixin; which is more prone to errors). Thanks for reading, hope this sheds some light :)

        3 points
        • Simon LarocheSimon Laroche, 7 years ago

          Couldn't you just call the function again that resets the old values and makes new ones for that breakpoint?

          Btw, I loved the article, I've also been searching for a great way to do this programatically, and to do it properly not like all the ones out there now.

          0 points
          • Thomas Bredin-Grey, 7 years ago (edited 7 years ago )

            You would just have to feed in some extra information about the rootsize, that's all. Prefer to set that in a config because then it's one less thing to remember when inputting values into a mixin (and if you get it wrong, your type wouldn't be set right!). However if you have a static rather than responsive baseline grid then breakpoints aren't needed at all

            0 points
    • Julian LengfelderJulian Lengfelder, 7 years ago (edited 7 years ago )

      I would like to give this a try, but as I mostly work with rem and em for most of my sizings and fonts – I need to know: How flexible is this when working with those units? Sorry if I missed info about this in your post.

      1 point
      • Thomas Bredin-Grey, 7 years ago

        All the parameters in the typeset mixin can accept rems, and it's all output as rems too! The only place where pixels are needed is when setting your rootsizes; which are output as a percentage on the html element (best practise for working with rems)

        1 point
  • Terry OTerry O, 7 years ago (edited 7 years ago )

    I can't help but feel this is overkill, to the point of anal retentiveness. Even with just a few simple defaults in place type on the web can be perfectly sufficient, even beautiful. The only people who are going to notice anything (if at all) are other type-nuts, who are rarely the target audience. It's nice to get concerned about the details now and again, but the sooner you get comfortable with not having total control (a la print design), the better.

    0 points
    • Peiran TanPeiran Tan, 7 years ago

      LOL even with print you don’t have total control (budget, client issues, font licensing, print factory to work with)

      1 point
    • Thomas Bredin-Grey, 7 years ago

      Hey Terry, thanks for reading! I think details like this are akin to the effect of many design elements we utilise; they all just add up to have a desired effect. In this case, it's less something people notice directly in that they'll say "the typographic rhythm looked great"; rather they've said things like "the reading experience was a breeze" or "I found it really easy to scan that article". Type rhythm just improves readability and hierarchy, aiding the user in easily digesting content (especially long editorial content). The way text is rendered in browsers means the current state of tooling is quite tricky, and I don't think any of the approaches I've explored are perfect — Ideally I feel like it'd be awesome to get a native browser property to tinker with — something that would let us toggle the way text is treated in the browser, similar to how box-sizing works for the box model, perhaps. type-sizing: leading | cap-height; could be useful...

      1 point