考えてみてください、CSS を使用してページを構築するとき、デフォルトのフォント サイズと行の高さはそれぞれどれくらいでしょうか?
私が収集した統計は次のとおりです:
計算後、基本的な行の高さは 18 ピクセルまたは 21 ピクセルになります。
ほとんどの友人はこの領域の詳細に注意を払っていないと思います。簡単に計算するには、基本的な行の高さは 1.5 で十分です。1.75 は問題ないと思われます。 。今日の Web ページは、情報を閲覧することしかできない状態からとうに別れを告げており、ページ構造はより複雑になり、少数の大きな説明文のみが使用されるようになりました。そのため、行の高さの役割は多少なりとも高まります。読書体験のレベルから、より便利な計算やその他の役割に変換されます。
ここでの「何の登場人物」は普通の文章に見えますが、実はこの記事の主人公です。この記事では、行の高さが
ウェブ垂直グリッド ベンチマーク の役割を果たします。
Web グリッド レイアウトについては聞いたことがあるかもしれません。正直に言うと、私は自分のレイアウトの概念と一致しないため、何百もの CSS 記事を紹介したことがありません。特筆したいのは縦型グリル！
ページのコンテンツは上から下までウォーターフォール形式で表示されることが多く、コンテンツは常に変化し、要素の高さも予測できないため、いわゆる垂直方向のグリッドはほとんど意味がありません。これは確かに事実ですが、部分グリッドによりページがより標準化され、作業が容易になる場合があります。
そして、これらすべては行の高さから始まります。以前にページを作成したときは、フォント サイズと行の高さの値を設定して、テキストの 1 行が占める高さを決定しましたが、ここでは逆に考えて、ページ上の基本テキストが占める高さを 20 にします。ピクセルの場合、行の高さは次のようになりますか?
今は大画面の時代です。デフォルトのフォント サイズが 14 ピクセルであると仮定します。四捨五入された結果は次のようになります。
申し訳ありませんが、CSS で注意してください。 , 行の高さを計算するときは、切り捨てではなく切り上げてください。上記のコードと同様に、14*1.42857 はほぼ 20 ピクセルですが、残念ながら、Chrome ブラウザではこのように、最終的には依然として 19 ピクセルの高さでレンダリングされます。
実際の設定は次のようになります:
body { line-height: 1.42857; font-size: 14px;}それで、20 ピクセルに基づく Web ページのレイアウト環境が得られます。この時点で、通常のテキスト行の高さは 20 ピクセルです。それでは、どのような利点があるでしょうか。
一見すると、高さ 20 ピクセルのユニットと高さ 21 ピクセルのユニットに違いはないように見えますが、完全なシステムに配置すると、その値がよく反映されます。
2. 20 ピクセルをベースにした小さなアイコン戦略基本的に、すべての Web サイトは、国際的に受け入れられているグラフィック言語と切り離すことができません。
とにかく、最終的には (スプライト ツールの普及により) Web ページ上のグラフィックのサイズは基本的に 16px*16px です:
body { line-height: 1.42858; font-size: 14px;}もちろん、17px*18px も非常に一般的です:
.icon-hi { display: inline-block; width: 16px; height: 16px;}この種の小さなアイコンは本物 サイズによる CSS コードの構築方法には 3 つの大きな問題があります:
次のテキストとの位置合わせ
クリック領域のサイズ
たとえば、Tencent Weibo では、アイコンのサイズは 16 ピクセルであり、その後、いくつかのさまざまな処理が行われます:
多くのパッチ、多くの CSS 処理、アイコンは絶対位置を使用しており、これは互換性を処理するための良い方法ですただし、明らかに普遍的な適用性を持っていません。
2. クリック領域のサイズ
小さなアイコンがそのままクリックボタンになる場合があります。このとき、アイコンのサイズが 16 ピクセル * 16 ピクセルの場合、不正確なクリックが発生する可能性が高くなります。 20ピクセル？
3. 冗長な CSS コードの繰り返し
当下类似 grunt-spritesmith 的小图标合并工具基本成了前端团队的标配，而根据我的观察，基本上，大家都是设计师给的图标直接扔到文件夹里面进行合并，于是，产出的代码基本上就是 width / height / background-position 的模式，然而，可能里面70%宽高都是16像素，20%是18像素，还有10%是其他小尺寸，也就是，其实很多CSS代码是可以合并的，然而，都浪费了。
如下生成less代码截图（源自真实项目）：
以上这些问题实际上一个对策就可以搞定，就是所有图标统一按照20px*20px的标准处理！
你想啊，我们网页文字基础高度是20像素，图标也是20像素高，天然对齐，问题1解决；20*20的点击区域对吧，显然比16*16要大，问题2解决；所有图标都是20*20的尺寸范围内，所有 width / height 都可以合并，大大减少CSS代码，问题3也搞定了！
如下图CSS生成模板示意：
————-低调的分隔线————-
然而，实际上的处理要比上面说的复杂和深奥的多！
图标和文字天然对齐
按照我们直观的认知，两个元素都是20像素高，都在自己的垂直范围内居中，那这两个元素应该是在一个水平线上的。实际上真的是这样吗？是的，但是，注意这里的但是，是有条件限制的！
在“ CSS深入理解vertical-align和line-height的基友关系 ”一文中，其中就已经提及过：
The baseline of an ‘inline-block’ is the baseline of its last line box in the normal flow, unless it has either no in-flow line boxes or if its ‘overflow’ property has a computed value other than ‘visible’, in which case the baseline is the bottom margin edge.
中文直译就是：
‘inline-block’的基线是正常流中最后一个line box的基线, 除非，这个line box里面既没有line boxes或者本身’overflow’属性的计算值而不是’visible’, 这种情况下基线是margin底边缘。
翻译成白话就是：
如果inline-block水平元素’overflow’不是’visible’，或者里面没有内联元素（图片、文字之类），则整个元素的基线就是自身的下边缘；否则，基线就是里面最后一行图文元素的基线（ 这是我们需要的）。
有点不太理解？没关系，不是本文的重点。你只要知道，我们要想20像素高的图标和20像素高的文字天然对齐显示，需要满足这两个条件：
所以，下面两种情况都是淘汰的！
.icon { display: inline-block; width: 20px; height: 20px; background: ....icon { display: inline-block; width: 20px; height: 20px; background: ... }
第一种情况是 overflow:hidden 拖后腿了；第二种情况是 标签里面是空大屁，基线还是元素底边缘而不是里面的文字（如果有）。
因此，要想实现小图标天然对齐，我们不能有 overflow:hidden 同时HTML标签内部有文本内容，我靠，好多限制，貌似很烦啊，然而，经过本人的实践，是可以有CSS代码段满足各种场景的对齐效果的，如下：
.icon { display: inline-block; width:20px; height:20px; background: ...; white-space:nowrap; letter-spacing: -1em; text-indent: -99em; color: transparent; /* IE7 */ *text-indent: 0; *zoom: expression( this.runtimeStyle['zoom'] = '1', this.innerHTML = '\3000');}.icon:before { /* 伪元素插入空格文本 */ content: '\3000'; }您可以狠狠地点击这里： 小图标文字对齐的终极解决方案demo
结果，无论是空标签HTML，还是内置可访问性提示文字的HTML，都是对齐效果棒棒哒！
<i class="icon"></i><a href="javascript:" class="icon">删除</a>
而且，就算文字的字号大小变化，例如 14px → 16px 图标和文字也是对齐良好的，因为，对齐的本质是图标元素里面的文字和后面的文字对齐，文字和文字对齐，自然是天然对齐的，千古难题就这么有了解决方案，以前的CSS hack啊，什么 vertical-align 控制，还有 margin 负值偏移都是浮云了！
图标20*20尺寸扩展grunt工具
设计师设计的图标都是16px~20px不等，CSS代码都是Grunt工具生成的，我们很难简单控制让所有图标都是20*20的区域大小。除非，我们对所有的小图标在导出的时候，手动扩展画布到20px*20px。
亲，什么年代了，又不是搞艺术品，手工劳作年代过去了，直接上工具。
我基于GM搞了个20像素以下小图标自动扩展为20像素大小图片的Grunt工具： https://github.com/zhangxinxu/canvasExpand
エネルギーが限られているので、ご覧のとおり、テンプレートによって生成されたテキストの多くを変更する時間がありませんでした。
Windows ユーザーは、ImageMagick.exe をインストールし、インストール中にグローバル変数などを確認することを忘れないでください。
質問があれば、大歓迎です...忙しいので、自分で考えてください、わかりました~~
アイコンの重心のピクセルレベルの処理
いくつかアイコンは、デザイナーが指定した標準的なサイズですが、余分なピクセルはありません。ただし、アイコン自体の形状は、特に上下に対称ではない場合があります。これにより、アイコンの重心が少し異なります。その結果、後ろのテキストと一緒に表示されると、実際のサイズは揃っていますが、視覚的には同じ線上にありません。要件が非常に高い場合は、通常は 1 ピクセルで十分です。たとえば、画像の重心が低い場合は、調整する必要があります。その下に高さ 1 ピクセルの追加の透明領域が存在します。
前述したように、システムではベースラインの高さ 20 ピクセルが有効であり、このシステムのもう 1 つの非常に重要なメンバーは、ページの基本的な UI コンポーネントです。 ！
すべてのボタンの高さは 40 ピクセル、すべての入力ボックスの高さは 40 ピクセル、すべてのドロップダウン ボックスと時間選択ボックスの高さは 40 ピクセルです
上の図は、「ネイティブ HTML に基づく UI コンポーネント」から取得したものです。 「開発」記事のフロントエンド分離を示す例: QQ パブリック プラットフォームの UI コンポーネントでのフロントエンド分離デモ
基本テキストの高さは 20 ピクセルなので、左テキストと上部の間の距離は標準の 10 です。ピクセル！
これは、Web ページでは、大きなモジュール間の間隔であっても、小さなテキストとスペースの間の間隔であっても、水平方向の間隔であっても垂直方向の間隔であっても、すべてが標準の 5 ピクセルの倍数であることを意味します。したがって、大小のすべてのモジュールの実際の高さは 10 の倍数 (padding-top + line-height * 行数 + padding-bottom) になります。
言い換えると、私たちはレイアウトと UI コンポーネントのデザインの基礎として 20 ピクセルを使用しており、これによりWeb ページの間隔が標準化され、目に見えない形でページの組版がよりプロフェッショナルなものになります、また zxx.lib も作成されます。 . cssの利用が改善されました。
ボタン
または入力ボックスの実装の詳細をさらに詳しく調べると、CSS 実装自体が 20 ピクセルベースの戦略に従って実装されていることがわかります:
//zxx: Erase, take aコードを見て、ボタンが高さを直接制御していることがわかりました。これは間違いでした。これは実際には問題であり、そのような設計状況に遭遇したことがないためです。はボタン内のアイコンであるため、公開されません。より良い実装は、上記の入力ボックスと同じ行で、行の高さが 20 ピクセルで、最終的な高さが 40 ピクセルになるようにパディングすることです。
20 ピクセルに基づく単純な要件のように見えますが、実際にはシステムに根ざしており、完全なソリューション セットがあります。
しかし、内容自体を超えて、別の観点から見ると、この記事の内容は実際には非常に退屈です。
淘宝網と天猫の基本的な高さは 18 ピクセルであり、ここで推奨されている 20 ピクセルではありませんが、それでも年間 3 兆の売上高があり、依然として市場に流通しており、依然として多数の地元の大物を生み出しています。
したがって、CSS の細かい部分にあまり注意を払う必要はありませんが、CSS は製品にとって商業的価値がありますが、ある段階を超えると、実際には制限されたり、直感的に表現するのが困難になったりします。費用対効果が高くありません。今日何人かの友人が、絶対配置要素の表示:なしと可視性:非表示の間の非表示のレンダリング パフォーマンスの違いについて質問しました。現在のブラウザーと偶数のレンダリング パフォーマンスに基づくと、この問題の商業的価値は 10,000 分の 1 です。実際の開発ニーズに違いがあるとしても、それはまったく価値がありません。
一般的な環境は非常に衝動的なので、あなたが遭遇するジレンマは、技術的な成長がボトルネックに遭遇したことではなく、この分野ではこれ以上の技術的な成長は必要ないので、より明白なメリットのある何かをやりに来てください!
多くの先輩技術ブログが、職場でもあるので仕方なく中止になっていると思います！
別の道を選んでもいいですか？
この記事はオリジナルの記事であり、知識ポイントは頻繁に更新され、いくつかの間違いは修正されます。したがって、転載する場合は、追跡可能性を容易にするために元のソースを保持し、誤解を招くことを避けてください。古くて間違った知識を学ぶと同時に、より良い読書体験を得ることができます。
この記事のアドレス: http://www.zhangxinxu.com/wordpress/?p=5264
(この記事は終わり)
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
