• The 4px baseline grid — The present
  • Ethan Wang
  • The Nuggets translation Project
  • Permanent link to this article: github.com/xitu/gold-m…
  • Translator: Mcskiller
  • Proofreader: Charlo-o, Portandbridge

I have been using the 4px baseline grid for over 2 years and have been trying to get my team to use it as well. I recently overcame my procrastination and decided to discuss it in my first Medium post. I’m looking for feedback on this approach, so forget it and let me know what you think!

The problem

Textbox boundaries always take up extra space above and below the text, which really gets on my nerves. Therefore, when I use a bounding box to measure the spacing, I end up with more spacing than you expected. The higher the line height, the more obvious the problem. In the example below, we design by measuring the spacing between bounding boxes. When all the spacing is set to 32px (card 1), the visual vertical spacing is actually greater than 32px (card 2), even though you set them all to 32px to make them all the same size.

The solution

Due to this problem, I used a 4px baseline grid for better visual accuracy. Here’s how I do it:

  1. Create a 4px grid in the background
  2. Align all UI elements and text baselines to the baseline grid
  3. Use grids instead of text box boundaries to measure vertical spacing. Specifically, I measured the upper spacing of the text with the grid line closest to the height above the content as the starting point, and measured the lower spacing with the text baseline as the starting point
  4. In addition, INSPIRED by Nathan Curtis’s article on Medium about spacing in a design system, I defined a set of spacing values for my team

To align all baselines to the grid, this method basically rounds the visible height of the text (the height from the top of the content to the baseline) to a multiple of 4px (as shown in the GIF below). This may be 1-2px off, but it’s still more accurate than using text boxes to calculate spacing.

With one exception, I don’t use the base grid for layout when vertically centering ICONS or text in components or containers, because most of the time developers use Flexbox to center elements, which is more convenient for both of us than using fixed spacing 😉.

reason

The traditional approach to graphic design is to use a baseline grid to create a sense of vertical rhythm. In my daily web design work, I don’t see many cases where this kind of rhythm is clearly needed for better alignment.

For me, using a 4px baseline grid is a way to balance visual accuracy (from the user’s side) with design efficiency (from the designer’s side). In the previous questions section, I talked about the extra spacing that comes with using text box measurements. And the end result is that the user can’t see the text box, which doesn’t make sense, especially since it can be visually unbalanced and not good for the user. On the other hand, ignoring boundary boxes and using baseline grid measurements can lead to better visual accuracy. Here’s a comparison between the two approaches. We can see that using a baseline grid design results in more accurate results when using the same spacing values (32px, 12px, 32px, 32px).

One could argue that using text boxes to measure results in more spacing. In the case of the first card, reducing the first spacing value from 32px to 28px or 24px will make the top and left margins of “Seattle” appear equal. But then design becomes a guessing game, and you never know for sure unless you count pixels. A 4px grid, on the other hand, provides a more accurate and predictable way to set spacing values around 32px (allowing for a 1-2px error).

This may seem less efficient in terms of design efficiency, but with grids, design tools (such as Sketch or Figma) can help you align elements and text baselines with the grid, making alignment and spacing much easier. Here’s how I used the baseline grid to lay out the text:

Or you can choose not to use the grid and measure manually from the top of the content (as shown in the GIF below), but you’ll be zooming in and out to see the pixel grid. Also, your artboard size may not be a multiple of 4px.

Known issues – Design to development handoff

The spacing values of the layout measured using the baseline grid can look arbitrary when the developer reviews the design using an automated annotation tool (InVision, Zeplin, Figma). Here is the design using the baseline grid. The numbers show what you will see in the autotag tool.

I briefly mentioned spacing in designing systems above. It discusses how to use CSS classes to represent spacing values, which helps keep designers and developers on the same page. Unfortunately, it is difficult to represent spacing with a set of CSS classes because of the randomness of the different spacing combinations created by using the baseline grid.

We also looked at a popular technique that many people have mentioned to mitigate the randomness problem, using ::before and ::after CSS pseudo-elements to “crop” borders (essentially setting spacing for correction). However, my code whiz boyfriend Chris Caruso told me:

Using ::before and ::after CSS pseudo-elements doesn’t work well because it varies across fonts, browsers, operating systems, and even screen resolutions. The configuration of one set of specific use environment may lead to spacing problems in another set of environment. From a developer’s point of view, this kind of programming is not good coding practice because it uses negative margins and adds extra elements to the DOM — both of which can have undesirable side effects. Therefore, it is not worth the risk in a production environment. 😑

The localization?

I have done localization research and looked at the eight script systems (Latin, Chinese kanji, Cyrillic, Tirian, Greek, Korean, kana, and Thai) that our product supports. Then I found that no matter which measurement METHOD I used, eventually, the developer would take the border spacing from the autoannotation tool and put it in CSS. Depending on the other non-Latin alphabet you use, even if the line height is the same, the visual height will be more or less different from the Latin alphabet. And their baselines may be skewed. So no matter which measurement method you use, localization will always make the spacing slightly different. However, as shown in the figure below, all the text remains in the relative center position, despite slight changes in spacing.

I don’t know much about the non-Latin alphabet yet, but I’d like to learn more. Please let me know if any of the above conclusions are incorrect or can be improved. I can only speak English and Chinese, so I would like to thank my colleagues who helped me translate this line into other languages.

Ask questions?

If there is anything unclear in the article, or if you have any questions, feedback or better solutions, please let me know! I’ve been working on this for a long time, so I’d love to hear what you think! If you want to contact me, please send email directly to [email protected]!

If you find any mistakes in your translation or other areas that need to be improved, you are welcome to the Nuggets Translation Program to revise and PR your translation, and you can also get the corresponding reward points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.