Skip to content

Commit

Permalink
Merge sumbach:a-vs-an
Browse files Browse the repository at this point in the history
  • Loading branch information
mixu committed Feb 3, 2016
2 parents be3ed78 + 9fbefbe commit 986b18a
Show file tree
Hide file tree
Showing 4 changed files with 18 additions and 18 deletions.
22 changes: 11 additions & 11 deletions input/1-positioning.md
Expand Up @@ -31,7 +31,7 @@ Both floats and absolute positioning can be best understood through how they int

If you think about it, there are actually two aspects of layout that are at play:

- how the box of a element is sized and aligned, which is primarily controlled by the `display` property (and `width`, `height` and `margin`).
- how the box of an element is sized and aligned, which is primarily controlled by the `display` property (and `width`, `height` and `margin`).
- how elements within a particular parent element are positioned relative to each other

In this chapter, I'll focus on the latter aspect - relative positioning. The next chapter covers the box model, which determines alignment and sizing.
Expand All @@ -54,21 +54,21 @@ Almost all block-level boxes are also block container boxes. A block container b

> Except for table boxes [...] and replaced elements, a block-level box is also a block container box. A block container box either contains only block-level boxes or establishes an inline formatting context and thus contains only inline-level boxes. [Source](http://www.w3.org/TR/CSS2/visuren.html#block-level)
And a inline-level element is defined as:
And an inline-level element is defined as:

> Inline-level elements are those elements of the source document that do not form new blocks of content; the content is distributed in lines (e.g., emphasized pieces of text within a paragraph, inline images, etc.). The following values of the 'display' property make an element inline-level: 'inline', 'inline-table', and 'inline-block'. Inline-level elements generate inline-level boxes, which are boxes that participate in an inline formatting context.
> An inline box is one that is both inline-level and whose contents participate in its containing inline formatting context. A non-replaced element with a 'display' value of 'inline' generates an inline box. Inline-level boxes that are not inline boxes (such as replaced inline-level elements, inline-block elements, and inline-table elements) are called atomic inline-level boxes because they participate in their inline formatting context as a single opaque box. [Source](http://www.w3.org/TR/CSS2/visuren.html#inline-level)
I won't really talk about replaced vs non-replaced elements, since it is a fairly minor distinction. The easiest way to think about replaced elements is to think about a `img` or `video` element - that is, an element that simply has a single (externally defined) content that cannot be broken up into lines like text content can.
I won't really talk about replaced vs non-replaced elements, since it is a fairly minor distinction. The easiest way to think about replaced elements is to think about an `img` or `video` element - that is, an element that simply has a single (externally defined) content that cannot be broken up into lines like text content can.

You can roughly think of the two formatting contexts in normal flow to correspond to vertical stacking (when in a block formatting context) and horizontal stacking (when in an inline formatting context). I'll cover both in a moment.

The interesting thing about the definitions above is that the formatting context of every box must either be "inline formatting context" or "block formatting context". That is, all child elements are laid out using one type of formatting context for each parent element. How can this be, when you can clearly mix block-level content like divs and inline-level content such as text? The answer is that there is a mechanism by which inline-level elements can be promoted to block-level elements. This mechanism is known as anonymous box generation.

## Anonymous box generation

Anonymous box generation is used to deal with cases where a parent element contains a mixture of inline-level and block-level child elements (in which case "anonymous block boxes" are generated) and with cases where the markup contains inline-level elements mixed with surrounding text (in which case "anonymous inline boxes" are generated), such as a `em` or `i` tag inside a paragraph of text.
Anonymous box generation is used to deal with cases where a parent element contains a mixture of inline-level and block-level child elements (in which case "anonymous block boxes" are generated) and with cases where the markup contains inline-level elements mixed with surrounding text (in which case "anonymous inline boxes" are generated), such as an `em` or `i` tag inside a paragraph of text.

### Anonymous block boxes

Expand All @@ -95,7 +95,7 @@ In short, when inline-level and block-level boxes are mixed in a single parent e

### Anonymous inline boxes

Anonymous inline boxes are generated when a block container element contains text that is not enclosed within a inline-level element. For example, the markup:
Anonymous inline boxes are generated when a block container element contains text that is not enclosed within an inline-level element. For example, the markup:

```html
<p>Some <em>emphasized</em> text</p>
Expand Down Expand Up @@ -172,7 +172,7 @@ In short, within an inline formatting context boxes are laid out horizontally on
>
> In general, the left edge of a line box touches the left edge of its containing block and the right edge touches the right edge of its containing block. [Line boxes] may vary in width if available horizontal space is reduced due to floats. Line boxes in the same inline formatting context generally vary in height (e.g., one line might contain a tall image while the others contain only text).
What happens when a inline box is too large for a line box? It depends on whether the inline box is replaced (e.g. a video or a image) or non-replaced (text etc.):
What happens when an inline box is too large for a line box? It depends on whether the inline box is replaced (e.g. a video or an image) or non-replaced (text etc.):

> When an inline box exceeds the width of a line box, it is split into several boxes and these boxes are distributed across several line boxes. If an inline box cannot be split [...], then the inline box overflows the line box.
>
Expand Down Expand Up @@ -224,7 +224,7 @@ The height of (non-replaced) inline boxes is defined as follows ([source](http:/
> The vertical padding, border and margin of an inline, non-replaced box start at the top and bottom of the content area, and has nothing to do with the 'line-height'. But only the 'line-height' is used when calculating the height of the line box.
As you can see from the parts of the spec shown above, the height of inline boxes is determined by their font and their line height. Specifically, each font must define a baseline, a text-top edge and a text-bottom edge. The calculated height of the content area of a inline box is the height of the font (e.g. bottom - top) multiplied by the line-height value:
As you can see from the parts of the spec shown above, the height of inline boxes is determined by their font and their line height. Specifically, each font must define a baseline, a text-top edge and a text-bottom edge. The calculated height of the content area of an inline box is the height of the font (e.g. bottom - top) multiplied by the line-height value:

> On a non-replaced inline element, 'line-height' specifies the height that is used in the calculation of the line box height.
Expand Down Expand Up @@ -352,7 +352,7 @@ The next example illustrates how the inline-block vertical centering technique w

I've added a couple of additional styles to better show the different parts that allow this technique for vertical centering to work. As you can see in the example above:

- the inner blocks inside the container are `display: inline-block`, meaning they are treated as inline-level boxes and produce a inline formatting context, but their contents behave like `display: block` elements (for example, setting `width: 100%` works!).
- the inner blocks inside the container are `display: inline-block`, meaning they are treated as inline-level boxes and produce an inline formatting context, but their contents behave like `display: block` elements (for example, setting `width: 100%` works!).
- the container has `text-align: center` to cause the inline-level blocks to be centered on each line box.
- the content block has `vertical-align: middle` set on it, which aligns it vertically relative to all the other content on the line box.
- a pseudo-element with `height: 100%` is added to the end of the container. It is shown in green. This is necessary because without it, the content block would simply be positioned at the top of the flow, because it would exist on its own on a single line box, and the line box height would simply match the content block, which would mean that there would be nothing to align it with.
Expand Down Expand Up @@ -408,7 +408,7 @@ Putting these pieces together took a while. First, `x-height` is not the same th
>The x-height of a font can be found in different ways. Some fonts contain reliable metrics for the x-height. If reliable font metrics are not available, UAs may determine the x-height from the height of a lowercase glyph. One possible heuristic is to look at how far the glyph for the lowercase "o" extends below the baseline, and subtract that value from the top of its bounding box. In the cases where it is impossible or impractical to determine the x-height, a value of 0.5em should be used.
So, an x-height is literally the height of a x character in the font rather than half the height of the parent element.
So, an x-height is literally the height of an x character in the font rather than half the height of the parent element.

Now, when the spec says "parent box", what does that mean? It turns out that they mean the line box, not the container box which establishes the inline formatting context. Let me illustrate:

Expand Down Expand Up @@ -736,7 +736,7 @@ There are three ways to accomplish this:
- adding an element with `clear: both` using pseudo-elements at the end of the parent
- making the parent element establish a new formatting context using a property such as `overflow: hidden` or `overflow: auto`

The example in the section on clearing floats illustrated the first approach: explicitly adding a element which clears floats will prevent the floats from interacting with subsequent elements. However, explicitly adding an element into markup to achieve a particular layout is bad - it breaks the contract that the markup should not be concerned with layout.
The example in the section on clearing floats illustrated the first approach: explicitly adding an element which clears floats will prevent the floats from interacting with subsequent elements. However, explicitly adding an element into markup to achieve a particular layout is bad - it breaks the contract that the markup should not be concerned with layout.

Instead of explicitly adding an element, we can use the `:after` pseudo element to insert additional content at the end of the `.clearfix`ed div. Here's what a basic clearfix following that pattern would look like:

Expand Down Expand Up @@ -837,7 +837,7 @@ In this example, the floated blocks are also offset from the top so that they ov

The first row uses the `overflow: auto` fix to cause the parent element establish a new formatting context. However, as a side effect, it also alters how `overflow` works, causing overflowing content to be scrollable rather than visible.

The second row uses the pseudo-element approach, which adds an pseudo element with `clear: both` at the end of the row. This keeps the default `overflow: visible` value, which means that the overflowed floats are still visible.
The second row uses the pseudo-element approach, which adds a pseudo element with `clear: both` at the end of the row. This keeps the default `overflow: visible` value, which means that the overflowed floats are still visible.

## Absolute / fixed positioning scheme

Expand Down
4 changes: 2 additions & 2 deletions input/3-additional.md
Expand Up @@ -8,7 +8,7 @@ Now that we have discussed how the box model properties vary across different el

- *Margin collapsing* affects adjacent margins so that only the larger of two margins is applied.
- *Negative margins*. Negative values (e.g. `-10px`) are allowed for margins, and these can be used to position content.
- *Overflow*. When the content inside a container box is larger than its parent or positioned at a offset that is beyond the parent's box, it overflows. The `overflow` property controls how this is handled.
- *Overflow*. When the content inside a container box is larger than its parent or positioned at an offset that is beyond the parent's box, it overflows. The `overflow` property controls how this is handled.
- *max-width, max-height, min-width, min-height*, Width and height can be further constrained by using the `max-width`, `max-height`, `min-width` and `min-height` properties.
- *Pseudo-elements* allow additional elements to be generated within the selected element from CSS. They are often used to generate additional content for layout or for to provide a particular visual appearance.
- *Stacking contexts and rendering order* determine the z-axis rendering of boxes.
Expand Down Expand Up @@ -172,7 +172,7 @@ Overflow occurs when a child element is either positioned outside its parent ele
| Property | Default value | Purpose
|-----------|------------------------------------------------------------------
| overflow | visible | Controls how child elements that are larger than their parent elements are handled. Not applicable to `display: inline` elements. Applying a `overflow` value other than `visible` creates a *block formatting context*.
| overflow | visible | Controls how child elements that are larger than their parent elements are handled. Not applicable to `display: inline` elements. Applying an `overflow` value other than `visible` creates a *block formatting context*.

The `overflow` property can take the following values. The default value is `visible`:

Expand Down
4 changes: 2 additions & 2 deletions input/4-flexbox.md
Expand Up @@ -64,7 +64,7 @@ However, absolutely positioned children are excluded.

> An absolutely-positioned child of a flex container does not participate in flex layout. However, it does participate in the reordering step (see order), which has an effect in their painting order. [source](http://www.w3.org/TR/css3-flexbox/#abspos-items)
What does it mean for a in-flow child to become a flex item?
What does it mean for an in-flow child to become a flex item?

> The `display` value of a flex item is blockified: if the specified display of an in-flow child of an element generating a flex container is an inline-level value, it computes to its block-level equivalent.
>
Expand Down Expand Up @@ -109,7 +109,7 @@ The `row` and `column` directions do what you would expect. You can also reverse

## Flex container properties: flex lines

Like a inline block formatting context, a flexbox container's contents can be laid out on multiple lines.
Like an inline block formatting context, a flexbox container's contents can be laid out on multiple lines.

> Flex items in a flex container are laid out and aligned within *flex lines*, hypothetical containers used for grouping and alignment by the layout algorithm.
Expand Down
6 changes: 3 additions & 3 deletions input/5-tricks.md
Expand Up @@ -64,7 +64,7 @@ Setting `position: relative` does not affect the positioning of elements in norm

*Positioning with constraints*. There are many interesting things that you can do with `position: absolute` elements as well as the `width` of `display: block` elements. For absolutely positioned elements, it is possible to trigger a contraint-based size calculation in both the horizontal and vertical axes; for `display: block` elements this only works for horizontal sizing.

For example, let's say you want to position a box in on the left or right side of a parent box while keeping it centered vertically. This could, for example, be the left and right navigation buttons on a image carousel. To accomplish this, you could set the parent to `position: relative`, and then use something like this:
For example, let's say you want to position a box in on the left or right side of a parent box while keeping it centered vertically. This could, for example, be the left and right navigation buttons on an image carousel. To accomplish this, you could set the parent to `position: relative`, and then use something like this:

```snippet
<div class="parent blue">
Expand Down Expand Up @@ -118,7 +118,7 @@ Next, grid frameworks use four techniques to achieve their behavior:

*Percentage-based width*. The grid columns have a `width` value defined as a percentage of the parent box. The framework ensures that the widths add up to `100%`, taking into account issues that can arise with rounding. This means that the columns will always fit onto a single row of in the grid framework and take up some divisor of the total width.

For example, in a 12-column layout, a 1-column float will have `1/12` of the available width (as a percentage) assigned to it. Placing a 4-column float with a 8-column float allows for a 33%:66% split of the available space.
For example, in a 12-column layout, a 1-column float will have `1/12` of the available width (as a percentage) assigned to it. Placing a 4-column float with an 8-column float allows for a 33%:66% split of the available space.

*Relative positioning*. The grid columns typically have `position: relative` as a default to make them act as the reference point for any absolutely positioned content.

Expand Down Expand Up @@ -268,7 +268,7 @@ Here are two ways to make the example above work:
For solution 1, you cannot set `line-height` to `100%`, because line height is relative to parent font height, not parent container height.
For solution 2, you need to use a inline-block because normal inline-level boxes do not have a `height` property and hence cannot reference the parent height. A pseudo-element is preferable to a real element because it requires fewer changes in markup.
For solution 2, you need to use an inline-block because normal inline-level boxes do not have a `height` property and hence cannot reference the parent height. A pseudo-element is preferable to a real element because it requires fewer changes in markup.
```

## Horizontal and vertical centering
Expand Down

0 comments on commit 986b18a

Please sign in to comment.