davidbgk
/
larlet-fr-david-cache


			
							123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407
							<!doctype html><!-- This is a valid HTML5 document. -->
<!-- Screen readers, SEO, extensions and so on. -->
<html lang="en">
<!-- Has to be within the first 1024 bytes, hence before the `title` element
  See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
<meta charset="utf-8">
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
<!-- The viewport meta is quite crowded and we are responsible for that.
  See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
<meta name="viewport" content="width=device-width,initial-scale=1">
<!-- Required to make a valid HTML5 document. -->
<title>Deep dive CSS: font metrics, line-height and vertical-align (archive) — David Larlet</title>
<meta name="description" content="Publication mise en cache pour en conserver une trace.">
<!-- That good ol' feed, subscribe :). -->
<link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/">
<!-- Generated from https://realfavicongenerator.net/ such a mess. -->
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png">
<link rel="manifest" href="/static/david/icons2/site.webmanifest">
<link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c">
<link rel="shortcut icon" href="/static/david/icons2/favicon.ico">
<meta name="msapplication-TileColor" content="#f7f7f7">
<meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml">
<meta name="theme-color" content="#f7f7f7" media="(prefers-color-scheme: light)">
<meta name="theme-color" content="#272727" media="(prefers-color-scheme: dark)">
<!-- Is that even respected? Retrospectively? What a shAItshow…
  https://neil-clarke.com/block-the-bots-that-feed-ai-models-by-scraping-your-website/ -->
<meta name="robots" content="noai, noimageai">
<!-- Documented, feel free to shoot an email. -->
<link rel="stylesheet" href="/static/david/css/style_2021-01-20.css">
<!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. -->
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<script>
    function toggleTheme(themeName) {
        document.documentElement.classList.toggle(
            'forced-dark',
            themeName === 'dark'
        )
        document.documentElement.classList.toggle(
            'forced-light',
            themeName === 'light'
        )
    }
    const selectedTheme = localStorage.getItem('theme')
    if (selectedTheme !== 'undefined') {
        toggleTheme(selectedTheme)
    }
</script>

  <meta name="robots" content="noindex, nofollow">
  <meta content="origin-when-cross-origin" name="referrer">
  <!-- Canonical URL for SEO purposes -->
  <link rel="canonical" href="https://iamvdo.me/en/blog/css-font-metrics-line-height-and-vertical-align">

<body class="remarkdown h1-underline h2-underline h3-underline em-underscore hr-center ul-star pre-tick" data-instant-intensity="viewport-all">


<article>
  <header>
    <h1>Deep dive CSS: font metrics, line-height and vertical-align</h1>
  </header>
  <nav>
    <p class="center">
      <a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
        <use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-home"></use>
      </svg> Accueil</a> •
      <a href="https://iamvdo.me/en/blog/css-font-metrics-line-height-and-vertical-align" title="Lien vers le contenu original">Source originale</a>
      <br>
      Mis en cache le 2024-04-18
    </p>
  </nav>
  <hr>
  <p><code>Line-height</code> and <code>vertical-align</code> are simple CSS properties. So simple that most of us are convinced to fully understand how they work and how to use them. But it’s not. They really are complex, maybe the hardest ones, as <strong>they have a major role in the creation of one of the less-known feature of CSS: inline formatting context</strong>.</p>
<p>For example, <code>line-height</code> can be set as a length or a unitless value , but the default is <code>normal</code>. OK, but what normal is? We often read that it is (or should be) 1, or maybe 1.2, even the <a href="https://www.w3.org/TR/CSS2/visudet.html#propdef-line-height">CSS spec is unclear on that point</a>. We know that unitless <code>line-height</code> is <code>font-size</code> relative, but the problem is that <code>font-size: 100px</code> behaves differently across font-families, so is <code>line-height</code> always the same or different? Is it really between 1 and 1.2? And <code>vertical-align</code>, what are its implications regarding <code>line-height</code>?</p>
<p>Deep dive into a not-so-simple CSS mechanism…</p>
<h2 id="lets-talk-about-font-size-first">Let’s talk about <code>font-size</code> first<a href="#lets-talk-about-font-size-first" class="self-link"></a></h2>
<p>Look at this simple HTML code, a <code>&lt;p&gt;</code> tag containing 3 <code>&lt;span&gt;</code>, each with a different <code>font-family</code>:</p>
<pre class="language-markup"><code>&lt;p&gt;
    &lt;span class="a"&gt;Ba&lt;/span&gt;
    &lt;span class="b"&gt;Ba&lt;/span&gt;
    &lt;span class="c"&gt;Ba&lt;/span&gt;
&lt;/p&gt;</code></pre>
<pre><code>p  { font-size: 100px }
.a { font-family: Helvetica }
.b { font-family: Gruppo    }
.c { font-family: Catamaran }</code></pre>
<p>Using the same <code>font-size</code> with different font-families produce elements with various heights:</p>
<figure><img src="/content/01-blog/30-css-avance-metriques-des-fontes-line-height-et-vertical-align/font-size.png"><figcaption class="caption">Different font-families, same font-size, give various heights</figcaption></figure>
<p>Even if we’re aware of that behavior, why <code>font-size: 100px</code> does not create elements with 100px height? I’ve measured and found these values: Helvetica:  115px, Gruppo: 97px and Catamaran: 164px</p>
<figure><img src="/content/01-blog/30-css-avance-metriques-des-fontes-line-height-et-vertical-align/font-size-line-height.png"><figcaption class="caption">Elements with font-size: 100px have height that varies from 97px to 164px</figcaption></figure>
<p>Although it seems a bit weird at first, it’s totally expected. <strong>The reason lays down inside the font itself</strong>. Here is how it works:</p>
<ul>
<li>a font defines its <a href="http://designwithfontforge.com/en-US/The_EM_Square.html">em-square</a> (or UPM, units per em), a kind of container where each character will be drawn. This square uses relative units and is generally set at 1000 units. But it can also be 1024, 2048 or anything else.</li>
<li>based on its relative units, metrics of the fonts are set (ascender, descender, capital height, x-height, etc.). Note that some values can bleed outside of the em-square.</li>
<li>in the browser, relative units are scaled to fit the desired font-size.</li>
</ul>
<p>Let’s take the Catamaran font and open it in <a href="https://fontforge.github.io/en-US/">FontForge</a> to get metrics:</p>
<ul>
<li>the em-square is 1000</li>
<li>the ascender is 1100 and the descender is 540. After running some tests, it seems that browsers use the <em>HHead Ascent</em>/<em>Descent</em> values on Mac OS, and <em>Win Ascent</em>/<em>Descent</em> values on Windows (these values may differ!). We also note that <em>Capital Height</em> is 680 and <em>X height</em> is 485.</li>
</ul>
<figure><img src="/content/01-blog/30-css-avance-metriques-des-fontes-line-height-et-vertical-align/font-forge-metrics.png"><figcaption class="caption">Font metrics values using FontForge</figcaption></figure>
<p>That means the Catamaran font uses 1100 + 540 units in a 1000 units em-square, which gives a height of 164px when setting <code>font-size: 100px</code>. <strong>This computed height defines the <em>content-area</em> of an element</strong> and I will refer to this terminology for the rest of the article. You can think of the <em>content-area</em> as the area where the <code>background</code> property applies .</p>
<p>We can also predict that capital letters are 68px high (680 units) and lower case letters (x-height) are 49px high (485 units). As a result, <code>1ex</code> = 49px and <code>1em</code> = 100px, not 164px (thankfully, <code>em</code> is based on <code>font-size</code>, not computed height)</p>
<figure><img src="/content/01-blog/30-css-avance-metriques-des-fontes-line-height-et-vertical-align/upm-px-equivalent.png"><figcaption class="caption">Catamaran font: UPM —Units Per Em— and pixels equivalent using font-size: 100px</figcaption></figure>
<p>Before going deeper, a short note on what this it involves. When a <code>&lt;p&gt;</code> element is rendered on screen, it can be composed of many lines, according to its width. Each line is made up of one or many inline elements (HTML tags or anonymous inline elements for text content) and is called a <em>line-box</em>. <strong>The height of a <em>line-box</em> is based on its children’s height</strong>. The browser therefore computes the height for each inline elements, and thus the height of the <em>line-box</em> (from its child’s highest point to its child’s lowest point). As a result, a <em>line-box</em> is always tall enough to contain all its children (by default).</p>
<blockquote>
<p>Each HTML element is actually a stack of <em>line-boxes</em>. If you know the height of each <em>line-box</em>, you know the height of an element.</p>
</blockquote>
<p>If we update the previous HTML code like this:</p>
<pre class="language-markup"><code>&lt;p&gt;
    Good design will be better.
    &lt;span class="a"&gt;Ba&lt;/span&gt;
    &lt;span class="b"&gt;Ba&lt;/span&gt;
    &lt;span class="c"&gt;Ba&lt;/span&gt;
    We get to make a consequence.
&lt;/p&gt;</code></pre>
<p>It will generate 3 <em>line-boxes</em>:</p>
<ul>
<li>the first and last one each contain a single anonymous inline element (text content)</li>
<li>the second one contains two anonymous inline elements, and the 3 <code>&lt;span&gt;</code></li>
</ul>
<figure><img src="/content/01-blog/30-css-avance-metriques-des-fontes-line-height-et-vertical-align/line-boxes.png"><figcaption class="caption">A <code>&lt;p&gt;</code> (black border) is made of line-boxes (white borders) that contain inline elements (solid borders) and anonymous inline elements (dashed borders)</figcaption></figure>
<p>We clearly see that the second <em>line-box</em> is taller than the others, due to the computed <em>content-area</em> of its children, and more specifically, the one using the Catamaran font.</p>
<p><strong>The difficult part in the <em>line-box</em> creation is that we can’t really see, nor control it with CSS</strong>. Even applying a background to <code>::first-line</code> does not give us any visual clue on the first <em>line-box</em>’s height.</p>
<h2 id="line-height-problems-and-beyond"><code>line-height</code>: to the problems and beyond<a href="#line-height-problems-and-beyond" class="self-link"></a></h2>
<p>Until now, I introduced two notions: <em>content-area</em> and <em>line-box</em>. If you’ve read it well, I told that a <em>line-box</em>’s height is computed according to its children’s height, I didn’t say its children <em>content-area</em>’s height. And that makes a big difference.</p>
<p>Even though it may sound strange, <strong>an inline element has two different height: the <em>content-area</em> height and the <em>virtual-area</em> height</strong> (I invented the term <em>virtual-area</em> as the height is invisible to us, but you won’t find any occurrence in the spec).</p>
<ul>
<li>the <em>content-area</em> height is defined by the font metrics (as seen before)</li>
<li><strong>the <em>virtual-area</em> height is the <code>line-height</code></strong>, and it is the height <strong>used to compute the <em>line-box</em>’s height</strong></li>
</ul>
<figure><img src="/content/01-blog/30-css-avance-metriques-des-fontes-line-height-et-vertical-align/line-height.png"><figcaption class="caption">Inline elements have two different height</figcaption></figure>
<p>That being said, it breaks down the popular belief that <code>line-height</code> is the distance between baselines. In CSS, it is not .</p>
<figure><img src="/content/01-blog/30-css-avance-metriques-des-fontes-line-height-et-vertical-align/line-height-yes-no.png"><figcaption class="caption">In CSS, the line-height is not the distance between baselines</figcaption></figure>
<p>The computed difference of height between the <em>virtual-area</em> and the <em>content-area</em> is called the leading. Half this leading is added on top of the <em>content-area</em>, the other half is added on the bottom. <strong>The <em>content-area</em> is therefore always on the middle of the <em>virtual-area</em></strong>.</p>
<p>Based on its computed value, the <code>line-height</code> (<em>virtual-area</em>) can be equal, taller or smaller than the <em>content-area</em>. In case of a smaller <em>virtual-area</em>, leading is negative and a <em>line-box</em> is visually smaller than its children.</p>
<p>There are also other kind of inline elements:</p>
<ul>
<li>replaced inline elements (<code>&lt;img&gt;</code>, <code>&lt;input&gt;</code>, <code>&lt;svg&gt;</code>, etc.)</li>
<li><code>inline-block</code> and all <code>inline-*</code> elements</li>
<li>inline elements that participate in a specific formatting context (eg. in a flexbox element, all flex items are <em>blocksified</em>)</li>
</ul>
<p>For these specific inline elements, height is computed based on their <code>height</code>, <code>margin</code> and <code>border</code> properties. If <code>height</code> is <code>auto</code>, then <code>line-height</code> is used and the <em>content-area</em> is strictly equal to the <code>line-height</code>.</p>
<figure><img src="/content/01-blog/30-css-avance-metriques-des-fontes-line-height-et-vertical-align/line-height-inline-block.png"><figcaption class="caption">Inline replaced elements, inline-block/inline-* and blocksified inline elements have a content-area equal to their height, or line-height</figcaption></figure>
<p>Anyway, the problem we’re still facing is how much the <code>line-height</code>’s <code>normal</code> value is? And the answer, as for the computation of the <em>content-area</em>’s height, is to be found inside the font metrics.</p>
<p>So let’s go back to FontForge. The Catamaran’s em-square is 1000, but we’re seeing many ascender/descender values:</p>
<ul>
<li>generals <em>Ascent/Descent</em>: ascender is 770 and descender is 230. Used for character drawings. (table <em>“OS/2”</em>)</li>
<li>metrics <em>Ascent/Descent</em>: ascender is 1100 and descender is 540. Used for <em>content-area</em>’s height. (table <em>“hhea”</em> and table <em>“OS/2”</em>)</li>
<li>metric <em>Line Gap</em>. Used for <code>line-height: normal</code>, by adding this value to <em>Ascent/Descent</em> metrics. (table <em>“hhea”</em>)</li>
</ul>
<p>In our case, the Catamaran font defines a 0 unit line gap, so <strong><code>line-height: normal</code> will be equal to the <em>content-area</em>, which is 1640 units, or 1.64</strong>.</p>
<p>As a comparison, the Arial font describes an em-square of 2048 units, an ascender of 1854, a descender of 434 and a line gap of 67. It means that <code>font-size: 100px</code> gives a <em>content-area</em> of 112px (1117 units) and a <code>line-height: normal</code> of 115px (1150 units or 1.15). All these metrics are font-specific, and set by the font designer.</p>
<p><strong>It becomes obvious that setting <code>line-height: 1</code> is a bad practice</strong>. I remind you that unitless values are <code>font-size</code> relative, not <em>content-area</em> relative, and dealing with a <em>virtual-area</em> smaller than the <em>content-area</em> is the origin of many of our problems.</p>
<figure><img src="/content/01-blog/30-css-avance-metriques-des-fontes-line-height-et-vertical-align/line-height-1.png"><figcaption class="caption">Using line-height: 1 can create a line-box smaller than the content-area</figcaption></figure>
<p>But not only <code>line-height: 1</code>. For what it’s worth, on the 1117 fonts installed on my computer (yes, <a href="https://github.com/qrpike/Web-Font-Load">I installed all fonts from Google Web Fonts</a>), 1059 fonts, around 95%, have a computed <code>line-height</code> greater than 1. Their computed <code>line-height</code> goes from 0.618 to 3.378. You’ve read it well, 3.378!</p>
<p>Small details on <em>line-box</em> computation:</p>
<ul>
<li>for inline elements, <code>padding</code> and <code>border</code> increases the background area, but not the <em>content-area</em>’s height (nor the <em>line-box</em>’s height). The <em>content-area</em> is therefore not always what you see on screen. <code>margin-top</code> and <code>margin-bottom</code> have no effect.</li>
<li>for replaced inline elements, <code>inline-block</code> and <em>blocksified</em> inline elements: <code>padding</code>, <code>margin</code> and <code>border</code> increases the <code>height</code>, so the <em>content-area</em> and <em>line-box</em>’s height</li>
</ul>
<h2 id="vertical-align-one-property-rule-them-all"><code>vertical-align</code>: one property to rule them all<a href="#vertical-align-one-property-rule-them-all" class="self-link"></a></h2>
<p>I didn’t mention the <code>vertical-align</code> property yet, even though it is an essential factor to compute a <em>line-box</em>’s height. We can even say that <strong><code>vertical-align</code> may have the leading role in inline formatting context</strong>.</p>
<p>The default value is <code>baseline</code>. Do you remind font metrics ascender and descender? These values determine where the baseline stands, and so the ratio. As the ratio between ascenders and descenders is rarely 50/50, it may produce unexpected results, for example with siblings elements.</p>
<p>Start with that code:</p>
<pre class="language-markup"><code>&lt;p&gt;
    &lt;span&gt;Ba&lt;/span&gt;
    &lt;span&gt;Ba&lt;/span&gt;
&lt;/p&gt;</code></pre>
<pre><code>p {
    font-family: Catamaran;
    font-size: 100px;
    line-height: 200px;
}</code></pre>
<p>A <code>&lt;p&gt;</code> tag with 2 siblings <code>&lt;span&gt;</code> inheriting <code>font-family</code>, <code>font-size</code> and fixed <code>line-height</code>. Baselines will match and the <em>line-box</em>’s height is equal to their <code>line-height</code>.</p>
<figure><img src="/content/01-blog/30-css-avance-metriques-des-fontes-line-height-et-vertical-align/vertical-align-baseline.png"><figcaption class="caption">Same font values, same baselines, everything seems OK</figcaption></figure>
<p>What if the second element has a smaller <code>font-size</code>?</p>
<pre><code>span:last-child {
    font-size: 50px;
}</code></pre>
<p>As strange as it sounds, <strong>default baseline alignment may result in a higher (!) <em>line-box</em></strong>, as seen in the image below. I remind you that a <em>line-box</em>’s height is computed from its child’s highest point to its child’s lowest point.</p>
<figure><img src="/content/01-blog/30-css-avance-metriques-des-fontes-line-height-et-vertical-align/vertical-align-baseline-nok.png"><figcaption class="caption">A smaller child element may result in a higher line-box's height</figcaption></figure>
<p>That could be <a href="http://allthingssmitty.com/2017/01/30/nope-nope-nope-line-height-is-unitless/">an argument in favor of using <code>line-height</code> unitless values</a>, but sometimes you need fixed ones to <a href="https://scotch.io/tutorials/aesthetic-sass-3-typography-and-vertical-rhythm#baseline-grids-and-vertical-rhythm">create a perfect vertical rhythm</a>. <strong>To be honest, no matter what you choose, you’ll always have trouble with inline alignments</strong>.</p>
<p>Look at this another example. A <code>&lt;p&gt;</code> tag with <code>line-height: 200px</code>, containing a single <code>&lt;span&gt;</code> inheriting <code>line-height</code></p>
<pre class="language-markup"><code>&lt;p&gt;
    &lt;span&gt;Ba&lt;/span&gt;
&lt;/p&gt;</code></pre>
<pre><code>p {
    line-height: 200px;
}
span {
    font-family: Catamaran;
    font-size: 100px;
}</code></pre>
<p>How high is the <em>line-box</em>? We should expect 200px, but it’s not what we get. The problem here is that the <code>&lt;p&gt;</code> has its own, different <code>font-family</code> (default to <code>serif</code>). Baselines between the <code>&lt;p&gt;</code> tag and the <code>&lt;span&gt;</code> are likely to be different, the height of the <em>line-box</em> is therefore higher than expected. <strong>This happens because browsers do their computation as if each <em>line-box</em> starts with a zero-width character</strong>, that the spec called a strut.</p>
<blockquote>
<p>An invisible character, but a visible impact.</p>
</blockquote>
<p>To resume, we’re facing the same previous problem as for siblings elements.</p>
<figure><img src="/content/01-blog/30-css-avance-metriques-des-fontes-line-height-et-vertical-align/vertical-align-strut.png"><figcaption class="caption">Each child is aligned as if its line-box starts with an invisible zero-width character</figcaption></figure>
<p>Baseline alignment is screwed, but what about <code>vertical-align: middle</code> to the rescue? As you can read in the spec, <code>middle</code> “aligns the vertical midpoint of the box with the baseline of the parent box plus half the x-height of the parent”. <strong>Baselines ratio are different, as well as x-height ratio, so <code>middle</code> alignment isn’t reliable either</strong>. Worst, in most scenarios, <code>middle</code> is never really “at the middle”. Too many factors are involved and cannot be set via CSS (x-height, ascender/descender ratio, etc.)</p>
<p>As a side note, there are 4 other values, that may be useful in some cases:</p>
<ul>
<li><code>vertical-align: top</code> / <code>bottom</code> align to the top or the bottom of the <em>line-box</em></li>
<li><code>vertical-align: text-top</code> / <code>text-bottom</code> align to the top or the bottom of the <em>content-area</em></li>
</ul>
<figure><img src="/content/01-blog/30-css-avance-metriques-des-fontes-line-height-et-vertical-align/vertical-align-top-bottom-text.png"><figcaption class="caption">Vertical-align: top, bottom, text-top and text-bottom</figcaption></figure>
<p>Be careful though, in all cases, it aligns the <em>virtual-area</em>, so the invisible height. Look at this simple example using <code>vertical-align: top</code>. <strong>Invisible <code>line-height</code> may produce odd, but unsurprising, results</strong>.</p>
<figure><img src="/content/01-blog/30-css-avance-metriques-des-fontes-line-height-et-vertical-align/vertical-align-top-virtual-height.png"><figcaption class="caption">vertical-align may produce odd result at first, but expected when visualizing line-height</figcaption></figure>
<p>Finally, <code>vertical-align</code> also accepts numerical values which raise or lower the box regarding to the baseline. That last option could come in handy.</p>
<h2 id="css-awesome">CSS is awesome<a href="#css-awesome" class="self-link"></a></h2>
<p>We’ve talked about how <code>line-height</code> and <code>vertical-align</code> work together, but now the question is: are font metrics controllable with CSS? Short answer: no. Even if I really hope so.
Anyway, I think we have to play a bit. Font metrics are constant, so we should be able to do something.</p>
<p>What if, for example, we want a text using the Catamaran font, where the capital height is exactly 100px high? Seems doable: let’s do some maths.</p>
<p>First we set all font metrics as CSS custom properties , then compute <code>font-size</code> to get a capital height of 100px.</p>
<pre><code>p {
    /* font metrics */
    --font: Catamaran;
    --fm-capitalHeight: 0.68;
    --fm-descender: 0.54;
    --fm-ascender: 1.1;
    --fm-linegap: 0;

    /* desired font-size for capital height */
    --capital-height: 100;

    /* apply font-family */
    font-family: var(--font);

    /* compute font-size to get capital height equal desired font-size */
    --computedFontSize: (var(--capital-height) / var(--fm-capitalHeight));
    font-size: calc(var(--computedFontSize) * 1px);
}</code></pre>
<figure><img src="/content/01-blog/30-css-avance-metriques-des-fontes-line-height-et-vertical-align/css-metrics-capital-height.png"><figcaption class="caption">The capital height is now 100px high</figcaption></figure>
<p>Pretty straightforward, isn’t it? But what if we want the text to be visually at the middle, so that the remaining space is equally distributed on top and bottom of the “B” letter? To achieve that, we have to compute <code>vertical-align</code> based on ascender/descender ratio.</p>
<p>First, compute <code>line-height: normal</code> and <em>content-area</em>’s height:</p>
<pre><code>p {
    …
    --lineheightNormal: (var(--fm-ascender) + var(--fm-descender) + var(--fm-linegap));
    --contentArea: (var(--lineheightNormal) * var(--computedFontSize));
}</code></pre>
<p>Then, we need:</p>
<ul>
<li>the distance from the bottom of the capital letter to the bottom edge</li>
<li>the distance from the top of the capital letter to the top edge</li>
</ul>
<p>Like so:</p>
<pre><code>p {
    …
    --distanceBottom: (var(--fm-descender));
    --distanceTop: (var(--fm-ascender) - var(--fm-capitalHeight));
}</code></pre>
<p>We can now compute <code>vertical-align</code>, which is the difference between the distances multiplied by the computed <code>font-size</code>. (we must apply this value to an inline child element)</p>
<pre><code>p {
    …
    --valign: ((var(--distanceBottom) - var(--distanceTop)) * var(--computedFontSize));
}
span {
    vertical-align: calc(var(--valign) * -1px);
}</code></pre>
<p>At the end, we set the desired <code>line-height</code> and compute it while maintaining a vertical alignment:</p>
<pre><code>p {
    …
    /* desired line-height */
    --line-height: 3;
    line-height: calc(((var(--line-height) * var(--capital-height)) - var(--valign)) * 1px);
}</code></pre>
<figure><img src="/content/01-blog/30-css-avance-metriques-des-fontes-line-height-et-vertical-align/css-metrics-results-line-height.png"><figcaption class="caption">Results with different line-height. The text is always on the middle</figcaption></figure>
<p>Adding an icon whose height is matching the letter “B” is now easy:</p>
<pre><code>span::before {
    content: '';
    display: inline-block;
    width: calc(1px * var(--capital-height));
    height: calc(1px * var(--capital-height));
    margin-right: 10px;
    background: url('https://cdn.pbrd.co/images/yBAKn5bbv.png');
    background-size: cover;
}</code></pre>
<figure><img src="/content/01-blog/30-css-avance-metriques-des-fontes-line-height-et-vertical-align/css-metrics-results-icon.png"><figcaption class="caption">Icon and B letter are the same height</figcaption></figure>
<p><a href="http://jsbin.com/tufatir/edit?css,output">See result in JSBin</a></p>
<p>Note that this test is for demonstration purpose only. You can’t rely on this. Many reasons:</p>
<ul>
<li>unless font metrics are constant, <a href="https://www.brunildo.org/test/normal-lh-plot.html">computations in browsers are not</a> ¯⁠\<em>⁠(ツ)⁠</em>/⁠¯</li>
<li>if font is not loaded, fallback font has probably different font metrics, and dealing with multiple values will quickly become quite unmanageable</li>
</ul>
<h2 id="takeaways">Takeaways<a href="#takeaways" class="self-link"></a></h2>
<p>What we learned:</p>
<ul>
<li>inline formatting context is really hard to understand</li>
<li>all inline elements have 2 height:
<ul>
<li>the <em>content-area</em> (based on font metrics)</li>
<li>the <em>virtual-area</em> (<code>line-height</code>)</li>
<li>none of these 2 heights can be visualize with no doubt. (if you're a devtools developer and want to work on this, it could be awesome)</li>
</ul></li>
<li><code>line-height: normal</code> is based on font metrics</li>
<li><code>line-height: n</code> may create a <em>virtual-area</em> smaller than <em>content-area</em></li>
<li><code>vertical-align</code> is not very reliable</li>
<li>a <em>line-box</em>’s height is computed based on its children’s <code>line-height</code> and <code>vertical-align</code> properties</li>
<li>we cannot easily get/set font metrics with CSS</li>
</ul>
<p>But I still love CSS :)</p>
</article>


<hr>

<footer>
  <p>
    <a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
        <use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-home"></use>
      </svg> Accueil</a> •
    <a href="/david/log/" title="Accès au flux RSS"><svg class="icon icon-rss2">
        <use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-rss2"></use>
      </svg> Suivre</a> •
    <a href="http://larlet.com" title="Go to my English profile" data-instant><svg class="icon icon-user-tie">
        <use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-user-tie"></use>
      </svg> Pro</a> •
    <a href="mailto:david%40larlet.fr" title="Envoyer un courriel"><svg class="icon icon-mail">
        <use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-mail"></use>
      </svg> Email</a> •
    <abbr class="nowrap" title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340"><svg class="icon icon-hammer2">
        <use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-hammer2"></use>
      </svg> Légal</abbr>
  </p>
  <template id="theme-selector">
      <form>
          <fieldset>
              <legend><svg class="icon icon-brightness-contrast">
                <use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-brightness-contrast"></use>
              </svg> Thème</legend>
              <label>
                  <input type="radio" value="auto" name="chosen-color-scheme" checked> Auto
              </label>
              <label>
                  <input type="radio" value="dark" name="chosen-color-scheme"> Foncé
              </label>
              <label>
                  <input type="radio" value="light" name="chosen-color-scheme"> Clair
              </label>
          </fieldset>
      </form>
  </template>
</footer>
<script src="/static/david/js/instantpage-5.1.0.min.js" type="module"></script>
<script>
    function loadThemeForm(templateName) {
        const themeSelectorTemplate = document.querySelector(templateName)
        const form = themeSelectorTemplate.content.firstElementChild
        themeSelectorTemplate.replaceWith(form)

        form.addEventListener('change', (e) => {
            const chosenColorScheme = e.target.value
            localStorage.setItem('theme', chosenColorScheme)
            toggleTheme(chosenColorScheme)
        })

        const selectedTheme = localStorage.getItem('theme')
        if (selectedTheme && selectedTheme !== 'undefined') {
            form.querySelector(`[value="${selectedTheme}"]`).checked = true
        }
    }

    const prefersColorSchemeDark = '(prefers-color-scheme: dark)'
    window.addEventListener('load', () => {
        let hasDarkRules = false
        for (const styleSheet of Array.from(document.styleSheets)) {
            let mediaRules = []
            for (const cssRule of styleSheet.cssRules) {
                if (cssRule.type !== CSSRule.MEDIA_RULE) {
                    continue
                }
                // WARNING: Safari does not have/supports `conditionText`.
                if (cssRule.conditionText) {
                    if (cssRule.conditionText !== prefersColorSchemeDark) {
                        continue
                    }
                } else {
                    if (cssRule.cssText.startsWith(prefersColorSchemeDark)) {
                        continue
                    }
                }
                mediaRules = mediaRules.concat(Array.from(cssRule.cssRules))
            }

            // WARNING: do not try to insert a Rule to a styleSheet you are
            // currently iterating on, otherwise the browser will be stuck
            // in a infinite loop…
            for (const mediaRule of mediaRules) {
                styleSheet.insertRule(mediaRule.cssText)
                hasDarkRules = true
            }
        }
        if (hasDarkRules) {
            loadThemeForm('#theme-selector')
        }
    })
</script>
</body>
</html>