これは、ベースライン グリッドに対する理解と評価が不足していることが原因である可能性があります。あるいは、ベースライン グリッドの実装が非常に難しいことで知られており、これまでのところ誰もそれを首尾よく実装するための青写真を持っていないことが原因である可能性があります。 ベースラインは、タイポグラフィ用語として Web では冗長であり、Web での動作は印刷で使用されるものとは異なるルールに従っており、行の高さと実際の行送りの間にはイライラするようなギャップがあると考える人もいます。例。 ただし、今のところは、ベースラインが Web デザイナーにとって少なくともある程度は便利なツールであると仮定しましょう。しかし、それはどのようなツールでしょうか、それを実装するために自由に使えるツールは何ですか、そして最も重要なことに、それだけの価値があるのでしょうか?
ベースラインの位置合わせを達成するために必要な計算と微調整に入る前に、垂直グリッドとは何なのかを理解しましょう。その理由を理解すると、ベースラインの調整をどのように達成するかという、時には退屈で魅力的な問題に取り組む準備が整い、より意欲的に取り組むことができるようになります。 垂直グリッドは、構造の高さと垂直に配置された要素間の間隔を含むものとして単純に理解できます。おそらく、より一般的には、パディング、マージン、および行の高さです。水平グリッドが事前設定されたセル サイズでレイアウトを制限することにより、きちんと調和のとれた効果を実現するのと同じように、垂直グリッドも、ユーザーが下にスクロールするときに一貫性のある予測可能な手段によってコンテンツの固定構造を提供します。 5年かけてじっくり開発したUIフロントエンドフレームワーク！
グリッドは水平方向だけでなく垂直方向にも役立ちます
垂直グリッドが重要なのはなぜですか?それは、垂直グリッドが私たちの脳の働きと、パターン認識を通じて私たちの周囲の世界をどのように解析するかに関係しているからです。このトピックについてはあまり深く立ち入りませんが (私より賢い人はこの仕事に適しています)、パターン認識により、人間の脳は類似または同一の印象 (基本的な形状や色など) をパターン ライブラリに保存できると言えます。新しい刺激状況に遭遇したときにそれらを使用してください。パターン ライブラリ検索を通じて、新しい刺激状況がすぐに分析されます。これが、私たちが本を読むときに個々の文字に注意を払わず、単語全体を瞬時に認識できる理由です（同じパターンの前のインスタンスを脳の記憶から取り出します）。同じ文字 (「A」「B」「C」...) たとえフォント、サイズ、色が変わったとしても、基本的な形状はすでに私たちの脳のパターン ライブラリに保存されています。 何らかの種類の刺激が以前に保存されたパターンと一致しないと、脳は新しいパターンを新しい記憶に保存するように促され、そのためにはより多くの精神的努力が必要になります?? そして、これは構造とグリッド（水平または垂直）のデザインが重要です。次に、一定の段落間隔が X である単純なレイアウトを想像してください。最初のパッセージを分析すると、脳は他のすべての同一のパッセージを同じパターンとして即座に認識します。しかし、同じレイアウトでも要素間の間隔が異なる場合、読者の脳はその意味を理解するために個々の要素をすべて分析する必要があります。言い換えれば、脳が分析しなければならない形状が多ければ多いほど、時間がかかります。 5年かけてじっくり開発したUIフロントエンドフレームワーク！
不規則な左側は右側よりも多くの精神的努力を必要とします
不規則な形は最初に行われるパターン認識を妨げます (したがって、優れたコンテンツを評価するために使用されるべき精神活動の一部が無駄になります)。規則的で一貫性のある予測可能な構造により、デザインが読みやすく理解しやすくなります。これを達成するには、固定ベースライン グリッドを確立するのが良い方法です。
さらに、基本的にすべての垂直（および水平）間隔が一貫しており、すべての要素が事前に設定された単位サイズを持つシステムを採用することにより、上記の恣意的な不一致を排除するだけでなく、デザイナーとしてのデザイナーの仕事も容易になります。基本的な構造だけを全体の枠組みで決定する必要があります。標準を確立します。たとえば、頭の下には常に 2 つのベースラインの空白スペースがあり、各ボックスには 3 つのベースラインのパディングスペースがあり、レイアウトにロジックを追加します。これは、設計と実装が簡単であるだけでなく、さらに重要です。は理解しやすいです。
さて、垂直グリッドがまだ抽象的な概念のように見える場合は、ベースライン
複数の列の水平方向の配置?? のもう 1 つの利点が理解しやすくなります。これは、印刷デザイン、特に複数段のレイアウトを使用する雑誌や新聞でよく見られます。隣接する段落 (またはヘッダー) のベースラインが適切に揃っていれば、その位置が悪くても、読んでいて楽しくなります。まったく整列していませんが、読書が煩わしく中断されます。ベースラインの配置から派生したこの静かなタイポグラフィは、目に見えない括弧がページ上のすべての要素をサポートしており、読者が無意識のうちに安心できるようになっています。左ページと右ページのすべての行が揃っている本では、信頼感を感じやすくなります。逆に、基本的に揃っている本では、信頼性はかなり低くなります。 5年かけてじっくり開発したUIフロントエンドフレームワーク！
複数の列の水平方向の配置伝統的に、ベースラインは、ほとんどの文字が「配置」され、各ベースラインの間に基本的なベースライン グリッドを形成する目に見えない線を指します。前に説明したように、ベースラインは垂直を形成するだけではありません。グリッドですが、隣接する列も水平に整列します。ベースライン グリッドを定義したら、次のステップでは、テキスト、境界線、画像、またはボックス要素の行が常に一致し、同じ垂直構造に整列するように、すべての要素の位置合わせを強制します。
問題は、ボタンをクリックするだけで簡単に形状を調整してグリッドを整列させることができる InDesign のようなツール (グリッドのオンとオフを正確に切り替える) が、CSS では線を調整することしかできないという事実に対応していることです。 -height (コントロールを介して)、padding、margin、size を変更すると、要素の合計の高さが変化する可能性があります。 5年かけてじっくり開発したUIフロントエンドフレームワーク！
従来のベースラインは、ほとんどの文字がその上に「位置する」ラインであり、ベースライン間の高さが要素の合計の高さになります。
さらに悪いことに、CSS の line-height プロパティにはベースラインという厳密な概念がなく、テキストの各行は要素の合計の高さのほぼ中央にあります。つまり、さまざまなスタイルやフォントに基づいてテキストを正確に配置する (ベースライン配置) には、さらに手動で時間のかかる調整とピクセル レベルの微調整が必要になります。
それでは、CSS のベースラインを実装するにはどうすればよいでしょうか?垂直方向の配置を強制するためのネイティブのベースライン構文、クイックインプレース機能、またはブラウザー機能が欠如しているため、これは将来の実験に任せます。最も基本的な CSS メソッドから始めましょう。 5年かけてじっくり開発したUIフロントエンドフレームワーク！
これまでのところ、CSS ベースラインを実装するための統一された正しい方法はありません。行の高さと間隔が一連の仕様に従っている限り満足する人もいますが、より職人技と詳細を求める人もいます。 - 何があっても - テキストのすべての行がベースライン上に美しく「収まる」場合、および画像、境界線、ボックス、その他の要素がすべて同じグリッドに完全に整列している場合にのみ満足できます。皆さんにとって良いニュースは、基本的な CSS ベースラインは実際にはまったく難しくないということです。いくつかの事前の設計決定 (および永続性) があれば、基本的な計算はほんの少しだけ必要になります。
使用する最小のテキスト (主に本文) から始めて、そこから上に向かって作業を進めていくのが最善です。以下の例では、フォント サイズ 14 ピクセル、行の高さ 22 ピクセルを使用しています。つまり、22 ピクセルがベースライン間の高さになります。この定義の結果、次のように、すべての行の高さとすべての要素 (ボーダー、パディング、マージンを含む) の合計高さは 22px の倍数でなければなりません:
h1{ font-size: 40px; line-height: 44px; margin-bottom: 22px;}p { font-size: 14px; line-height: 22px; margin-bottom: 22px;}
定義された行の高さとフォント サイズ現在は最適ではないため、スケーラビリティを考慮して em に変換します。これにより、コードが少し読みにくくなりますが、使用される計算は非常に簡単です。フォント サイズを変更するときに行の高さを再計算することを忘れないでください。 5年かけてじっくり開発したUIフロントエンドフレームワーク！
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;}
与えられた例での「物理的な」サイズと比率をより明確に示すために、この記事全体を通してフォントサイズと行の高さをピクセル単位で言及することに注意してください。ただし、すべてのコードについては em に変換します。
可視グリッドを使用すると (多くの人は png または gif の背景画像を使用し、他の人は Baseliner などのツールを使用します)、すべてのスタイルの配置を検出できます。ここで、テキスト行がベースライン上に「座っている」のではなく、ベースライン間を浮遊していることがわかります。この段階では心配する必要はありません。背景画像を変更するか本文にパディングを追加するだけでこの問題を修正できます。
ビジュアル グリッドは設計プロセスで非常に役立ちます
ここまではうまくいきましたが、私たちのコードはまだかなり基本的です。しかし、すべての要素にさらに多くの属性 (上枠など) を含めるとどうなるでしょうか?当然のことながら、境界線の高さを結合した後の合計の高さが依然としてベースライン間の高さの倍数になるように、プロパティ値を調整する必要があります。 5年かけてじっくり開発したUIフロントエンドフレームワーク！
h1{ border-top: 3px; padding-top: 22px; margin-bottom: 19px; /* 22px-3px */}
ボーダートップ 3 ピクセルとマージンボトム 19 ピクセルの合計をベースライン間の高さ 22 ピクセルに等しくする方法に注意してください
りー
在简单的文字排版布局上使用基线网格要相对简单点，但我们必须保证其他的元素相图片也要对齐网格。对于容器，按钮，和网页分界线来说，通过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 フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
