This may be due to a lack of understanding and appreciation of the baseline grid, or perhaps because the baseline grid is notoriously difficult to implement, and no one has yet had a blueprint to successfully implement it. Some even think that baselines are redundant on the web. Baseline as a typography term and behavior on the web follows different rules than those used for print, and there is a frustrating gap between line-height and true leading. The difference is the most obvious example. For now, however, let's assume that baselines are, at least to some extent, a useful tool for web designers. But what kind of tool is it, what tools are at our disposal to implement it, and most importantly, is it worth it?
Before we do the math and do the nudging to achieve baseline alignment, let’s understand what it’s all about: Vertical Grid. When you understand why, you will be better prepared and more motivated to tackle the sometimes tedious and fascinating problem of how to achieve baseline alignment. Vertical grid can be simply understood as involving the height of the structure and the spacing between vertically arranged elements. Perhaps more generally, it is padding, margin and line-height. . Just as the horizontal grid achieves a neat and harmonious effect by constraining the layout with a preset cell size, the vertical grid also provides a fixed structure of content by consistent and predictable measures as the user scrolls down. UI front-end framework carefully developed for 5 years!
Grids are not only useful in the horizontal direction, but also in the vertical direction
Why is the vertical grid important? Because the vertical grid is related to how our brains work and how we parse the world around us through pattern recognition. Without going too deep into this topic (others smarter than me are better suited to the task), it can be said that pattern recognition allows the human brain to store similar or identical impressions (such as basic shapes and colors) in a pattern library and use them when encountering New stimulus situations are quickly analyzed through pattern library search. This is why when we read we don’t pay attention to it as an independent letter , but can recognize the entire word in an instant (taking out previous instances of the same pattern from our brain memory). This is also true That's why we can quickly recognize the same letter ("A" "B" "C" ...) even if the font, size and color change - the basic shape is already stored in our brain's pattern library. Once any type of stimulus fails to match your previously stored pattern, this prompts the brain to store new patterns in new memories, which in turn requires more mental effort?? And this is structure and grid ( Whether horizontal or vertical) design is important. Next, imagine a simple layout with consistent paragraph spacing of X. After analyzing the first passage, your brain will immediately recognize all other identical passages as the same pattern. But if, instead, the same layout has different spacing between elements, the reader’s brain has to analyze all the individual elements to understand their meaning. To put it another way: the more shapes the brain has to analyze, the longer it takes. UI front-end framework carefully developed for 5 years!
The irregular left side requires more mental effort than the right side
Any irregular shape will interrupt the stream of pattern recognition that comes first (and therefore waste (part of the mental activity that should be spent on appreciating great content), and a regular, consistent, and predictable structure will make your design easier to read and understand. Establishing a fixed baseline grid is a good way to achieve this.
Furthermore, by essentially having a system where every vertical (and horizontal) spacing is consistent and every element has a preset unit size not only eliminates the arbitrary inconsistencies mentioned above, but also makes the designer's job easier , the designer only needs to decide the basic structure in the overall frame. Establish a standard, for example, there is always two baselines of white space below the head, and each box has three baseline spaces of padding, adding logic to our layout, which is not only easy to design and easy to implement, but more importantly is easy to understand.
Now, if the vertical grid still seems like an abstract concept, another advantage of baselines - Horizontal alignment of multiple columns - becomes easier to understand. This is more common in print design, especially magazines and newspapers, which often use multi-column layouts. If the baseline alignment of adjacent paragraphs (or headers) is well aligned, it will make reading immersive and joyful. Once the alignment is poor or not aligned at all, Reading is interrupted annoyingly. This quiet typography derived from baseline alignment shows a kind of visual confidence. An invisible bracket supports all elements on the page, allowing readers to subconsciously feel at ease. In a book where every line of the left-hand page is aligned with the right-hand page, it is easy to feel trust. On the contrary, if the book is basically aligned, this trust is much less. UI front-end framework carefully developed for 5 years!
Horizontally align multiple columns
Traditionally, the baseline refers to an invisible line on which most letters "sit". A basic baseline grid is formed between each baseline, as As discussed previously, the baseline not only forms a vertical grid, but also aligns adjacent columns horizontally. Once the baseline grid is defined, the next step is to enforce alignment of all elements so that rows of text, borders, images, or box elements always match and align to the same vertical structure.
The problem is that tools like InDesign that allow you to easily adjust the shape to align the grid with the click of a button (turning the grid on and off exactly), in CSS can only adjust the row height through controls. (line-height), padding, margin, size? Any changes among them may cause changes in the total height of the element. UI front-end framework carefully developed for 5 years!
The traditional baseline is the line above which most letters "sit", and the height between baselines is the total height of the element.
To make matters worse, the line-height property in CSS does not have a strict concept of a baseline, and each line of text is roughly in the middle of the total height of the element. This means that precise alignment of text (baseline alignment) based on different styles and fonts requires further manual, time-consuming adjustments and pixel-level nudges.
So, how do we go about implementing a baseline for CSS? Due to the lack of native baseline syntax, quick-in-place or browser functionality to force vertical alignment, we leave this to future experimentation. Let’s start with the most basic css method. UI front-end framework carefully developed for 5 years!
So far, there is no unified and correct method to implement css baseline. Some people just need to make the line height and spacing follow a set of specifications. Satisfied, others are more crafted and detailed - no matter what - only if every line of text "sits" beautifully on the baseline, and images, borders, boxes and other elements all line up perfectly to the same grid. satisfy. The good news for everyone is: basic CSS baselines really aren’t difficult at all. With some upfront design decisions (and persistence), they only require a little bit of basic math.
Define your baseline. It is best to start with the smallest text you use, mostly your body text, and work upwards from there. In my example below, I use a font-size of 14px with a line-height of 22px, which means 22px is the height between my baselines. The result of this definition is that all line-heights and the total height of all elements (including borders, padding and margins) must be multiples of 22px, as follows:
h1{ font-size: 40px; line-height: 44px; margin-bottom: 22px;}p { font-size: 14px; line-height: 22px; margin-bottom: 22px;}
The line-height and font-size defined now are not optimal, so they are converted to em for scalability. This makes the code a little harder to read, but the math used is pretty simple - just remember to recalculate line-height when changing font-size. UI front-end framework carefully developed for 5 years!
h1{ font-size: 2.5em; /* = 40px/16px */ line-height: 1.1em; /* = 44px/40px */ margin-bottom: 22px;}p { font-size: 0.875em; /* 16px is the default em size */ line-height: 1.5714285714285714em; /* = 22px/14px */ margin-bottom: 22px;}
Note that throughout this article I will mention font-size and line-height in px, so as to more clearly indicate their "physical" size and given proportions in the example. However, for all code, we will convert it to em.
Using a visible grid (many people use png or gif background images, others use tools like Baseliner) we can detect the alignment of all styles. Here we find that the lines of text do not "sit" on the baseline, but instead float between them. There's nothing to worry about at this stage - we can fix this by simply reducing our background image, or adding padding to the body.
A visual grid would be helpful in the design process
So far so good, but our code is still pretty basic. But what happens if we include more attributes - such as a top border - to all elements? Naturally, the property values need to be adjusted so that the total height after combining the border heights is still a multiple of the height between the baselines. UI front-end framework carefully developed for 5 years!
h1{ border-top: 3px; padding-top: 22px; margin-bottom: 19px; /* 22px-3px */}
Note how to make the sum of the border-top of 3px and the margin-bottom of 19px equal to the height between the baselines of 22px
Although this is indeed not high-tech, in complex websites, especially when using relative units, adding the above numbers will be a big challenge. If you're willing to sacrifice em scalability and stick with px, a precompiled language like SASS can take care of some of the trouble. Using SASS we can define the height between baselines as a variable ($baseline in my case) and use a linear equation to define its multiples. This makes the whole process very simple and makes the css easier to read. In the normal process, if you want to re-dinginess the height between your baselines, you only need to change one place. Although my example below uses Sass, the same principle applies when using rems - define your baseline height only in one place and then apply it throughout your code. UI front-end framework carefully developed for 5 years!
$baseline: 22px; .box { padding-top: 3px; height: $baseline*15;}h1{ font-size: 40px; line-height: $baseline*2; margin-bottom: $baseline;}p { font-size: 16px; line-height: $baseline; margin-bottom: $baseline;}
在简单的文字排版布局上使用基线网格要相对简单点，但我们必须保证其他的元素相图片也要对齐网格。对于容器，按钮，和网页分界线来说，通过css让任何的单元都是基线间高度的倍数，这是一个很重要的约定。但从另一个方面来说，图片很少遵守这一约定，其一般为一系列任意的高度，因此在这样的例子中，少量的JavaScript便可以帮我们的大忙。我不会在此深究，但是jQuery的插件Baseline.js和Matthew Wilcox关于垂直网格的文章倒是值得一看。如果你正在进行一个复杂的布局，无妨看看FtColumnflow??一段“修复css多列布局缺陷”的代码，它广泛使用在音乐《金融时报》的web app上，并且如果你想找一个更为健壮的方案，它或许更加合适。
上述基础的方案。通过保证我们的行高，内边距，外边距，高度??任何的属性??相加和总是等于基线间高度的倍数，就可以保证我们整个垂直网格不受影响，这很简单，对吧？
当然，如果接下来不继续深入，你也不会看这篇文章了。精心开发5年的UI前端框架！
坏消息是，大多数的设计师在受限的条件下工作，有时一个22px的基线间的高度对他们来说更像是一个令人烦恼的阻碍，而不是有用的约束。例如，遵循黄分割的规则，一个16px的段落主体部分可以推导出26px的段头（尽管下部段落主题可能适用高于20px的任何值，这取决于字体）。保持我们的基线间高度为22px，你或许会发现一个简单的22px的基线间高度的行距太窄了以至于不能舒适的阅读，然而一个双倍的基线间高度又显得太宽了，只有在h2呈两行显示的情况下才会有这样的争论，当然理论上可以假设列的宽度足够的长，这样折行就永远都不会发生，嗯哼，这只是理论上。
h2要么小的尴尬要么行高太大
如果在此有一种快速到位的方法，就不会发生上述的问题，就像我们可以简单的将h2不应用基线网格，看看紧随它的短多是不会魔术般的落到正确的位置。遗憾的，并不存在这样可行的魔法，我们只能实事求是的去思考找出一种解决方案。
在文章的开始我曾推荐从你有着最小文本的line-height开始定义你的基线间的高度，就像body的文本。正如我们所看到的，一个固定的，22px（或者你body line-height的任意值）的最小单元会使得固定字体的line-height值变得很不合适。但如果让我们的原始的基线间高度减半会怎样？技术上来讲我们的body的文本就会有两个基线间高度的line-height，但这只是纸上谈兵。在大多数的示例中，这样带来的可变性和排版自由的结果是值得的，我们使用黄金分割的比例来快速的定义一些h元素的大小（四舍五入，保持em值整洁），我们可以很容易的看到每次值得增加都会有一个合适的line-height值，例如：16px/22px ，28px/33px，40px/44px等。 精心开发5年的UI前端框架！
h1{ font-size: 2.5em; line-height: 1.1em; margin-bottom: 22px;}h2{ font-size: 1.625em; /* 26px/16px */ line-height: 1.2692307692307692em; /* 33px/26px */ margin-bottom: 11px;}
h1, h2, 和 p都对齐了基线网格
在我继续之前，我必须承认的是，下述的内容完全是实验性的甚至你们其中一部分人甚至会认为它实践起来也很糟糕。但如果你准备继续迁就我，即使它变得丑陋也继续阅读。好吧，我说的丑陋是源于“代码整洁”的观点。或许从设计的角度来说，它可能确实很漂亮。
基于上述的基本的方案和带一点实用性（可选）的随意可变得方案，现在我们有知识和工具去改善大多数布局的基线网格，但是对于真正基线却没有实现。正如前面所提到的，css中line-height计算的方式意味着字符大约处于行距的垂直中点，而不是字符的下边紧挨着基线（先InDesign和Quark）。许多人理所应当的认为这就这是应该的。这就是css中iine-height工作的方式，我们没法改变。没错，但是我们的眼睛并不知道css的概念。我们的眼睛并不习惯去按照x轴中心去扫描成行的文字??它们习惯于跟随字符的地步，基线来阅读，并且当相邻行错位的时候可读性就会变差。
来看一下下面的额例子： 精心开发5年的UI前端框架！
h1{ font-size: 2.5em; line-height: 1.1em; margin-bottom: 22px;}h2{ font-size: 1.625em; /* 26px/16px */ line-height: 1.2692307692307692em; /* 33px/26px */ margin-bottom: 11px;}p { font-size: 0.875em; line-height: 1.5714285714285714em; margin-bottom: 11px;}p.intro { font-size: 1.125em; /* 18px/16px */ line-height: 1.22222222em; /* 22px/16px */ margin-bottom: 22px;}
在相邻两列的情况且，尽管基线已经正确的贯穿介绍段落，但介绍段落的字母的底部（下图红线）并没有对齐和主段落对其，这正是因为字体计算之后的line-height所导致。
css中line-height倒是夸列并没有对其
现在到了它变丑陋的地方。为了能够在所有列中的成行文本都对齐（当然是最重要的一点是从基线网格开始），我们必须手动偏移样式。一个简单的方法是增加padding-top的值直到字符紧挨到基线，并且相应调整margin-bottom来弥补增加的值。 精心开发5年的UI前端框架！
h1{ font-size: 2.5em; line-height: 1.1em; padding-top: Xpx; /* This requires trial and error, as X depends on your font and line-height */ margin-bottom: 22px-Xpx;}h2{ font-size: 1.625em; /* 26px/16px */ line-height: 1.2692307692307692em; /* 33px/26px */ padding-top: Xpx; margin-bottom: 11px-Xpx;}p { font-size: 0.875em; line-height: 1.5714285714285714em; padding-top: Xpx; margin-bottom: 11px-Xpx;}p.intro { font-size: 1.125em; /* 18px */ line-height: 1.22222222em; /* 22px */ padding-top: Xpx; margin-bottom: 11px-Xpx;}
混乱？也许是的。确实乏味。但同时也没有什么能像施了魔法般的让基线完美的对齐复杂布局一样令人欣喜而愉悦了。
所有的元素多列对齐。
嘘。如果你仍然还在阅读，或许你要么是受虐狂，要么是对细节有着病态的迷恋，而对于后者，恭喜你，毫无疑问你的基线就像外墙的砖一样牢固。
下面是我们所有的。基础css的基线，相当的简单，只需要不多的数学和组织即可改进你的布局。而在天平的另一端，我们可以手动的调整padding和margin值来模拟像打印设计中精确的基线，这种概念无疑会让纯css主义者面带愁容。更实在的问题当然是，手动的偏移样式对视觉效果带来好处是否值得。在某种情况下，比如设计驱动的项目和微型站点中，这确实值得。
其他情况，大部分的情况是，对于更为复杂的站点（你的项目经理会绞尽脑汁想知道你为什么需要花那么长的时间来构建初始模版）或者由数个开发者维持同样的代码的协作性项目，这样确实不值得。我们需要面对的是??我们所谈论的在某些极端的例子中不仅会增加体力劳动，而且会让代码变得更为负责和难以维护。在一个足够的大的项目中甚至会影响你站点的加载时间。
但是想想看，仅仅是几年前，从行业领袖到黑客很少有人提倡并不讨巧的“sliding doors”技术，但现在css3已经让它变得司空见惯。使用两个div而不是一个来实现圆角这是否值得？很显然，对一些人来说是值得的??但其他人认为就是浪费时间，导致了实施的困难和语义上有缺陷的代码。但是关键的一点是：如果没有人尝试如此劳力和代码密集的技术，我们可能不会有成熟语法的技术时代了。
实验性的，糟糕的体验，hacks，丑陋的代码??无论我们怎样称呼它??它已经推出了，并且将会继续推出，我们的语法会改善，我们将使用新的工具来创建和发布下一代的在线内容。为了回应Mark Boulton的“若css能够无痛的创建基线网格这将会有多酷”无论你的执念有多强??无论你的字符是紧挨着基线或者悬浮在基线之间??垂直网格都会是一个重要的思路，使用任意本文所列的方法都会给你一个满意的基线网格。
当然，会有一些例子比较难以实施网格的约束，像一些元素如，题注，导航或者列表项目好像不能正确的对齐到预先定义的结构中。在这些例子中，需要注意的是一些妥协并不是世界末日。一些设计时，像杰出的设计时Khoi Vinh，认为基线在你内容主体的上下文才最为重要，一些次要的元素可以在不破坏布局的情况下不遵守基线对齐。精心开发5年的UI前端框架！
希望能够理解的是在此并没有正确或者错误的实现基线的方法，这也会激励你在将来能够后在你的项目中尝试，在此我也鼓励任何一个喜欢排版的人贡献这个正在进行的项目，能在未来的的网页设计中让垂直网格和水平网格同等重要。
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
