Stream

A definition list inside a blockquote with a sublist in one of its items is an interesting case for Markdown and its layout.

The problem came up in the Hugo-forum and it was not clear to at first. So I created two demos. The original question was not about the layout, only about the resulting HTML code.*

Bullet list inside of definition list

Version 1

> He adds up:
> : - The cost of raw materials to be processed
>   - The wages
>   - The consumption of the machines, their wear and tear and the interest on the money they cost him:
>     - The selling expenses: transport. brokerage. discounts.
>     - The general expenses: administration, rents, taxes. insurance etc.
> {.dl-loose}

gets rendered to:

<blockquote>
<dl class="dl-loose">
<dt>He adds up:</dt>
<dd><ul>
<li>The cost of raw materials to be processed</li>
<li>The wages</li>
<li>The consumption of the machines, their wear and tear and the interest on the money they cost him:
<ul>
<li>The selling expenses: transport. brokerage. discounts.</li>
<li>The general expenses: administration, rents, taxes. insurance etc.</li>
</ul>
</li>
</ul>
</dd>
</dl>
</blockquote>

and looks like:

Version 2

> He adds up:
> : The cost of raw materials to be processed
> : The wages
> : The consumption of the machines, their wear and tear and the interest on the money they cost him:
>   - The selling expenses: transport. brokerage. discounts.
>   - The general expenses: administration, rents, taxes. insurance etc.
> {.dl-loose}

gets rendered to:

<blockquote>
<dl class="dl-loose">
<dt>He adds up:</dt>
<dd>The cost of raw materials to be processed</dd>
<dd>The wages</dd>
<dd>The consumption of the machines, their wear and tear and the interest on the money they cost him:
<ul>
<li>The selling expenses: transport. brokerage. discounts.</li>
<li>The general expenses: administration, rents, taxes. insurance etc.</li>
</ul>
</dd>
</dl>
</blockquote>

and looks like:

Markdown is very sensitive to indentation, when combining various formatting signs and attributes. We need to align our code perfectly.

The HTML code is the expected one, which markup fits the content in the best way is a matter of taste. The layout of the theme is alright in both cases.

Nested definition lists are tricky and another request for the opposite problem came up after that.

Definition list nested inside a bullet list

This time without a surrounding blockquote.

- **1980**
  : blablabl
- **1988**
  : blabla
  : blabla

gets rendered to:

<ul>
<li>
<dl>
<dt><strong>1980</strong></dt>
<dd>blablabl</dd>
</dl>
</li>
<li>
<dl>
<dt><strong>1988</strong></dt>
<dd>blabla</dd>
<dd>blabla</dd>
</dl>
</li>
</ul>

and looks like:

And again the correct indentation leads to correct HTML.

I don’t know the context, but maybe a simpler solution without the bullets could serve the same purpose:

1980
: blablabl

1988
: blabla
: blabla

gets rendered to:

<dl>
<dt>1980</dt>
<dd>blablabl</dd>
<dt>1988</dt>
<dd>blabla</dd>
<dd>blabla</dd>
</dl>

and looks like:

Markdown only has two basic layout modes: inline & block. Before we think about applying others with an attribute or a shortcode, we need to understand them.

The distinction between those two in Markdown seems simple. Every block is surrounded by at least one blank line. Everything written on the same or the directly following line is inline — except lists and their items. We usually don’t need to think about layout modes and use them intuitively correct. One problematic element is the main reason to recall the distinction:

Inline elements

behave like characters and may be embedded in text. They are placed on the same line as long as there is any horizontal space left — and then the line wraps and so on. They may contain other inline elements — like a piece of code in emphasis for example. Inline elements shouldn’t include block elements, but they always need to be embedded in block elements.

Block elements

always completely fill the available width and may include additional vertical space. Block elements may contain other block elements or inline elements. A common example for the latter is a paragraph block, which fills at least one line, but may include an arbitrary amount of inline elements and text.

The Markdown image element is creating some confusion, because its an inline element. Because many images appear visually as blocks, we falsely tend to infer they should be block elements. But a Markdown image is always inline and embedded in an enclosing block. When its placed stand-alone on a separated line, its not only an image but enclosed in a paragraph block of its own.

To generate a stand-alone image resulting in semantically correct HTML, we need the figure shortcode. And we can easily add CSS-styles to resize or move the resulting figure — even beside the main text column.

There are some doubts about the accessibility of fluid typography among web developers. But websites with a responsive fluid design can behave especially user-friendly and accessible. This site is an example.

Fluid fonts solely depend on the width of the browser window or the view-port width of the mobile device. When a user changes the zoom-factor of his browser or his device, they are not affected at all. That’s the problem with fluid sized fonts. The solution is obvious: We need to change their value accordingly, when we change the layout responsively.

They are not suitable for every possible width. For various reasons we shouldn’t deviate to much from the default browser font-size on mobile devices. Responsive fluid design is beneficial on larger screens — phablet sizes and up. Breakpoints depending on the ‘em’-unit allow to fit our fluid text precisely into the variants of our responsive layout. On large desktop screens we need to stop the fluid growth again, because their height is usually more restricted than their width.

A responsive fluid layout changes to a larger or smaller version in our favor as soon as a breakpoint is reached — wether we change the width or change our zoom setting. And not only the fonts but the size of all elements will change accordingly, if they consequently rely on the same fluid base font-size. We may have to change the zoom setting by a larger step sometimes, to make a layout change happen — but that’s all there is to it.

Just give it a try with Ctrl + + and Ctrl + - or the zoom setting of your desktop browser. You will be surprised how well you can zoom in or out of this layout. Even the images get reloaded in a higher resolution, if necessary.

Marginal notes allow to add further information in an elegant and unobtrusive way. We can glance over them and stay with the main text or zone out for a while, when they pique our curiosity.

The famous mathematician Fermat wrote his last conjecture around 1637 in the marginal column besides an ancient Greek proof by Diophantus. The “marvelous proof” Fermat mentioned there has never been uncovered, but his note kept mathematicians busy for over 350 years — until one of them could actually proof his hypothesis after years of ground-breaking work.

Diophantus’ proof and Fermat’s conjecture in plain English:

To divide a given square into a sum of two squares.

To divide 16 into a sum of two squares.

Let the first summand be x², and thus the second 16 – x². The latter is to be a square. I form the square of the difference of an arbitrary multiple of x diminished by the root of 16, that is, diminished by 4. I form, for example, the square of 2x – 4. It is 4x² + 16 – 16x. I put this expression equal to 16 – x². I add to both sides x² + 16x and subtract 16. In this way I obtain 5x² = 16x, hence x = ¹⁶⁄₅

Thus one number is ²⁵⁶⁄₂₅ and the other ¹⁴⁴⁄₂₅. The sum of these numbers is 16 and each summand is a square.

Like to use marginal notes? Have a look at the shortcode mnote.