{
  "$type": "site.standard.document",
  "content": {
    "$type": "site.standard.content.markdown",
    "text": "Pixels are an [absolute unit](https://developer.mozilla.org/en-US/docs/Learn/CSS/Building_blocks/Values_and_units#absolute_length_units), they are expected to represent a fixed size and aren’t affected by outside factors ([sort of](https://www.smashingmagazine.com/2021/07/css-absolute-units/)). While this sounds like a good thing for design because you can be sure of the dimensions, the reality is that using pixel values in the web hinders user experience. Layouts become unresponsive, translated content becomes unreadable, and accessibility preferences just aren’t considered. In most cases, we want to avoid absolute units and instead use something more flexible that adapts to the needs of the layout.\n\nRelative units are *related* to something else. An example of a relative unit is percentage and relates to different properties based on where it is used. The `rem` is a relative unit which roughly represents the size of the letter “M” in the document. If the document `font-size` changes, all areas where this unit is used will also change. The root `font-size` can change based on user preference; usually increasing to help folks with vision impairment. There is a [not insignificant amount of the population](https://medium.com/@vamptvo/pixels-vs-ems-users-do-change-font-size-5cfb20831773) who leverage the ability to change the `font-size` in user settings so we want to ensure this feature of the web is maintained in our experiences. [It’s possible to check this out for yourself.](https://brokul.dev/detecting-the-default-browser-font-size-in-javascript)\n\n## Hocus pocus\n\nThere was [a trick by Richard Rutter](https://clagnut.com/blog/348/) discovered many years ago which was meant to help folks better understand relative font-size units when coming from pixels. The trick is to set the `font-size` of the document to `62.5%`.\n\n```\nhtml {\n    font-size: 62.5%;\n}\n```\n\nIt’s important to know that when this trick was discovered, we didn’t have `rem` units at all. The trick was attempting to solve for `em` units. These units are scoped to the parent `font-size` which can change at any time. So trying to get all of the sizes to behave is a nightmare. Luckily `rem` can only be changed in one place.\n\nThe `62.5%` *looks like* what we like to call a [magic number](https://css-tricks.com/magic-numbers-in-css/); it seems oddly specific. The number is the ratio 10:16 as a percent. The default `rem` is 16 pixels, so 1/16th of a `rem` equals one pixel. Multiplying by 10 helps keep the font size *somewhat* readable (`6.25%` is too small, `625%` too large). Then the final use of this declaration allows for the following:\n\n```\nbutton {\n    padding: .8rem 1.6rem; /* 8px 16px */\n}\n```\n\nHere, it is possible to write `rem` in terms of pixels. This provides [the benefits of `rem`](https://uxdesign.cc/why-designers-should-move-from-px-to-rem-and-how-to-do-that-in-figma-c0ea23e07a15) while maintaining a pixel mental model. [This post by Aleksandr Hovhannisyan](https://www.aleksandrhovhannisyan.com/blog/62-5-percent-font-size-trick/) goes into the approach in more detail also mentioning accessibility considerations. Some design systems (eg., [Workbench by Gusto](https://workbench.gusto.com/getting-started/engineers/#css-resets)) use the approach to make it “easier” to work with `rem` units. So what is so difficult that warrants this approach?\n\nThe fact is that the `rem` doesn’t exist in design tools, so a **translation from pixels to `rem` must occur** for an inclusive web experience. Before this approach, designers and engineers would need to figure out what the final `rem` number should be based on a formula. Then they would potentially need to repeat that formula every time a new size was needed. In other words, [math is hard and to repeat that math is a waste of time](https://www.editorx.com/shaping-design/article/font-size). It is “easier” for the translation to occur once globally.\n\nSo why would [Jeremy Keith](https://adactio.com/) say the following about the author and the approach nearly 20 years later?\n\n> Not that he—or anyone else—would recommend it these days!\n> \n> — [Jeremy Keith](https://twitter.com/adactio/status/1523743519034200067)\n\n## Absolutely arbitrary font-size\n\n[Toheeb Ogunbiyi](https://twitter.com/toheebdotcom) does a deep dive into the `62.5%` approach and has some opinions about thinking in pixels:\n\n> Thinking in pixels makes it easy to do the following:\n> \n> -   Translate UI Design to code.\n> -   Read the code in the editor.\n> -   Troubleshoot the code in the browser.\n> \n> This ensures a better development experience. In addition, the mental model is maintained across the team.\n> \n> — [Toheeb Ogunbiyi](https://www.toheeb.com/on/62.5-font-size-trick/)\n\nWhat if I said that mental model being maintained is baseless artifact of legacy computer graphic design? 😱\n\nWhen you select a pixel font-size, what does it mean? More specifically, what is the difference between [Courier](https://en.wikipedia.org/wiki/Courier_\\(typeface\\)) and [Verdana](https://en.wikipedia.org/wiki/Verdana) at `16px`? In practice it’s meant to represent [the `em` square](https://typography.guru/term/em-square-r46). In the harsh reality, [it doesn’t really mean anything](https://graphicdesign.stackexchange.com/questions/4035/what-does-the-size-of-the-font-translate-to-exactly). That means we could use 16 pigs, or 1 barn, maybe 8 tulips to talk about `font-size` if design tools were prepared to use these units. It actually doesn’t matter as long as the visual result is expected. That’s what we are really doing when curating `font-size`. We are tweaking some input and assessing the visual output. When we get something that Looks Good™, we record what the tool says in the input to repeat the visual style in digital media elsewhere.\n\nSo why do we need to use the pixel value so much? It’s because that’s what design tools have decided to use to define the `font-size` among other computer graphic properties. If the design tool was to include the `rem` as an option, we would have a 1:1 relationship between the design expectation and the engineering execution and no need to require this translation at all! You could speak in terms of `rem` right in the tool; no math required. The [design tools are the problem](https://twitter.com/SaraSoueidan/status/1619640486305869824) and this “solution” is a community hack for a missing feature.\n\n## Subverting expectations\n\nWhen the `font-size` value is redefined at the `html` element, the representation of the `rem` is changed for the *entire document*. This means that third-party elements could look incorrect; designed with the `rem` to expect the browser `16px` default. This even includes usage of `rem` in the [Shadow DOM](https://blog.openreplay.com/shadow-dom--the-ultimate-guide/). [Josh W. Comeau](https://www.twitter.com/joshwcomeau) calls this out:\n\n> There’s a baseline assumption on the web that `1rem` will produce readable text. I don’t wanna mess with that assumption.\n> \n> — [Josh W. Comeau](https://www.joshwcomeau.com/css/surprising-truth-about-pixels-and-accessibility/#the-sixtwofive-trick-13)\n\nHe also mentions that adoption is difficult because it would need to be done all at once. There’s no possibility of incremental enhancement. This also means that deprecating the approach is also troublesome. So you need to be very sure in this decision, more than most others.\n\n## Back to base\n\nSo instead of thinking in terms of pixels for font size, think in terms of a base (or root) size. What is the font size that is most used in the document? This is most likely your body copy. That should be what the `rem` represents and exist as the base. Next, any `font-size` that you want to set past this should be some proportion from the base. How much larger do you want the headline to be from the base? 1.5x larger? 2x larger? 2.5x larger? Guess what, that’s `rem`! If you’ve set your headline to be 2.5x times larger than the base, that’s `2.5rem`.\n\n```\nh1 {\n    font-size: 2.5rem; /* 2.5x times larger than your base (root) font-size */\n}\n```\n\nIf the user zooms the content, that relationship is maintained. This is what [Andrés Galante](https://twitter.com/andresgalante) says in his article [“Accessible Font Sizing, Explained”](https://css-tricks.com/accessible-font-sizing-explained/) at CSS-Tricks:\n\n> Think about proportions, not size\n> \n> — [Andrés Galante](https://css-tricks.com/accessible-font-sizing-explained/#aa-think-about-proportions-not-size)\n\nWhile it’s recommended to *not* update the `font-size` at `html` and maintain the default expectations, setting the size here [isn’t all bad](https://taupecat.com/blog/2013/07/17/the-62-5-solution/) as long as it’s made accessible. Just recognize that it does affect *all* use of `rem` throughout the page where this rule is applied. So reverting this approach later is an exercise of auditing all pages where `rem` is used and updating the values where appropriate. For large applications and systems, this could be a monumental task. However, if you’ve kept in mind that the `rem` is relating to the `font-size` in the usage, it might not be a difficult change. It might even be a feature of the approach. Though, if you use `rem` as just another unit because someone said it’s better without understanding why, you might end up fighting `rem`.\n\nDon’t dislike `rem` because you don’t understand it, dislike pixels because you do.",
    "version": "1.0"
  },
  "description": "Humans don't like math so we use math to make the math easier, but at what cost?",
  "path": "/posts/62-5",
  "publishedAt": "2023-01-30T00:00:00.000Z",
  "site": "https://blog.damato.design",
  "tags": [
    "typography",
    "css"
  ],
  "textContent": "Pixels are an absolute unit, they are expected to represent a fixed size and aren’t affected by outside factors (sort of). While this sounds like a good thing for design because you can be sure of the dimensions, the reality is that using pixel values in the web hinders user experience. Layouts become unresponsive, translated content becomes unreadable, and accessibility preferences just aren’t considered. In most cases, we want to avoid absolute units and instead use something more flexible that adapts to the needs of the layout.\n\nRelative units are related to something else. An example of a relative unit is percentage and relates to different properties based on where it is used. The  is a relative unit which roughly represents the size of the letter “M” in the document. If the document  changes, all areas where this unit is used will also change. The root  can change based on user preference; usually increasing to help folks with vision impairment. There is a not insignificant amount of the population who leverage the ability to change the  in user settings so we want to ensure this feature of the web is maintained in our experiences. It’s possible to check this out for yourself.\n\nHocus pocus\n\nThere was a trick by Richard Rutter discovered many years ago which was meant to help folks better understand relative font-size units when coming from pixels. The trick is to set the  of the document to .\n\nIt’s important to know that when this trick was discovered, we didn’t have  units at all. The trick was attempting to solve for  units. These units are scoped to the parent  which can change at any time. So trying to get all of the sizes to behave is a nightmare. Luckily  can only be changed in one place.\n\nThe  looks like what we like to call a magic number; it seems oddly specific. The number is the ratio 10:16 as a percent. The default  is 16 pixels, so 1/16th of a  equals one pixel. Multiplying by 10 helps keep the font size somewhat readable ( is too small,  too large). Then the final use of this declaration allows for the following:\n\nHere, it is possible to write  in terms of pixels. This provides the benefits of  while maintaining a pixel mental model. This post by Aleksandr Hovhannisyan goes into the approach in more detail also mentioning accessibility considerations. Some design systems (eg., Workbench by Gusto) use the approach to make it “easier” to work with  units. So what is so difficult that warrants this approach?\n\nThe fact is that the  doesn’t exist in design tools, so a translation from pixels to  must occur for an inclusive web experience. Before this approach, designers and engineers would need to figure out what the final  number should be based on a formula. Then they would potentially need to repeat that formula every time a new size was needed. In other words, math is hard and to repeat that math is a waste of time. It is “easier” for the translation to occur once globally.\n\nSo why would Jeremy Keith say the following about the author and the approach nearly 20 years later?\n\nNot that he—or anyone else—would recommend it these days!\n— Jeremy Keith\n\nAbsolutely arbitrary font-size\n\nToheeb Ogunbiyi does a deep dive into the  approach and has some opinions about thinking in pixels:\n\nThinking in pixels makes it easy to do the following:\nTranslate UI Design to code.\nRead the code in the editor.\nTroubleshoot the code in the browser.\nThis ensures a better development experience. In addition, the mental model is maintained across the team.\n— Toheeb Ogunbiyi\n\nWhat if I said that mental model being maintained is baseless artifact of legacy computer graphic design? 😱\n\nWhen you select a pixel font-size, what does it mean? More specifically, what is the difference between Courier) and Verdana at ? In practice it’s meant to represent the  square. In the harsh reality, it doesn’t really mean anything. That means we could use 16 pigs, or 1 barn, maybe 8 tulips to talk about  if design tools were prepared to use these units. It actually doesn’t matter as long as the visual result is expected. That’s what we are really doing when curating . We are tweaking some input and assessing the visual output. When we get something that Looks Good™, we record what the tool says in the input to repeat the visual style in digital media elsewhere.\n\nSo why do we need to use the pixel value so much? It’s because that’s what design tools have decided to use to define the  among other computer graphic properties. If the design tool was to include the  as an option, we would have a 1:1 relationship between the design expectation and the engineering execution and no need to require this translation at all! You could speak in terms of  right in the tool; no math required. The design tools are the problem and this “solution” is a community hack for a missing feature.\n\nSubverting expectations\n\nWhen the  value is redefined at the  element, the representation of the  is changed for the entire document. This means that third-party elements could look incorrect; designed with the  to expect the browser  default. This even includes usage of  in the Shadow DOM. Josh W. Comeau calls this out:\n\nThere’s a baseline assumption on the web that  will produce readable text. I don’t wanna mess with that assumption.\n— Josh W. Comeau\n\nHe also mentions that adoption is difficult because it would need to be done all at once. There’s no possibility of incremental enhancement. This also means that deprecating the approach is also troublesome. So you need to be very sure in this decision, more than most others.\n\nBack to base\n\nSo instead of thinking in terms of pixels for font size, think in terms of a base (or root) size. What is the font size that is most used in the document? This is most likely your body copy. That should be what the  represents and exist as the base. Next, any  that you want to set past this should be some proportion from the base. How much larger do you want the headline to be from the base? 1.5x larger? 2x larger? 2.5x larger? Guess what, that’s ! If you’ve set your headline to be 2.5x times larger than the base, that’s .\n\nIf the user zooms the content, that relationship is maintained. This is what Andrés Galante says in his article “Accessible Font Sizing, Explained” at CSS-Tricks:\n\nThink about proportions, not size\n— Andrés Galante\n\nWhile it’s recommended to not update the  at  and maintain the default expectations, setting the size here isn’t all bad as long as it’s made accessible. Just recognize that it does affect all use of  throughout the page where this rule is applied. So reverting this approach later is an exercise of auditing all pages where  is used and updating the values where appropriate. For large applications and systems, this could be a monumental task. However, if you’ve kept in mind that the  is relating to the  in the usage, it might not be a difficult change. It might even be a feature of the approach. Though, if you use  as just another unit because someone said it’s better without understanding why, you might end up fighting .\n\nDon’t dislike  because you don’t understand it, dislike pixels because you do.",
  "title": "62.5%",
  "updatedAt": "2026-06-10T01:51:48.185Z"
}