), but it is also descended from a div whose class contains the word one. Both rules match, and so both apply. Since there is a conflict, the cas‐ cade is used to resolve the conflict, and the second rule wins. The structural arrange‐ ment of the markup, with the div.two being “closer” to the paragraph than div.one, is irrelevant. Pseudo-Class Selectors | 91 Pseudo-Element Selectors Much as pseudo-classes assign phantom classes to anchors, pseudo-elements insert fictional elements into a document in order to achieve certain effects. Four basic pseudo-elements were defined in CSS 2, and they let you style the first letter of an element, style the first line of an element, and both create and style “before” and “after” content. There are other pseudo-classes that have been defined since CSS 2 (e.g., ::marker), and we’ll explore those in the chapters of the book for which they’re relevant. The four from CSS2 will be covered here because they’re old-school, and because they make a convenient way to talk about pseudo-element behavior. Unlike the single colon of pseudo-classes, pseudo-elements employ a double-colon syntax, like ::first-line. This is meant to distinguish pseudo-elements from pseudo-classes. This was not always the case—in CSS2, both selector types used a sin‐ gle colon—so for backward compatibility, browsers will accept single-colon pseudoelement selectors. Don’t take this as an excuse to be sloppy, though! Use the proper number of colons at all times in order to future-proof your CSS; after all, there is no way to predict when browsers will stop accepting single-colon pseudo-element selec‐ tors. Note that all pseudo-elements must be placed at the very end of the selector in which they appear. It would not be legal to write p::first-line em since the pseudoelement comes before the subject of the selector (the subject is the last element listed). This also means that only one pseudo-element is permitted in a given selector, though that restriction may be eased in future versions of CSS. Styling the First Letter The ::first-letter pseudo-element styles the first letter, or a leading punctuation character and the first letter (if the text starts with punctuation), of any non-inline element. This rule causes the first letter of every paragraph to be colored red: p::first-letter {color: red;} The ::first-letter pseudo-element is most commonly used to create an “initial cap” or “drop cap” typographic effect. You could make the first letter of each p twice as big as the rest of the heading, though you may want to only apply this styling to the first letter of the first paragraph: p:first-of-type::first-letter {font-size: 200%;} The result of this rule is illustrated in Figure 2-45. Figure 2-45. The ::first-letter pseudo-element in action 92 | Chapter 2: Selectors This rule effectively causes the user agent to style a fictional, or “faux” element, that encloses the first letter of each p. It would look something like this:

This is a p element, with a styled first letter The ::first-letter styles are applied only to the contents of the fictional element shown in the example. This element does not appear in the docu‐ ment source, nor even in the DOM tree. Instead, its existence is constructed on the fly by the user agent and is used to apply the ::first-letter style(s) to the appropri‐ ate bit of text. In other words, is a pseudo-element. Remember, you don’t have to add any new tags. The user agent styles the first letter for you as if you had encased it in a styled element. The first letter is defined as the first typographic letter unit of the originating element, if it is not preceded by other content, like an image. The specifications use “letter unit” because some languages have letters made up of more than character, like “oe” in Norse. Punctuation that precedes or follows the first letter unit, even if there are several such symbols, are included in the ::first-letter pseudo-element. Styling the First Line Similarly, ::first-line can be used to affect the first line of text in an element. For example, you could make the first line of each paragraph in a document large and purple: p::first-line { font-size: 150%; color: purple; } In Figure 2-46, the style is applied to the first displayed line of text in each paragraph. This is true no matter how wide or narrow the display region is. If the first line con‐ tains only the first five words of the paragraph, then only those five words will be big and purple. If the first line contains the first 30 words of the element, then all 30 will be big and purple. Figure 2-46. The ::first-line pseudo-element in action Because the text from “This” to “only” should be big and purple, the user agent employs a fictional markup that looks something like this: Pseudo-Element Selectors | 93 

This is a paragraph of text that has only one stylesheet applied to it. That style causes the first line to be big and purple. No other line will have those styles applied.

If the first line of text were edited to include only the first seven words of the para‐ graph, then the fictional would move back and occur just after the word “that.” If the user were to increase or decrease the font-size rendering, or expand or contract the browser window causing the width of the text to change, thereby causing the number of words on the first line to increase or decrease, the browser automatically sets only the words in the currently displayed first line to be both big and purple. The length of the first line depends on a number of factors, including the font-size, letter spacing, width of the parent container, etc. Depending on the markup, and the length of that first line, it is possible that the end of the first line comes in the middle of a nested element. If the ::first-line breaks up a nested element, such as an em or a hyperlink, the properties attached to the ::first-line will only apply to the por‐ tion of that nested element that is displayed on the first line. Restrictions on ::first-letter and ::first-line The ::first-letter and ::first-line pseudo-elements currently can be applied only to block-display elements such as headings or paragraphs, and not to inlinedisplay elements such as hyperlinks. There are also limits on the CSS properties that may be applied to ::first-line and ::first-letter. Table 2-5 gives an idea of these limitations. Table 2-5. Properties permitted on pseudo-elements ::first-letter ::first-line • • • • • • • • • • • • • • • • • • 94 All font properties All background properties All text decoration properties All inline typesetting properties All inline layout properties All border properties box-shadow color opacity | Chapter 2: Selectors All font properties All background properties All margin properties All padding properties All border properties All text decoration properties All inline typesetting properties color opacity Styling (or Creating) Content Before and After Elements Let’s say you want to preface every h2 element with a pair of silver square brackets as a typographical effect: h2::before {content: "]]"; color: silver;} CSS lets you insert generated content, and then style it directly using the pseudoelements ::before and ::after. Figure 2-47 illustrates an example. Figure 2-47. Inserting content before an element The pseudo-element is used to insert the generated content and to style it. To place content after an element, use the pseudo-element ::after. You could end your docu‐ ments with an appropriate finish: body::after {content: "The End.";} Generated content is a separate subject, and the entire topic (including more detail on ::before and ::after) is covered more thoroughly in Chapter 15. Summary By using selectors based on the document’s language, authors can create CSS rules that apply to a large number of similar elements just as easily as they can construct rules that apply in very narrow circumstances. The ability to group together both selectors and rules keeps stylesheets compact and flexible, which incidentally leads to smaller file sizes and faster download times. Selectors are the one thing that user agents usually must get right because the inability to correctly interpret selectors pretty much prevents a user agent from using CSS at all. On the flip side, it’s crucial for authors to correctly write selectors because errors can prevent the user agent from applying the styles as intended. An integral part of correctly understanding selectors and how they can be combined is a strong grasp of how selectors relate to document structure and how mechanisms—such as inheri‐ tance and the cascade itself—come into play when determining how an element will be styled. Summary | 95 CHAPTER 3 Specificity and the Cascade Chapter 2 showed how document structure and CSS selectors allow you to apply a wide variety of styles to elements. Knowing that every valid document generates a structural tree, you can create selectors that target elements based on their ancestors, attributes, sibling elements, and more. The structural tree is what allows selectors to function and is also central to a similarly crucial aspect of CSS: inheritance. Inheritance is the mechanism by which some property values are passed on from an element to its descendants. When determining which values should apply to an ele‐ ment, a user agent must consider not only inheritance but also the specificity of the declarations, as well as the origin of the declarations themselves. This process of con‐ sideration is what’s known as the cascade. We will explore the interrelation between these three mechanisms—specificity, inheritance, and the cascade—in this chapter, but the difference between the latter two can be summed up this way: choosing the result of h1 {color: red; color: blue;} is the cascade; making a span inside the h1 blue is inheritance. Above all, regardless of how abstract things may seem, keep going! Your perseverance will be rewarded. Specificity You know from Chapter 2 that you can select elements using a wide variety of means. In fact, it’s possible that the same element could be selected by two or more rules, each with its own selector. Let’s consider the following three pairs of rules. Assume that each pair will match the same element: h1 {color: red;} body h1 {color: green;} h2.grape {color: purple;} 97 h2 {color: silver;} html > body table tr[id="totals"] td ul > li {color: maroon;} li#answer {color: navy;} Only one of the two rules in each pair can win out, since the matched elements can be only one color or the other. How do we know which one will win? The answer is found in the specificity of each selector. For every rule, the user agent evaluates the specificity of the selector and attaches it to each declaration in the rule. When an element has two or more conflicting property declarations, the one with the highest specificity will win out. This isn’t the whole story in terms of conflict resolution. All style conflict resolution (including specificity) is handled by the cascade, which has its own section later in this chapter (“The Cascade” on page 106). A selector’s specificity is determined by the components of the selector itself. A spe‐ cificity value can be expressed in four parts, like this: 0,0,0,0. The actual specificity of a selector is determined as follows: • For every ID attribute value given in the selector, add 0,1,0,0. • For every class attribute value, attribute selection, or pseudo-class given in the selector, add 0,0,1,0. • For every element and pseudo-element given in the selector, add 0,0,0,1. CSS2 contradicted itself as to whether pseudo-elements had any specificity at all, but CSS2.1 made it clear that they do, and this is where they belong. • Combinators and the universal selector do not contribute anything to the specif‐ icity. For example, the following rules’ selectors result in the indicated specificities: h1 {color: red;} p em {color: purple;} .grape {color: purple;} *.bright {color: yellow;} p.bright em.dark {color: maroon;} #id216 {color: blue;} div#sidebar *[href] {color: silver;} /* /* /* /* /* /* /* specificity specificity specificity specificity specificity specificity specificity = = = = = = = 0,0,0,1 0,0,0,2 0,0,1,0 0,0,1,0 0,0,2,2 0,1,0,0 0,1,1,1 */ */ */ */ */ */ */ Given a case where an em element is matched by both the second and fifth rules in this example, that element will be maroon because the fifth rule’s specificity out‐ weighs the second’s. 98 | Chapter 3: Specificity and the Cascade As an exercise, let’s return to the pairs of rules from earlier in the section and fill in the specificities: h1 {color: red;} body h1 {color: green;} h2.grape {color: purple;} h2 {color: silver;} /* 0,0,0,1 */ /* 0,0,0,2 (winner)*/ /* 0,0,1,1 (winner) */ /* 0,0,0,1 */ html > body table tr[id="totals"] td ul > li {color: maroon;} li#answer {color: navy;} (winner) */ /* 0,0,1,7 */ /* 0,1,0,1 I’ve indicated the winning rule in each pair; in each case, it’s because the specificity is higher. Notice how they’re sorted. In the second pair, the selector h2.grape wins because it has an extra 1: 0,0,1,1 beats out 0,0,0,1. In the third pair, the second rule wins because 0,1,0,1 wins out over 0,0,1,7. In fact, the specificity value 0,0,1,0 will win out over the value 0,0,0,13. This happens because the values are sorted from left to right. A specificity of 1,0,0,0 will win out over any specificity that begins with a 0, no matter what the rest of the numbers might be. So 0,1,0,1 wins over 0,0,1,7 because the 1 in the first value’s second position beats out the 0 in the second value’s second position. Declarations and Specificity Once the specificity of a selector has been determined, the specificity value will be conferred on all of its associated declarations. Consider this rule: h1 {color: silver; background: black;} For specificity purposes, the user agent must treat the rule as if it were “ungrouped” into separate rules. Thus, the previous example would become: h1 {color: silver;} h1 {background: black;} Both have a specificity of 0,0,0,1, and that’s the value conferred on each declaration. The same splitting-up process happens with a grouped selector as well. Given the rule: h1, h2.section {color: silver; background: black;} the user agent treats it if it were the following: h1 {color: silver;} h1 {background: black;} h2.section {color: silver;} h2.section {background: black;} /* /* /* /* 0,0,0,1 0,0,0,1 0,0,1,1 0,0,1,1 */ */ */ */ Specificity | 99 This becomes important in situations where multiple rules match the same element and some of the declarations clash. For example, consider these rules: h1 + p {color: black; font-style: italic;} /* 0,0,0,2 */ p {color: gray; background: white; font-style: normal;} /* 0,0,0,1 */ *.aside {color: black; background: silver;} /* 0,0,1,0 */ When applied to the following markup, the content will be rendered as shown in Figure 3-1:

Greetings!

It's a fine way to start a day, don't you think?

There are many ways to greet a person, but the words are not as important as the act of greeting itself.

Salutations!

There is nothing finer than a hearty welcome from one's fellow man.

Although a thick and juicy hamburger with bacon and mushrooms runs a close second.

Figure 3-1. How different rules affect a document In every case, the user agent determines which rules match a given element, calculates all of the associated declarations and their specificities, determines which rules win out, and then applies the winners to the element to get the styled result. These machi‐ nations must be performed on every element, selector, and declaration. Fortunately, the user agent does it all automatically. This behavior is an important component of the cascade, which we will discuss later in this chapter. 100 | Chapter 3: Specificity and the Cascade Universal Selector Specificity The universal selector does not contribute to specificity. In other words, it has a spe‐ cificity of 0,0,0,0, which is different than having no specificity (as we’ll discuss in “Inheritance” on page 103). Therefore, given the following two rules, a paragraph descended from a div will be black, but all other elements will be gray: div p {color: black;} /* 0,0,0,2 */ * {color: gray;} /* 0,0,0,0 */ As you might expect, this means the specificity of a selector that contains a universal selector along with other selectors is not changed by the presence of the universal selector. The following two selectors have exactly the same specificity: div p /* 0,0,0,2 */ body * strong /* 0,0,0,2 */ Combinators, by comparison, have no specificity at all—not even zero specificity. Thus, they have no impact on a selector’s overall specificity. ID and Attribute Selector Specificity It’s important to note the difference in specificity between an ID selector and an attribute selector that targets an id attribute. Returning to the third pair of rules in the example code, we find: html > body table tr[id="totals"] td ul > li {color: maroon;} /* 0,0,1,7 */ li#answer {color: navy;} /* 0,1,0,1 (wins) */ The ID selector (#answer) in the second rule contributes 0,1,0,0 to the overall spe‐ cificity of the selector. In the first rule, however, the attribute selector ([id="totals"]) contributes 0,0,1,0 to the overall specificity. Thus, given the fol‐ lowing rules, the element with an id of meadow will be green: #meadow {color: green;} /* 0,1,0,0 */ *[id="meadow"] {color: red;} /* 0,0,1,0 */ Inline Style Specificity So far, we’ve only seen specificities that begin with a zero, so you may be wondering why it’s there at all. As it happens, that first zero is reserved for inline style declara‐ tions, which trump any other declaration’s specificity. Consider the following rule and markup fragment: h1 {color: red;}

The Meadow Party

Specificity | 101 Given that the rule is applied to the h1 element, you would still probably expect the text of the h1 to be green. This happens because every inline declaration has a specif‐ icity of 1,0,0,0. This means that even elements with id attributes that match a rule will obey the inline style declaration. Let’s modify the previous example to include an id: h1#meadow {color: red;}

The Meadow Party

Thanks to the inline declaration’s specificity, the text of the h1 element will still be green. Importance Sometimes, a declaration is so important that it outweighs all other considerations. CSS calls these important declarations (for hopefully obvious reasons) and lets you mark them by inserting !important just before the terminating semicolon in a decla‐ ration: p.dark {color: #333 !important; background: white;} Here, the color value of #333 is marked !important, whereas the background value of white is not. If you wish to mark both declarations as important, each declaration needs its own !important marker: p.dark {color: #333 !important; background: white !important;} You must place !important correctly, or the declaration may be invalidated. !impor tant always goes at the end of the declaration, just before the semicolon. This place‐ ment is especially important—no pun intended—when it comes to properties that allow values containing multiple keywords, such as font: p.light {color: yellow; font: smaller Times, serif !important;} If !important were placed anywhere else in the font declaration, the entire declara‐ tion would likely be invalidated and none of its styles applied. I realize that to those of you who come from a programming back‐ ground, the syntax of this token instinctively translates to “not important.” For whatever reason, the bang (!) was chosen as the delimiter for important tokens, and it does not mean “not” in CSS, no matter how many other languages give it that very meaning. This association is unfortunate, but we’re stuck with it. Declarations that are marked !important do not have a special specificity value, but are instead considered separately from non-important declarations. In effect, all ! 102 | Chapter 3: Specificity and the Cascade important declarations are grouped together, and specificity conflicts are resolved relatively within that group. Similarly, all non-important declarations are considered together, with any conflicts within the non-important group are resolved using spe‐ cificity. Thus, in any case where an important and a non-important declaration con‐ flict, the important declaration always wins. Figure 3-2 illustrates the result of the following rules and markup fragment: h1 {font-style: italic; color: gray !important;} .title {color: black; background: silver;} * {background: black !important;}

NightWing

Figure 3-2. Important rules always win Important declarations and their handling are discussed in more detail in “The Cascade” on page 106. Inheritance As important as specificity may be to understanding how declarations are applied to a document, another key concept is inheritance. Inheritance is the mechanism by which some styles are applied not only to a specified element, but also to its descend‐ ants. If a color is applied to an h1 element, for example, then that color is applied to all text inside the h1, even the text enclosed within child elements of that h1: h1 {color: gray;}

Meerkat Central

Both the ordinary h1 text and the em text are colored gray because the em element inherits the value of color from the h1. If property values could not be inherited by descendant elements, the em text would be black, not gray, and we’d have to color the elements separately. Consider an unordered list. Let’s say we apply a style of color: gray; for ul ele‐ ments: ul {color: gray;} Inheritance | 103 We expect that style applied to a ul will also be applied to its list items, and also to any content of those list items. Thanks to inheritance, that’s exactly what happens, as Figure 3-3 demonstrates. Figure 3-3. Inheritance of styles It’s easier to see how inheritance works by turning to a tree diagram of a document. Figure 3-4 shows the tree diagram for a very simple document containing two lists: one unordered and the other ordered. Figure 3-4. A simple tree diagram When the declaration color: gray; is applied to the ul element, that element takes on that declaration. The value is then propagated down the tree to the descendant ele‐ ments and continues on until there are no more descendants to inherit the value. Val‐ ues are never propagated upward; that is, an element never passes values up to its ancestors. There is an exception to the upward propagation rule in HTML: background styles applied to the body element can be passed to the html element, which is the document’s root element and therefore defines its canvas. This only happens if the body element has a defined background and the html element does not. Inheritance is one of those things about CSS that is so basic that you almost never think about it unless you have to. However, you should still keep a couple of things in mind. First, note that many properties are not inherited—generally in order to avoid unde‐ sirable outcomes. For example, the property border (which is used to set borders on elements) does not inherit. A quick glance at Figure 3-5 reveals why this is the case. If 104 | Chapter 3: Specificity and the Cascade borders were inherited, documents would become much more cluttered—unless the author took the extra effort to turn off the inherited borders. Figure 3-5. Why borders aren’t inherited As it happens, most of the box-model properties—including margins, padding, back‐ grounds, and borders—are not inherited for the same reason. After all, you likely wouldn’t want all of the links in a paragraph to inherit a 30-pixel left margin from their parent element! Second, inherited values have no specificity at all, not even zero specificity. This seems like an academic distinction until you work through the consequences of the lack of inherited specificity. Consider the following rules and markup fragment and compare them to the result shown in Figure 3-6: * {color: gray;} h1#page-title {color: black;}

Meerkat Central

Welcome to the best place on the web for meerkat information!

Figure 3-6. Zero specificity defeats no specificity Since the universal selector applies to all elements and has zero specificity, its color declaration’s value of gray wins out over the inherited value of black, which has no specificity at all. Therefore, the em element is rendered gray instead of black. This example vividly illustrates one of the potential problems of using the universal selector indiscriminately. Because it can match any element, the universal selector often has the effect of short-circuiting inheritance. This can be worked around, but it’s usually more sensible to avoid the problem in the first place by not using the uni‐ versal selector indiscriminately. Inheritance | 105 The complete lack of specificity for inherited values is not a trivial point. For exam‐ ple, assume that a style sheet has been written such that all text in a “toolbar” is to be white on black: #toolbar {color: white; background: black;} This will work so long as the element with an id of toolbar contains nothing but plain text. If, however, the text within this element is all hyperlinks (a elements), then the user agent’s styles for hyperlinks will take over. In a web browser, this means they’ll likely be colored blue, since the browser’s internal style sheet probably contains an entry like this: a:link {color: blue;} To overcome this problem, you must declare something like this: #toolbar {color: white; background: black;} #toolbar a:link {color: white;} By targeting a rule directly at the a elements within the toolbar, you’ll get the result shown in Figure 3-7. Figure 3-7. Directly assigning styles to the relevant elements Another way to get the same result is to use the value inherit, covered in the previ‐ ous chapter. We can alter the previous example like so: #toolbar {color: white; background: black;} #toolbar a:link {color: inherit;} This also leads to the result shown in Figure 3-7, because the value of color is explic‐ itly inherited thanks to an assigned rule whose selector has specificity. The Cascade Throughout this chapter, we’ve skirted one rather important issue: what happens when two rules of equal specificity apply to the same element? How does the browser resolve the conflict? For example, consider the following rules: h1 {color: red;} h1 {color: blue;} Which one wins? Both have a specificity of 0,0,0,1, so they have equal weight and should both apply. That can’t be the case because the element can’t be both red and blue. So which will it be? 106 | Chapter 3: Specificity and the Cascade At last, the name “Cascading Style Sheets” makes sense: CSS is based on a method of causing styles to cascade together, which is made possible by combining inheritance and specificity with a few rules. The cascade rules for CSS are: 1. Find all rules that contain a selector that matches a given element. 2. Sort all declarations applying to the given element by explicit weight. Those rules marked !important have a higher weight than those that are not. 3. Sort all declarations applying to the given element by origin. There are three basic origins: author, reader, and user agent. Under normal circumstances, the author’s styles win out over the reader’s styles. !important reader styles are stronger than any other styles, including !important author styles. Both author and reader styles override the user agent’s default styles. 4. Sort all declarations applying to the given element by specificity. Those elements with a higher specificity have more weight than those with lower specificity. 5. Sort all declarations applying to the given element by order. The later a declara‐ tion appears in the style sheet or document, the more weight it is given. Declara‐ tions that appear in an imported style sheet are considered to come before all declarations within the style sheet that imports them. To be perfectly clear about how this all works, let’s consider some examples that illus‐ trate the last four of the five cascade rules. Some later CSS modules add more origins to the basic list of three; for example, the animation and transition origins. These are not covered here, but are addressed in the chapters on those topics. Sorting by Weight and Origin If two rules apply to an element, and one is marked !important, the important rule wins out: p {color: gray !important;}

Well, hello there!

Despite the fact that there is a color assigned in the style attribute of the paragraph, the !important rule wins out, and the paragraph is gray. This gray is inherited by the em element as well. Note that if an !important is added to the inline style, then it will be the winner. Thus, given the following, the paragraph (and its descendant element) will be black: p {color: gray !important;} The Cascade | 107 

Well, hello there!

In situations where the explicit weight is the same, the origin of a rule is considered. If an element is matched by normal-weight styles in both the author’s style sheet and the reader’s style sheet, then the author’s styles are used. For example, assume that the following styles come from the indicated origins: p em {color: black;} /* author's style sheet */ p em {color: yellow;} /* reader's style sheet */ In this case, emphasized text within paragraphs is colored black, not yellow, because normal-weight author styles win out over normal-weight reader styles. However, if both rules are marked !important, the situation changes: p em {color: black !important;} /* author's style sheet */ p em {color: yellow !important;} /* reader's style sheet */ Now the emphasized text in paragraphs will be yellow, not black. As it happens, the user agent’s default styles—which are often influenced by the user preferences—are figured into this step. The default style declarations are the least influential of all. Therefore, if an author-defined rule applies to anchors (e.g., declar‐ ing them to be white), then this rule overrides the user agent’s defaults. To sum up, there are five basic levels to consider in terms of declaration weight. In order of most to least weight, these are: 1. Reader important declarations 2. Author important declarations 3. Author normal declarations 4. Reader normal declarations 5. User agent declarations Authors typically need to worry about only the first four weight levels, since anything declared by an author will win out over the user agent’s styles. Sorting by Specificity If conflicting declarations apply to an element and they all have the same explicit weight and origin, they should be sorted by specificity, with the most specific declara‐ tion winning out, like this: p#bright {color: silver;} p {color: black;}

Well, hello there!

108 | Chapter 3: Specificity and the Cascade Given the rules shown, the text of the paragraph will be silver, as illustrated in Figure 3-8. Why? Because the specificity of p#bright (0,1,0,1) overrode the specif‐ icity of p (0,0,0,1), even though the latter rule comes later in the style sheet. Figure 3-8. Higher specificity wins out over lower specificity Sorting by Order Finally, if two rules have exactly the same explicit weight, origin, and specificity, then the one that occurs later in the style sheet wins out. Let’s return to our earlier exam‐ ple, where we find the following two rules in the document’s style sheet: h1 {color: red;} h1 {color: blue;} In this case, the value of color for all h1 elements in the document will be blue, not red. This is because the two rules are tied with each other in terms of explicit weight and origin, and the selectors have equal specificity, so the last one declared is the win‐ ner. So what happens if rules from completely separate style sheets conflict? For example, suppose the following: @import url(basic.css); h1 {color: blue;} What if h1 {color: red;} appears in basic.css? The entire contents of basic.css are treated as if they were pasted into the style sheet at the point where the @import occurs. Thus, any rule contained in the document’s style sheet occurs later than those from the @import. If they tie in terms of explicit weight and specificity, the docu‐ ment’s style sheet contains the winner. Consider the following: p em {color: purple;} /* from imported style sheet */ p em {color: gray;} /* rule contained within the document */ In this case, the second rule shown wins out over the imported rule because it was the last one specified. Order sorting is the reason behind the often-recommended ordering of link styles. The recommendation is that you array your link styles in the order link-visited-focushover-active, or LVFHA, like this: a:link {color: blue;} a:visited {color: purple;} a:focus {color: green;} The Cascade | 109 a:hover {color: red;} a:active {color: orange;} Thanks to the information in this chapter, you now know that the specificity of all of these selectors is the same: 0,0,1,0. Because they all have the same explicit weight, origin, and specificity, the last one that matches an element will win out. An unvisited link that is being “clicked” or otherwise activated, such as via the keyboard, is matched by four of the rules—:link, Lfocus, :hover, and :active—so the last one of those four will win out. Given the LVFHA ordering, :active will win, which is likely what the author intended. Assume for a moment that you decide to ignore the common ordering and alphabet‐ ize your link styles instead. This would yield: a:active {color: orange;} a:focus {color: green;} a:hover {color: red;} a:link {color: blue;} a:visited {color: purple;} Given this ordering, no link would ever show :hover, :focus, or :active styles because the :link and :visited rules come after the other three. Every link must be either visited or unvisited, so those styles will always override the others. Let’s consider a variation on the LVFHA order that an author might want to use. In this ordering, only unvisited links will get a hover style; visited links do not. Both vis‐ ited and unvisited links will get an active style: a:link {color: blue;} a:hover {color: red;} a:visited {color: purple;} a:focus {color: green;} a:active {color: orange;} Such conflicts arise only when all the states attempt to set the same property. If each state’s styles address a different property, then the order does not matter. In the fol‐ lowing case, the link styles could be given in any order and would still function as intended: a:link {font-weight: bold;} a:visited {font-style: italic;} a:focus {color: green;} a:hover {color: red;} a:active {background: yellow;} You may also have realized that the order of the :link and :visited styles doesn’t matter. You could order the styles LVFHA or VLFHA with no ill effect. The ability to chain pseudo-classes together eliminates all these worries. The follow‐ ing could be listed in any order without any overrides: 110 | Chapter 3: Specificity and the Cascade a:link {color: blue;} a:visited {color: purple;} a:link:hover {color: red;} a:visited:hover {color: gray;} Because each rule applies to a unique set of link states, they do not conflict. There‐ fore, changing their order will not change the styling of the document. The last two rules do have the same specificity, but that doesn’t matter. A hovered unvisited link will not be matched by the rule regarding hovered visited links, and vice versa. If we were to add active-state styles, then order would start to matter again. Consider: a:link {color: blue;} a:visited {color: purple;} a:link:hover {color: red;} a:visited:hover {color: gray;} a:link:active {color: orange;} a:visited:active {color: silver;} If the active styles were moved before the hover styles, they would be ignored. Again, this would happen due to specificity conflicts. The conflicts could be avoided by adding more pseudo-classes to the chains, like this: a:link:hover:active {color: orange;} a:visited:hover:active {color: silver;} This does have the effect of raising the specificity of the selectors—both have a specif‐ icity value of 0,0,3,1—but they don’t conflict because the actual selection states are mutually exclusive. A link can’t be an unvisited hovered active link and an unvisited hovered active link: only one of the two rules will match, and the styles applied accordingly. Non-CSS Presentational Hints It is possible that a document will contain presentational hints that are not CSS—for example, the font element. Such presentational hints are treated as if they have a spe‐ cificity of 0 and appear at the beginning of the author’s stylesheet. Such presentation hints will be overridden by any author or reader styles, but not by the user agent’s styles. In CSS3, presentational hints from outside CSS are treated as if they belong to the user agent’s stylesheet, presumably at the end (although as of this writing, the specification doesn’t say). Summary Perhaps the most fundamental aspect of Cascading Style Sheets is the cascade itself— the process by which conflicting declarations are sorted out and from which the final document presentation is determined. Integral to this process is the specificity of selectors and their associated declarations, and the mechanism of inheritance. Summary | 111 CHAPTER 4 Values and Units In this chapter, we’ll tackle features that are the basis for almost everything you can do with CSS: the units that affect the colors, distances, and sizes of a whole host of properties, as well as the units that help to define those values. Without units, you couldn’t declare that an image should have 10 pixels of blank space around it, or that a heading’s text should be a certain size. By understanding the concepts put forth here, you’ll be able to learn and use the rest of CSS much more quickly. Keywords, Strings, and Other Text Values Everything in a stylesheet is text, but there are certain value types that directly repre‐ sent strings of text as opposed to, say, numbers or colors. Included in this category are URLs and, interestingly enough, images. Keywords For those times when a value needs to be described with a word of some kind, there are keywords. A very common example is the keyword none, which is distinct from 0 (zero). Thus, to remove the underline from links in an HTML document, you would write: a:link, a:visited {text-decoration: none;} Similarly, if you want to force underlines on the links, then you would use the key‐ word underline. If a property accepts keywords, then its keywords will be defined only for the scope of that property. If two properties use the same word as a keyword, the behavior of the keyword for one property will not necessarily be shared with the other. As an exam‐ 113 ple, normal, as defined for letter-spacing, means something very different than the normal defined for font-style. Global keywords CSS3 defines three “global” keywords that are accepted by every property in the spec‐ ification: inherit, initial, and unset. inherit. The keyword inherit makes the value of a property on an element the same as the value of that property on its parent element. In other words, it forces inheri‐ tance to occur even in situations where it would not normally operate. In many cases, you don’t need to specify inheritance, since many properties inherit naturally. Never‐ theless, inherit can still be very useful. For example, consider the following styles and markup: #toolbar {background: blue; color: white;} The div itself will have a blue background and a white foreground, but the links will be styled according to the browser’s preference settings. They’ll most likely end up as blue text on a blue background, with white vertical bars between them. You could write a rule that explicitly sets the links in the “toolbar” to be white, but you can make things a little more robust by using inherit. You just add the following rule to the stylesheet: #toolbar a {color: inherit;} This will cause the links to use the inherited value of color in place of the user agent’s default styles. Ordinarily, directly assigned styles override inherited styles, but inherit can undo that behavior. It might not always be a good idea—for example, here links might blend into surrounding text too much, and become an accessibility concern—but it can be done. Similarly, you can pull a property value down from a parent even if it wouldn’t hap‐ pen normally. Take border, for example, which is (rightfully) not inherited. If you want a span to inherit the border of its parent, all you need is span {border: inherit;}. More likely, though, you just want the border on a span to use the same border color as its parent. In that case span {border-color: inherit;} will do the trick. 114 | Chapter 4: Values and Units initial. The keyword initial sets the value of a property to the defined initial value, which in a way means it “resets” the value. For example, the default value of fontweight is normal. Thus, declaring font-weight: initial is the same as declaring font-weight: normal. This might seem a little bit silly until you consider that not all values have explicitly defined initial values. For example, the initial value for color is “depends on user agent.” That’s not a funky keyword you should type! What it means is that the default value of color depends on things like the preferences settings in a browser. While almost nobody changes the default text color setting from black, someone might set it to a dark gray or even a bright red. By declaring color: initial;, you’re telling the browser to set the color of the element to whatever the user’s default color is set to be. unset. The keyword unset acts as a universal stand-in for both inherit and ini tial. If the property is inherited, then unset has the same effect as if inherit was used. If the property is not inherited, then unset has the same effect as if initial was used. As of late 2017, Opera Mini did not support any of initial, inherit, or unset. Internet Explorer did not support them through IE11. These global values are usable on all properties, but there is a special property that only accepts the global keywords: all. all Values inherit | initial | unset Initial value See individual properties all is a stand-in for all properties except direction and unicode-bidi. Thus, if you declare all: inherit on an element, you’re saying that you want all properties except direction and unicode-bidi to inherit their values from the element’s parent. Consider the following: section {color: white; background: black; font-weight: bold;} #example {all: inherit;} Keywords, Strings, and Other Text Values | 115 

This is a div.

You might think this causes the div element to inherit the values of color, back ground, and font-weight from the section element. And it does do that, yes—but it will also force inheritance of the values of every single other property in CSS (minus the two exceptions) from the section element. Maybe that’s what you want, in which case, great. But if you just want to inherit the property values you wrote out for the section element, then the CSS would need to look more like this: section {color: white; background: black; font-weight: bold;} #example {color: inherit; background: inherit; font-weight: inherit;} Odds are what you really want in these situations is all: unset, but your stylesheet may vary. As of late 2017, a new global keyword, revert, was being consid‐ ered for adoption. Its goal was to allow rollbacks of values to those set by other origins—for example, to let an author say, “All property values for this element should be as if the author styles don’t exist, but user agent and user styles do.” Since it was still under consider‐ ation, it has not been documented in detail here. As of late 2017, Opera Mini and Microsoft Edge did not support all. Support was under consideration for Edge. Strings A string value is an arbitrary sequence of characters wrapped in either single or dou‐ ble quotes, and is represented in value definitions with . Two simple exam‐ ples: "I like to play with strings." 'Strings are fun to play with.' Note that the quotes balance, which is to say that you always start and end with the same kind of quotes. Getting this wrong can lead to all kinds of parsing problems, since starting with one kind of quote and trying to end with the other means the string won’t actually be terminated. You could accidentally incorporate subsequent rules into the string that way! If you want to put quote marks inside strings, that’s OK, as long as they’re either not the kind you used to enclose the string or are escaped using a backslash: 116 | Chapter 4: Values and Units "I've always liked to play with strings." 'He said to me, "I like to play with strings."' "It's been said that \"haste makes waste.\"" 'There\'s never been a "string theory" that I\'ve liked.' Note that the only acceptable string delimiters are ' and ", sometimes called “straight quotes.” That means you can’t use “curly” or “smart” quotes to begin or end a string value. You can use them inside a string value, as in this code example, though, and they don’t have to be escaped: "It’s been said that “haste makes waste.”" 'There’s never been a “string theory” that I’ve liked.' This requires that you use Unicode encoding for your documents, but you should be doing that regardless. (You can find the Unicode standard at http://www.unicode.org/ standard/standard.html.) If you have some reason to include a newline in your string value, you can do that by escaping the newline itself. CSS will then remove it, making things as if it had never been there. Thus, the following two string values are identical from a CSS point of view: "This is the right place \ for a newline." "This is the right place for a newline." If, on the other hand, you actually want a string value that includes a newline charac‐ ter, then use the Unicode reference \A where you want the newline to occur: "This is a better place \Afor a newline." URLs If you’ve written web pages, you’re almost certainly familiar with URLs (or, as in CSS2.1, URIs). Whenever you need to refer to one—as in the @import statement, which is used when importing an external stylesheet—the general format is: url(protocol://server/pathname) This example defines what is known as an absolute URL. By absolute, I mean a URL that will work no matter where (or rather, in what page) it’s found, because it defines an absolute location in web space. Let’s say that you have a server called web.waf‐ fles.org. On that server, there is a directory called pix, and in this directory is an image waffle22.gif. In this case, the absolute URL of that image would be: web.waffles.org/pix/waffle22.gif This URL is valid no matter where it is found, whether the page that contains it is located on the server web.waffles.org or web.pancakes.com. Keywords, Strings, and Other Text Values | 117 The other type of URL is a relative URL, so named because it specifies a location that is relative to the document that uses it. If you’re referring to a relative location, such as a file in the same directory as your web page, then the general format is: url(pathname) This works only if the image is on the same server as the page that contains the URL. For argument’s sake, assume that you have a web page located at http:// web.waffles.org/syrup.html and that you want the image waffle22.gif to appear on this page. In that case, the URL would be: pix/waffle22.gif This path works because the web browser knows that it should start with the place it found the web document and then add the relative URL. In this case, the pathname pix/waffle22.gif added to the server name http://web.waffles.org equals http:// web.waffles.org/pix/waffle22.gif. You can almost always use an absolute URL in place of a relative URL; it doesn’t matter which you use, as long as it defines a valid loca‐ tion. In CSS, relative URLs are relative to the stylesheet itself, not to the HTML document that uses the stylesheet. For example, you may have an external stylesheet that imports another stylesheet. If you use a relative URL to import the second stylesheet, it must be relative to the first stylesheet. As an example, consider an HTML document at http://web.waffles.org/toppings/ tips.html, which has a link to the stylesheet http://web.waffles.org/styles/basic.css: Inside the file basic.css is an @import statement referring to another stylesheet: @import url(special/toppings.css); This @import will cause the browser to look for the stylesheet at http:// web.waffles.org/styles/special/toppings.css, not at http://web.waffles.org/toppings/ special/toppings.css. If you have a stylesheet at the latter location, then the @import in basic.css should read one of the two following ways: @import url(http://web.waffles.org/toppings/special/toppings.css); @import url(../special/toppings.css); Note that there cannot be a space between the url and the opening parenthesis: body {background: url(http://www.pix.web/picture1.jpg);} /* correct */ body {background: url (images/picture2.jpg);} /* INCORRECT */ If the space is present, the entire declaration will be invalidated and thus ignored. 118 | Chapter 4: Values and Units Images An image value is a reference to an image, as you might have guessed. Its syntax rep‐ resentation is . At the most basic level of support, which is to say the one every CSS engine on the planet would understand, an value is a value. In more advanced user agents, stands for one of the following: A URL identifier of an external resource; in this case, the URL of an image. Perhaps unsurprisingly, a set of images, chosen based on a set of conditions embedded into the value. For example, an image-set() could specify that a larger image be used for desktop layouts, whereas a smaller image (both in pixel size and file size) be used for a mobile design. It is intended to at least approxi‐ mate the behavior of the srcset attribute for picture elements. As of late 2016, browser support for image-set was limited to Safari, Chrome, and desktop Opera, and was not on par with srcset’s full range of capabilities. Refers to either a linear or radial gradient image, either singly or in a repeating pattern. Gradients are fairly complex, and thus are covered in detail in Chapter 9. Identifiers There are a few properties that accept an identifier value, which is a user-defined identifier of some kind; the most common example is generated list counters. They are represented in the value syntax as . Identifiers themselves are words, and are case-sensitive; thus, myID and MyID are, as far as CSS is concerned, completely distinct and unrelated to each other. In cases where a property accepts both an identi‐ fier and one or more keywords, the author should take care to never define an identi‐ fier identical to a valid keyword. Numbers and Percentages These value types are special because they serve as the foundation for so many other values types. For example, font sizes can be defined using the em identifier (covered later in this text) preceded by a number. But what kind of number? Defining the types of numbers here lets us speak clearly later on. Numbers and Percentages | 119 Integers An integer value is about as simple as it gets: one or more numbers, optionally pre‐ fixed by a + or − sign to indicate a positive or negative value. That’s it. Integer values are represented in value syntax as . Examples include 13, −42, 712, and 1,066. Integer values that fall outside a defined range are, by default, considered invalid and cause the entire declaration to be ignored. However, some properties define behavior that causes values outside the accepted range to be set to the accepted value closest to the declared value, known as clamping. In cases (such as the property z-index) where there is no restricted range, user agents must support values up to ±1,073,741,824 (±230). Numbers A number value is either an or a real number, which is to say an integer followed by a dot and then some number of following integers. Additionally, it can be prefixed by either + or − to indicate positive or negative values. Number values are represented in value syntax as . Examples include 2.7183, −3.1416, and 6.2832. The reason a can be an and yet there are separate value types is that some properties will only accept integers (e.g., z-index), whereas others will accept any real number (e.g., flex-grow). As with integer values, number values may have limits imposed on them by a property definition; for example, opacity restricts its value to be any valid in the range 0 to 1, inclusive. By default, number values that fall outside a defined range are, by default, considered invalid and cause the entire declaration to be ignored. However, some properties define behavior that causes values outside the accepted range to be set to the accepted value closest to the declared value (generally referred to as “clamping”). Percentages A percentage value is a followed by a percentage sign (%), and is repre‐ sented in value syntax as . Examples would include 50% and 33.333%. Percentage values are always relative to another value, which can be anything—the value of another property of the same element, a value inherited from the parent ele‐ ment, or a value of an ancestor element. Any property that accepts percentage values will define any restrictions on the range of allowed percentage values, and will also define the way in which the percentage is relatively calculated. 120 | Chapter 4: Values and Units Fractions A fraction value (or flex value) is a followed by the label fr. Thus, one frac‐ tional unit is 1fr. This is a concept introduced by Grid Layout, and is used to divide up fractions of the unconstrained space in a layout. See Chapter 13 for more details. Distances Many CSS properties, such as margins, depend on length measurements to properly display various page elements. It’s likely no surprise, then, that there are a number of ways to measure length in CSS. All length units can be expressed as either positive or negative numbers followed by a label, although note that some properties will accept only positive numbers. You can also use real numbers—that is, numbers with decimal fractions, such as 10.5 or 4.561. All length units are followed by short abbreviation (usually two characters) that rep‐ resents the actual unit of length being specified, such as in (inches) or pt (points). The only exception to this rule is a length of 0 (zero), which need not be followed by a unit when describing lengths. These length units are divided into two types: absolute length units and relative length units. Absolute Length Units We’ll start with absolute units because they’re easiest to understand, despite the fact that they’re almost unusable in regular web design. The six types of absolute units are as follows: Inches (in) As you might expect, this notation refers to the inches you’d find on a ruler in the United States. (The fact that this unit is in the specification, even though almost the entire world uses the metric system, is an interesting insight into the perva‐ siveness of US interests on the internet—but let’s not get into virtual sociopoliti‐ cal theory right now.) Centimeters (cm) Refers to the centimeters that you’d find on rulers the world over. There are 2.54 centimeters to an inch, and one centimeter equals 0.394 inches. Millimeters (mm) For those Americans who are metric-challenged, there are 10 millimeters to a centimeter, so an inch equals 25.4 millimeters, and a millimeter equals 0.0394 inches. Distances | 121 Quarter-millimeters (q) There are 40 Q units in a centimeter; thus, setting an element to be 1/10 of a cen‐ timeter wide—which is also to say, a millimeter wide—would mean a value of 4q. (Only Firefox supported q as of late 2016.) Points (pt) Points are standard typographical measurements that have been used by printers and typesetters for decades and by word processing programs for many years. Traditionally, there are 72 points to an inch (points were defined before wide‐ spread use of the metric system). Therefore the capital letters of text set to 12 points should be one-sixth of an inch tall. For example, p {font-size: 18pt;} is equivalent to p {font-size: 0.25in;}. Picas (pc) Picas are another typographical term. A pica is equivalent to 12 points, which means there are 6 picas to an inch. As just shown, the capital letters of text set to 1 pica should be one-sixth of an inch tall. For example, p {font-size: 1.5pc;} would set text to the same size as the example declarations found in the defini‐ tion of points. Pixels (px) A pixel is a small box on screen, but CSS defines pixels more abstractly. In CSS terms, a pixel is defined to be the size required to yield 96 pixels per inch. Many user agents ignore this definition in favor of simply addressing the pixels on the screen. Scaling factors are brought into play when page zooming or printing, where an element 100px wide can be rendered more than 100 device dots wide. These units are really useful only if the browser knows all the details of the screen on which your page is displayed, the printer you’re using, or whatever other user agent might apply. On a web browser, display is affected by the size of the screen and the resolution to which the screen is set—and there isn’t much that you, as the author, can do about these factors. You can only hope that, if nothing else, the measurements will be consistent in relation to each other—that is, that a setting of 1.0in will be twice as large as 0.5in, as shown in Figure 4-1. Figure 4-1. Setting absolute-length left margins Nevertheless, despite all that, let’s make the highly suspect assumption that your com‐ puter knows enough about its display system to accurately reproduce real-world measurements. In that case, you could make sure every paragraph has a top margin of 122 | Chapter 4: Values and Units half an inch by declaring p {margin-top: 0.5in;}. Regardless of font size or any other circumstances, a paragraph will have a half-inch top margin. Absolute units are much more useful in defining stylesheets for printed documents, where measuring things in terms of inches, points, and picas is much more common. Pixel lengths On the face of things, pixels are straightforward. If you look at a screen closely enough, you can see that it’s broken up into a grid of tiny little boxes. Each box is a pixel. If you define an element to be a certain number of pixels tall and wide, as in the following markup:

The following image is 20 pixels tall and wide:

then it follows that the element will be that many screen elements tall and wide, as shown in Figure 4-2. Figure 4-2. Using pixel lengths In general, if you declare something like font-size: 18px, a web browser will almost certainly use actual pixels on your screen—after all, they’re already there—but with other display devices, like printers, the user agent will have to rescale pixel lengths to something more sensible. In other words, the printing code has to figure out how many dots there are in a pixel. On the other hand, pixel measurements are often useful for expressing the size of images, which are already a certain number of pixels tall and wide. These days, responsive design means that we often want to express image size in relation to the size of the text of the width of the viewport, regardless of the number of actual pixels in the image. You do end up relying on the image-scaling routines in user agents, but those have been getting pretty good. Scaling of images really makes sense with vectorbased images like SVG. Pixel theory In its discussion of pixels, the CSS specification recommends that, in cases where a display’s resolution density is significantly different than 96 pixels per inch (ppi), user agents should scale pixel measurements to a “reference pixel.” CSS2 recommended 90 ppi as the reference pixel, but CSS2.1 and CSS3 recommend 96 ppi. The most com‐ mon example is a printer, which has dots instead of pixels, and which has a lot more Distances | 123 dots per inch than 96! In printing web content, then, it may assume 96 pixels per inch and scale its output accordingly. If a display’s resolution is set to 1,024 pixels wide by 768 pixels tall, its screen size is exactly 10 2/3 inches wide by 8 inches tall, and the screen it is filled entirely by the display pixels, then each pixel will be 1/96 of an inch wide and tall. As you might guess, this scenario is a fairly rare occurrence. So, on most displays, the actual num‐ ber of pixels per inch (ppi) is higher than 96—sometimes much higher. The Retina display on an iPhone 4S, for example, is 326 ppi; the display on the iPad 264 ppi. As a Windows XP user, you should be able to set your display driver to make the display of elements correspond correctly to realworld measurements. The path to the ruler dialog is Start→Control Panel; double-click Display; click the Settings tab; then click Advanced to reveal a dialog box (which may differ on each PC). You should see a dropdown or other form control labeled Font Size; select Other. Resolution Units With the advent of media queries and responsive designs, three new unit types were introduced in order to be able to describe display resolution: Dots per inch (dpi) The number of display dots per linear inch. This can refer to the dots in a paper printer’s output, the physical pixels in an LED screen or other device, or the ele‐ ments in an e-ink display such as that used by a Kindle. Dots per centimeter (dpcm) Same as dpi, except the linear measure is one centimeter instead of one inch. Dots per pixel unit (dppx) The number of display dots per CSS px unit. As of CSS3, 1dppx is equivalent to 96dpi because CSS defines pixel units at that ratio. Just bear in mind that ratio could change in future versions of CSS. As of late 2017, these units are only used in the context of media queries. As an exam‐ ple, an author can create a media block to be used only on displays that have higher than 500 dpi: @media (min-resolution: 500dpi) { /* rules go here */ } 124 | Chapter 4: Values and Units Relative Length Units Relative units are so called because they are measured in relation to other things. The actual (or absolute) distance they measure can change due to factors beyond their control, such as screen resolution, the width of the viewing area, the user’s preference settings, and a whole host of other things. In addition, for some relative units, their size is almost always relative to the element that uses them and will thus change from element to element. em and ex units First, let’s consider em and ex, which are closely related. In CSS, one “em” is defined to be the value of font-size for a given font. If the font-size of an element is 14 pixels, then for that element, 1em is equal to 14 pixels. As you may suspect, this value can change from element to element. For example, let’s say you have an h1 with a font size of 24 pixels, an h2 element with a font size of 18 pixels, and a paragraph with a font size of 12 pixels. If you set the left margin of all three at 1em, they will have left margins of 24 pixels, 18 pixels, and 12 pixels, respec‐ tively: h1 {font-size: 24px;} h2 {font-size: 18px;} p {font-size: 12px;} h1, h2, p {margin-left: 1em;} small {font-size: 0.8em;}

Left margin = 24 pixels

Left margin = 18 pixels

Left margin = 12 pixels

When setting the size of the font, on the other hand, the value of em is relative to the font size of the parent element, as illustrated by Figure 4-3. Figure 4-3. Using em for margins and font sizing In theory, one em is equal to the width of a lowercase m in the font used—that’s where the name comes from, in fact. It’s an old typographer’s term. However, this is not assured in CSS. ex, on the other hand, refers to the height of a lowercase x in the font being used. Therefore, if you have two paragraphs in which the text is 24 points in size, but each paragraph uses a different font, then the value of ex could be different for each Distances | 125 paragraph. This is because different fonts have different heights for x, as you can see in Figure 4-4. Even though the examples use 24-point text—and therefore each exam‐ ple’s em value is 24 points—the x-height for each is different. Figure 4-4. Varying x heights The rem unit Like the em unit, the rem unit is based on declared font size. The difference—and it’s a doozy—is that whereas em is calculated using the font size of the element to which it’s applied, rem is always calculated using the root element. In HTML, that’s the html element. Thus, declaring any element to have font-size: 1rem; is setting it to have the same font-size value as the root element of the document. As an example, consider the following markup fragment. It will have the result shown in Figure 4-5.

This paragraph has inheritance.

1em;">This paragraph has the same font size as its parent 1rem;">This paragraph has the same font size as the root In effect, rem acts as a reset for font size: no matter what relative font sizing has hap‐ pened to the ancestors of an element, giving it font-size: 1rem; will put it right back where the root element is set. This will usually be the user’s default font size, unless you (or the user) have set the root element to a specific font size. For example, given this declaration, 1rem will always be equivalent to 13px: html {font-size: 13px;} However, given this declaration, 1rem will always be equivalent to three-quarters the user’s default font size: html {font-size: 75%;} In this case, if the user’s default is 16 pixels, then 1rem will equal 12px. If the user has actually set their default to 12 pixels—a few people do this—then 1rem will equal 9px; if the default setting is 20 pixels, then 1rem equals 15px. And so on. You are not restricted to the value 1rem. Any real number can be used, just as with the em unit, so you can do fun things like set all of your headings to be multiples of the root element’s font size: h1 h2 h3 h4 h5 h6 {font-size: {font-size: {font-size: {font-size: {font-size: {font-size: 2rem;} 1.75rem;} 1.4rem;} 1.1rem;} 1rem;} 0.8rem;} In browsers that support the keyword initial, font-size: 1rem is equivalent to font-size: initial as long as no font size is set for the root element. The ch unit An interesting addition to CSS3 is the ch unit, which is broadly meant to represent “one character.” The way it is defined in CSS3 is: Equal to the advance measure of the “0” (ZERO, U+0030) glyph found in the font used to render it. The term advance measure is actually a CSS-ism that corresponds to the term “advance width” in font typography. CSS uses the term “measure” because some scripts are not right to left or left to right, but instead top to bottom or bottom to top, and so may have an advance height rather than an advance width. For simplicity’s sake, we’ll stick to advance widths in this section. Distances | 127 Without getting into too many details, a character glyph’s advance width is the dis‐ tance from the start of a character glyph to the start of the next. This generally corre‐ sponds to the width of the glyph itself plus any built-in spacing to the sides. (Although that built-in spacing can be either positive or negative.) CSS pins the ch unit to the advance width of a zero in a given font. This is in parallel to the way that em is calculated with respect to the font-size value of an element. The easiest way to demonstrate this unit is to run a bunch of zeroes together and then set an image to have a width with the same number of ch units as the number of zeroes, as shown in Figure 4-6: img {height: 1em; width: 25ch;} Figure 4-6. Character-relative sizing Given a monospace font, all characters are by definition 1ch wide. In any propor‐ tional face type, which is what the vast majority of Western typefaces are, characters may be wider or narrower than the “0” and so cannot be assumed to be 1ch wide. As of late 2017, only Opera Mini and Internet Explorer had prob‐ lems with ch. In IE11, ch was mis-measured to be exactly the width of the “0” glyph, not the glyph plus the small amount of space to either side of it. Thus, 5ch was less than the width of “00000” in IE11. This error was corrected in Edge. 128 | Chapter 4: Values and Units Viewport-relative units Another new addition in CSS3 are the three viewport-relative size units. These are calculated with respect to the size of the viewport—browser window, printable area, mobile device display, etc.: Viewport width unit (vw) This unit is calculated with respect to the viewport’s width, which is divided by 100. Therefore, if the viewport is 937 pixels wide, 1vw is equal to 9.37px. If the viewport’s width changes, say by dragging the browser window wider or more narrow, the value of vw changes along with it. Viewport height unit (vh) This unit is calculated with respect to the viewport’s height, which is divided by 100. Therefore, if the viewport is 650 pixels tall, 1vh is equal to 6.5px. If the view‐ port’s height changes, say by dragging the browser window taller or shorter, the value of vh changes along with it. Viewport minimum unit (vmin) This unit is 1/100 of the viewport’s width or height, whichever is lesser. Thus, given a viewport that is 937 pixels wide by 650 pixels tall, 1vmin is equal to 6.5px. Viewport maximum unit (vmax) This unit is 1/100 of the viewport’s width or height, whichever is greater. Thus, given a viewport that is 937 pixels wide by 650 pixels tall, 1vmax is equal to 9.37px. Note that these are length units like any other, and so can be used anywhere a length unit is permitted. You can scale the font size of a heading in terms of the viewport, height, for example, with something like h1 {font-size: 10vh;}. This sets the font size to be 1/10 the height of the viewport—a technique potentially useful for article titles and the like. These units can be particularly handy for creating full-viewport interfaces, such as those one would expect to find on a mobile device, because it can allow elements to be sized compared to the viewport and not any of the elements within the document tree. It’s thus very simple to fill up the entire viewport, or at least major portions of it, and not have to worry about the precise dimensions of the actual viewport in any particular case. Here’s a very basic example of viewport-relative sizing, which is illustrated in Figure 4-7: div {width: 50vh; height: 33vw; background: gray;} Distances | 129 An interesting (though perhaps not useful) fact about these units is that they aren’t bound to their own primary axis. Thus, for example, you can declare width: 25vh; to make an element as wide as one-quarter the height of the viewport. As of late 2016, viewport-relative units were supported by all browsers except Opera Mini, plus the odd exception that vmax is not supported in Microsoft browsers. Figure 4-7. Viewport-relative sizing Calculation values In situations where you need to do a little math, CSS provides a calc() value. Inside the parentheses, you can construct simple mathematical expressions. The permitted operators are + (addition), - (subtraction), * (multiplcation), and / (division), as well as parentheses. These follow the traditional PEMDAS (parentheses, exponents, multi‐ plication, division, addition, subtraction) precedence order, although in this case it’s really just PMDAS since exponents are not permitted in calc(). Support for parentheses in calc() appears to be a convenience provided by browsers, since they’re not mentioned in the syntax definition for calc(). It seems likely that support for parentheses will remain, but use at your own risk. As an example, suppose you want your paragraphs to have a width that’s 2 em less than 90% the width of their parent element. Here’s how you express that with calc(): 130 | Chapter 4: Values and Units p {width: calc(90% - 2em);} calc() can be used anywhere one of the following value types is permitted: , , , , , , and . You can also use all these unit types within a calc() value, though there are some limitations to keep in mind. The basic limitation is that calc() does basic type checking to make sure that units are, in effect, compatible. The checking works like this: 1. To either side of a + or - sign, both values must have the same unit type, or be a and (in which case, the result is a ). Thus, 5 + 2.7 is valid, and results in 7.7. On the other hand, 5em + 2.7 is invalid, because one side has a length unit and the other does not. Note that 5em + 20px is valid, because em and px are both length units. 2. Given a *, one of the values involved must be a (which, remember, includes integer values). So 2.5rem * 2 and 2 * 2.5rem are both valid, and each result in 5rem. On the flip side, 2.5rem * 2rem is not valid, because the result would be 5rem2, and length units cannot be area units. 3. Given a /, the value on the right side must be a . If the left side is an , the result is a . Otherwise, the result is of the unit type used on the left side. This means that 30em / 2.75 is valid, but 30 / 2.75em is not valid. 4. Furthermore, any circumstance that yields division by zero is invalid. This is easi‐ est to see in a case like 30px/0, but there are other ways to get there. There’s one more notable limitation, which is that whitespace is required to either side of the + and - operators, while it is not for * and /. This avoids ambiguity with respect to values which can be negative. Beyond that, the specification requires that user agents support a minimum of 20 terms inside a calc() expression, where a term is a number, percentage, or dimen‐ sion (length). In situations where the number of terms somehow exceeds the user agent’s term limits, the entire expression is treated as invalid. Attribute Values In a few CSS properties, it’s possible to pull in the value of an HTML attribute defined for the element being styled. This is done with the attr() expression. For example, with generated content, you can insert the value of any attribute. It looks something like this (don’t worry about understanding the exact syntax, which we’ll explore in Chapter 15): Attribute Values | 131 p::before {content: "[" attr(id) "]";} That expression would prefix any paragraph that has an id attribute with the value of that id, enclosed in square brackets. Therefore applying the previous style to the fol‐ lowing paragraphs would have the result shown in Figure 4-8:

This is the first paragraph.

This is the second paragraph.

This is the third paragraph.

Figure 4-8. Inserting attribute values It’s theoretically possible to use attr() in almost any property value, specifying the value type within the expression. For example, you could (again, in theory) use the maxlength attribute on an input field to determine its width, as shown here: input[type="text"] {width: attr(maxlength em);} Given that setup, the input element would be styled to be 10 em wide, assuming a user agent that supports this use of attr(). As of late 2016, this was not the case: no tested browser supported this application of attr(). Color One of the first questions every starting web author asks is, “How do I set colors on my page?” Under HTML, you have two choices: you could use one of a small number of colors with names, such as red or purple, or employ a vaguely cryptic method using hexadecimal codes. Both of these methods for describing colors remain in CSS, along with some other—and, I think, more intuitive—methods. Named Colors Assuming that you’re content to pick from a small, basic set of colors, the easiest method is to use the name of the color you want. CSS calls these color choices, logi‐ cally enough, named colors. In the early days of CSS, there were 16 basic color key‐ words, which were the 16 colors defined in HTML 4.01. These are shown in Table 4-1. 132 | Chapter 4: Values and Units Table 4-1. The basic 16 color keywords aqua gray navy silver black green olive teal blue lime purple white fuchsia maroon red yellow So, let’s say you want all first-level headings to be maroon. The best declaration would be: h1 {color: maroon;} Simple enough, isn’t it? Figure 4-9 shows a few more examples: h1 {color: silver;} h2 {color: fuchsia;} h3 {color: navy;} Figure 4-9. Named colors You’ve probably seen (and maybe even used) color names other than the ones listed earlier. For example, if you specify: h1 {color: lightgreen;} As of late 2017, the latest CSS color specification includes those original 16 named colors in a longer list of 148 color keywords. This extended list is based on the stan‐ dard X11 RGB values that have been in use for decades, and have been recognized by browsers for many years, with the addition of some color names from SVG (mostly involving variants of “gray” and “grey”). A table of color equivalents for all 148 key‐ words defined in the CSS Color Module Level 4 is given in Appendix C. Fortunately, there are more detailed and precise ways to specify colors in CSS. The advantage is that, with these methods, you can specify any color in the color spec‐ trum, not just a limited list of named colors. Colors by RGB and RGBa Computers create colors by combining different levels of red, green, and blue, a com‐ bination that is often referred to as RGB color. Each point of display is known as a pixel. Given the way colors are created on a screen, it makes sense that you should Color | 133 have direct access to those colors, determining your own mixture of the three for maximum control. That solution is complex, but possible, and the payoffs are worth it because there are very few limits on which colors you can produce. There are four ways to affect color in this manner. Functional RGB colors There are two color value types that use functional RGB notation as opposed to hexa‐ decimal notation. The generic syntax for this type of color value is rgb(color), where color is expressed using a triplet of either percentages or integers. The percentage values can be in the range 0%–100%, and the integers can be in the range 0–255. Thus, to specify white and black, respectively, using percentage notation, the values would be: rgb(100%,100%,100%) rgb(0%,0%,0%) Using the integer-triplet notation, the same colors would be represented as: rgb(255,255,255) rgb(0,0,0) An important thing to remember is that you can’t mix integers and percentages in the same color value. Thus, rgb(255,66.67%,50%) would be invalid and thus ignored. Assume you want your h1 elements to be a shade of red that lies between the values for red and maroon. red is equivalent to rgb(100%,0%,0%), whereas maroon is equal to (50%,0%,0%). To get a color between those two, you might try this: h1 {color: rgb(75%,0%,0%);} This makes the red component of the color lighter than maroon, but darker than red. If, on the other hand, you want to create a pale red color, you would raise the green and blue levels: h1 {color: rgb(75%,50%,50%);} The closest equivalent color using integer-triplet notation is: h1 {color: rgb(191,127,127);} The easiest way to visualize how these values correspond to color is to create a table of gray values. The result is shown in Figure 4-10: p.one {color: rgb(0%,0%,0%);} p.two {color: rgb(20%,20%,20%);} p.three {color: rgb(40%,40%,40%);} p.four {color: rgb(60%,60%,60%);} p.five {color: rgb(80%,80%,80%);} p.six {color: rgb(0,0,0);} p.seven {color: rgb(51,51,51);} 134 | Chapter 4: Values and Units p.eight {color: rgb(102,102,102);} p.nine {color: rgb(153,153,153);} p.ten {color: rgb(204,204,204);} Figure 4-10. Text set in shades of gray Since we’re dealing in shades of gray, all three RGB values are the same in each state‐ ment. If any one of them were different from the others, then a color hue would start to emerge. If, for example, rgb(50%,50%,50%) were modified to be rgb(50%,50%, 60%), the result would be a medium-dark color with just a hint of blue. It is possible to use fractional numbers in percentage notation. You might, for some reason, want to specify that a color be exactly 25.5 percent red, 40 percent green, and 98.6 percent blue: h2 {color: rgb(25.5%,40%,98.6%);} A user agent that ignores the decimal points (and some do) should round the value to the nearest integer, resulting in a declared value of rgb(26%,40%,99%). In integer trip‐ lets, you are limited to integers. Values that fall outside the allowed range for each notation are clipped to the nearest range edge, meaning that a value that is greater than 100% or less than 0% will default to those allowed extremes. Thus, the following declarations would be treated as if they were the values indicated in the comments: P.one {color: rgb(300%,4200%,110%);} /* 100%,100%,100% P.two {color: rgb(0%,-40%,-5000%);} /* 0%,0%,0% */ p.three {color: rgb(42,444,-13);} /* 42,255,0 */ */ Conversion between percentages and integers may seem arbitrary, but there’s no need to guess at the integer you want—there’s a simple formula for calculating them. If you know the percentages for each of the RGB levels you want, then you need only apply them to the number 255 to get the resulting values. Let’s say you have a color of 25 percent red, 37.5 percent green, and 60 percent blue. Multiply each of these percen‐ tages by 255, and you get 63.75, 95.625, and 153. Round these values to the nearest integers, and voilà: rgb(64,96,153). Color | 135 If you already know the percentage values, there isn’t much point in converting them into integers. Integer notation is more useful for people who use programs such as Photoshop, which can display integer values in the Info dialog, or for those who are so familiar with the technical details of color generation that they normally think in values of 0–255. RGBa colors As of CSS3, the two functional RGB notations were extended into a functional RGBa notation. This notation adds an alpha value to the end of the RGB triplets; thus “redgreen-blue-alpha” becomes RGBa. The alpha stands for alpha channel, which is a measure of opacity. For example, suppose you wanted an element’s text to be half-opaque white. That way, any background color behind the text would “shine through,” mixing with the half-transparent white. You would write one of the following two values: rgba(255,255,255,0.5) rgba(100%,100%,100%,0.5) To make a color completely transparent, you set the alpha value to 0; to be completely opaque, the correct value is 1. Thus rgb(0,0,0) and rgba(0,0,0,1) will yield pre‐ cisely the same result (black). Figure 4-11 shows a series of paragraphs set in increas‐ ingly transparent black, which is the result of the following rules. p.one {color: rgba(0,0,0,1);} p.two {color: rgba(0%,0%,0%,0.8);} p.three {color: rgba(0,0,0,0.6);} p.four {color: rgba(0%,0%,0%,0.4);} p.five {color: rgba(0,0,0,0.2);} Figure 4-11. Text set in progressive translucency As you’ve no doubt already inferred, alpha values are always real numbers in the range 0 to 1. Any value outside that range will either be ignored or reset to the nearest valid alpha value. You cannot use to represent alpha values, despite the mathematical equivalence. 136 | Chapter 4: Values and Units Hexadecimal RGB colors CSS allows you to define a color using the same hexadecimal color notation so familiar to old-school HTML web authors: h1 h2 h3 h4 {color: {color: {color: {color: #FF0000;} #903BC0;} #000000;} #808080;} /* /* /* /* set set set set H1s H2s H3s H4s to to to to red */ a dusky purple */ black */ medium gray */ Computers have been using hex notation for quite some time now, and programmers are typically either trained in its use or pick it up through experience. Their familiar‐ ity with hexadecimal notation likely led to its use in setting colors in HTML. That practice was carried over to CSS. Here’s how it works: by stringing together three hexadecimal numbers in the range 00 through FF, you can set a color. The generic syntax for this notation is #RRGGBB. Note that there are no spaces, commas, or other separators between the three numbers. Hexadecimal notation is mathematically equivalent to integer-pair notation. For example, rgb(255,255,255) is precisely equivalent to #FFFFFF, and rgb(51,102,128) is the same as #336680. Feel free to use whichever notation you prefer—it will be rendered identically by most user agents. If you have a calculator that converts between decimal and hexadecimal, making the jump from one to the other should be pretty simple. For hexadecimal numbers that are composed of three matched pairs of digits, CSS permits a shortened notation. The generic syntax of this notation is #RGB: h1 {color: #000;} h2 {color: #666;} h3 {color: #FFF;} /* set H1s to black */ /* set H2s to dark gray */ /* set H3s to white */ As you can see from the markup, there are only three digits in each color value. How‐ ever, since hexadecimal numbers between 00 and FF need two digits each, and you have only three total digits, how does this method work? The answer is that the browser takes each digit and replicates it. Therefore, #F00 is equivalent to #FF0000, #6FA would be the same as #66FFAA, and #FFF would come out #FFFFFF, which is the same as white. Not every color can be represented in this man‐ ner. Medium gray, for example, would be written in standard hexadecimal notation as #808080. This cannot be expressed in shorthand; the closest equivalent would be #888, which is the same as #888888. Hexadecimal RGBa colors A new (as of late 2017) hexadecimal notation adds a fourth hex value to represent the alpha channel value. Figure 4-11 shows a series of paragraphs set in increasingly Color | 137 transparent black, just as we saw in the previous section, which is the result of the following rules: p.one {color: #000000FF;} p.two {color: #000000CC;} p.three {color: #00000099;} p.four {color: #00000066;} p.five {color: #00000033;} Figure 4-12. Text set in progressive translucency, redux As with non-alpha hexadecimal values, it’s possible to shorten a value composed of matched pairs to a four-digit value. Thus, a value of #663399AA can be written as #639A. If the value has any pairs that are not repetitive, then the entire eight-digit value must be written out: #663399CA cannot be shortened to #639CA. As of late 2017, the alpha-channel hexadecimal notation was sup‐ ported in Firefox and Safari, and had experimental implementa‐ tions in Chrome and Opera. Colors by HSL and HSLa New to CSS3 (though not to the world of color theory in general) are HSL notations. HSL stands for Hue, Saturation, and Lightness, where the hue is a hue angle in the range 0–360, saturation is a percentage value from 0 (no saturation) to 100 (full satu‐ ration), and lightness is a percentage value from 0 (completely dark) to 100 (com‐ pletely light). The hue angle is expressed in terms of a circle around which the full spectrum of col‐ ors progresses. It starts with red at 0 degrees and then proceeds through the rainbow until it comes to red again at 360 degrees. Figure 4-13 illustrates this visually by showing the angles and colors of the spectrum on a wheel as well as a linear strip. If you’re intimately familiar with RGB, then HSL may be confusing at first. (But then, RGB is confusing for people familiar with HSL.) You may be able to better grasp the hues in HSL by contemplating the diagram in Figure 4-14, which shows the spectrum results from placing and then mixing red, green, and blue. 138 | Chapter 4: Values and Units Figure 4-13. The spectrum on a wheel and a strip Figure 4-14. Mixing RGB to create the spectrum Color | 139 As for the other two values, saturation measures the intensity of a color. A saturation of 0% always yields a shade of gray, no matter what hue angle you have set, and a satu‐ ration of 100% creates the most vivid possible shade of that hue for a given lightness. Similarly, lightness defines how dark or light the color appears. A lightness of 0% is always black, regardless of the other hue and saturation values, just as a lightness of 100% always yields white. Consider the results of the following styles, illustrated on the left side of Figure 4-15. p.one {color: hsl(0,0%,0%);} p.two{color: hsl(60,0%,25%);} p.three {color: hsl(120,0%,50%);} p.four {color: hsl(180,0%,75%);} p.five {color: hsl(240,0%,0%);} p.six {color: hsl(300,0%,25%);} p.seven {color: hsl(360,0%,50%);} Figure 4-15. Varying lightness and hues The gray you see on the left side isn’t just a function of the limitations of print: every single one of those bits of text is a shade of gray, because every color value has 0% in the saturation (middle) position. The degree of lightness or darkness is set by the lightness (third) position. In all seven examples, the hue angle changes, and in none of them does it matter. But that’s only so long as the saturation remains at 0%. If that value is raised to, say, 50%, then the hue angle will become very important, because it will control what sort of color you see. Consider the same set of values that we saw before, but all set to 50% saturation, as illustrated on the right side of Figure 4-15. It can be instructive to take the 16 color keywords defined in HTML4 (Table 4-1) and plot them against a hue-and-lightness wheel, as shown in Figure 4-16. The color wheel not only features the full spectrum around the rim, but also runs from 50 per‐ cent lightness at the edge to 0 percent lightness in the center. (The saturation is 100 percent throughout.) As you can see, the 12 keywords of color are regularly placed throughout the wheel, which bespeaks careful choice on the part of whoever chose them. The gray shades aren’t quite as regularly placed, but are probably the most use‐ ful distribution of shades, given that there were only four of them. 140 | Chapter 4: Values and Units Figure 4-16. Keyword-equivalent hue angles and lightnesses Just as RGB has its RGBa counterpart, HSL has an HSLa counterpart. This is an HSL triplet followed by an alpha value in the range 0–1. The following HSLa values are all black with varying shades of transparency, just as in “Hexadecimal RGBa colors” on page 137 (and illustrated in Figure 4-11): p.one {color: hsla(0,0%,0%,1);} p.two {color: hsla(0,0%,0%,0.8);} p.three {color: hsla(0,0%,0%,0.6);} p.four {color: hsla(0,0%,0%,0.4);} p.five {color: hsla(0,0%,0%,0.2);} Color Keywords There are two special keywords that can be used anywhere a color value is permitted. These are transparent and currentColor. As its name suggests, transparent defines a completely transparent color. The CSS Color Module defines it to be equivalent to rgba(0,0,0,0), and that’s its computed value. The is not often used to set text color, for example, but it is essentially the default value for element background colors. It can also be used to define element borders that take up space, but are not visible, and is often used when defining gradi‐ ents—all topics we’ll cover in later chapters. Color | 141 By contrast, currentColor means “whatever the computed value of color is for this element.” Consider the following: main {color: gray; border-color: currentColor;} The first declaration causes any main elements to have a foreground color of gray. The second declaration uses currentColor to copy the computed value of color—in this case, rgb(50%,50%,50%), which is equivalent to gray—and apply it to any bor‐ ders the main elements might have. Angles Since we just finished talking about hue angles in HSL, this would be a good time to talk about angle units. Angles in general are represented as , which is a followed by one of four unit types: deg Degrees, of which there are 360 in a full circle. grad Gradians, of which there are 400 in a full circle. Also known as grades or gons. rad Radians, of which there are 2π (approximately 6.28) in a full circle. turn Turns, of which there is one in a full circle. This unit is mostly useful when ani‐ mating a rotation and you wish to have it turn multiple times, such as 10turn to make it spin 10 times. (Sadly, the pluralization turns is invalid, at least as of late 2017, and will be ignored.) Angle units (Table 4-2) are mostly used in 2D and 3D transforms, though they do appear in a few other places. Note that angle units are not used in HSL colors, where all hue angle values are always degrees and thus do not use the deg unit! Table 4-2. Angle equivalents Degrees Gradians Radians Turns 0deg 0grad 0rad 0turn 45deg 50grad 0.785rad 0.125turn 90deg 100grad 1.571rad 0.25turn 180deg 200grad 3.142rad 0.5turn 270deg 300grad 4.712rad 0.75turn 360deg 400grad 6.283rad 1turn 142 | Chapter 4: Values and Units Time and Frequency In cases where a property needs to express a period of time, the value is represented as and is a followed by either s (seconds) or ms (milliseconds.) Time values are most often used in transitions and animations, either to define dura‐ tions or delays. The following two declarations will have exactly the same result: a[href] {transition-duration: 2.4s;} a[href] {transition-duration: 2400ms;} Time values are also used in aural CSS, again to define durations or delays, but sup‐ port for aural CSS is extremely limited as of this writing. Another value type historically used in aural CSS is , which is a followed by either Hz (hertz) or kHz (kilohertz). As usual, the unit identifiers are case-insensitive, so Hz and hz are equivalent. The following two declarations will have exactly the same result: h1 {pitch: 128hz;} h1 {pitch: 0.128khz;} Position A position value is how you specify the placement of an origin image in a background area, and is represented as . Its syntactical structure is rather complicated: [ [ [ [ [ [ left | center | right | left | center | right | top | center | bottom | center | [ left | right center | [ top | bottom top | bottom | | ] | | ] | ] | ] [ | ]? ] && ] [ | ]? ] ] That might seem a little nutty, but it’s all down to the subtly complex patterns that this value type has to allow. If you declare only one value, such as left or 25%, then a second value is set to center. Thus, left is the same as left center, and 25% is the same as 25% center. If you declare (either implicitly, as above, or explicitly) two values, and the first one is a length or percentage, then it is always considered to be the horizontal value. This means that given 25% 35px, the 25% is a horizontal distance and the 35px is a vertical distance. If you swap them to say 35px 25%, then 35px is horizontal and 25% is verti‐ cal. This means that if you write 25% left or 35px right, the entire value is invalid because you have supplied two horizontal distances and no vertical distance. (Simi‐ larly, a value of right left or top bottom is invalid and will be ignored.) On the other hand, if you write left 25% or right 35px, there is no problem because you’ve Time and Frequency | 143 given a horizontal distance (with the keyword) and a vertical distance (with the per‐ centage or length). If you declare four values (we’ll deal with three just in a moment), then you must have two lengths or percentages, each of which is preceded by a keyword. In this case, each length or percentage specifies an offset distance, and each keyword defines the edge from which the offset is calculated. Thus, right 10px bottom 30px means an offset of 10 pixels to the left of the right edge, and an offset of 30 pixels up from the bottom edge. Similarly, top 50% left 35px means a 50 percent offset from the top and a 35-pixels-to-the-right offset from the left. If you declare three values, the rules are the same as for four, except the last offset is set to be zero (no offset). Thus right 20px top is the same as right 20px top 0. Custom Values As this book was being finished in late 2017, a new capability was being added to CSS. The technical term for this is custom properties, even though what these really do is create sort of variables in your CSS. They do not, contrary to their name, create spe‐ cial CSS properties, in the sense of properties like color or font. Here’s a simple example, with the result shown in Figure 4-17: html { --base-color: #639; --highlight-color: #AEA; } h1 {color: var(--base-color);} h2 {color: var(--highlight-color);} Figure 4-17. Using custom values to color headings There are two things to absorb here. The first is the definition of the custom values -base-color and --highlight-color. These are not some sort of special color types. They’re just names that were picked to describe what the values contain. We could just as easily have said: 144 | Chapter 4: Values and Units html { --alison: #639; --david: #AEA; } h1 {color: var(--alison);} h2 {color: var(--david);} You probably shouldn’t do that sort of thing, unless you’re literally defining colors that specifically correspond to people named Alison and David. (Perhaps on an “About Our Team” page.) It’s always better to define custom identifiers that are selfdocumenting—things like main-color or accent-color or brand-font-face. The important this is that any custom identifier of this type begins with two hyphens (--). It can then be invoked later on using a var() value type. Note that these names are case-sensitive, so --main-color and --Main-color are completely separate iden‐ tifiers. These custom identifiers are often referred to as “CSS variables,” which explains the var() pattern. This labelling has some truth to it, but bear in mind that these are not full-blown variables in the programming-language sense. They’re more like macros in text editors: simple substitutions of one value for another. An interesting feature of custom properties is their ability to scope themselves to a given context. If that sentence made any sense to you, it probably gave a little thrill. If not, here’s an example to illustrate scoping, with the result shown in Figure 4-18: html { --base-color: #639; } aside { --base-color: #F60; } h1 {color: var(--base-color);}

Heading 1

Main text.

Heading 1

Main text.

Custom Values | 145 Figure 4-18. Scoping custom values to certain contexts Notice how the headings are purple outside the aside element and orange inside. That’s because the variable --base-color was updated for aside elements. The new custom value applies to any h1 inside an aside element. There are a great many patterns possible with CSS variables, even if they are confined to value replacement. Here’s an example suggested by Chriztian Steinmeier combin‐ ing variables with the calc() value type to create a regular set of indents for unor‐ dered lists: html { --gutter: 3ch; --offset: 1; } ul li {margin-left: calc(var(--gutter) * var(--offset));} ul ul li {--offset: 2;} ul ul ul li {--offset: 3;} This particular example is basically the same as writing: ul li {margin-left: 3ch;} ul ul li {margin-left: 6ch;} ul ul ul li {margin-left: 9ch;} The difference is that with variables, it’s simple to update the --gutter multiplier in one place and have everything adjust automatically, rather than having to retype three values and make sure all the math is correct. This method of using abstract variable names opens an entirely new way of styling, an approach which has little precedent in the history of CSS. If you want to try out 146 | Chapter 4: Values and Units custom properties but are concerned about support, remember the @supports() fea‐ ture query. Using this approach will keep your variable styling safely hidden away: @supports (color: var(--custom)) { /* variable-dependent styles go here */ } @supports (--custom: value) { /* alternate query pattern */ } To reiterate: custom properties were just going into production as of late 2017, as the book was being finished. There were still uncer‐ tainties to be worked out around how custom properties should be used, how powerful they may become, how they relate to the cas‐ cade, and more. While they’re worth knowing about and experi‐ menting with, bear in mind that anything stated here may have changed or been removed by the time you read this. Custom Values | 147 CHAPTER 5 Fonts The beginning of the “Font Properties” section of the CSS1 specification, written in 1996, begins with this sentence: “Setting font properties will be among the most com‐ mon uses of style sheets.” The intervening years have done nothing to disprove this assertion. CSS2 added the ability to specify custom fonts for download with @font-face, but it wasn’t until about 2009 that this capability really began to be widely and consistently supported. Now, websites can call on any font they have the right to use, aided by online services such as Typekit. Generally speaking, if you can get access to a font, you can use it in your design. It’s important to remember, however, that this does not grant absolute control over fonts. If the font you’re using fails to download, or is in a file format the user’s browser doesn’t understand, then the text will be displayed with a fallback font. That’s a good thing, since it means the user still gets your content, but it’s worth bearing in mind that you cannot absolutely depend on the presence of a given font and should never design as if you can. Font Families What we think of as a “font” is usually composed of many variations to describe bold text, italic text, and so on. For example, you’re probably familiar with (or at least have heard of) the font Times. However, Times is actually a combination of many variants, including TimesRegular, TimesBold, TimesItalic, TimesBoldItalic, and so on. Each of these variants of Times is an actual font face, and Times, as we usually think of it, is a combination of all these variant faces. In other words, Times is actually a font family, not just a single font, even though most of us think about fonts as being single enti‐ ties. 149 In order to cover all the bases, CSS defines five generic font families: Serif fonts These fonts are proportional and have serifs. A font is proportional if all charac‐ ters in the font have different widths due to their various sizes. For example, a lowercase i and a lowercase m are different widths. (This book’s paragraph font is proportional, for example.) Serifs are the decorations on the ends of strokes within each character, such as little lines at the top and bottom of a lowercase l, or at the bottom of each leg of an uppercase A. Examples of serif fonts are Times, Georgia, and New Century Schoolbook. Sans-serif fonts These fonts are proportional and do not have serifs. Examples of sans-serif fonts are Helvetica, Geneva, Verdana, Arial, and Univers. Monospace fonts Monospace fonts are not proportional. These generally are used for displaying programmatic code or tabular data. In these fonts, each character uses up the same amount of horizontal space as all the others; thus, a lowercase i takes up the same horizontal space as a lowercase m, even though their actual letterforms may have different widths. These fonts may or may not have serifs. If a font has uni‐ form character widths, it is classified as monospace, regardless of the presence of serifs. Examples of monospace fonts are Courier, Courier New, Consolas, and Andale Mono. Cursive fonts These fonts attempt to emulate human handwriting or lettering. Usually, they are composed largely of flowing curves and have stroke decorations that exceed those found in serif fonts. For example, an uppercase A might have a small curl at the bottom of its left leg or be composed entirely of swashes and curls. Examples of cursive fonts are Zapf Chancery, Author, and Comic Sans. Fantasy fonts Such fonts are not really defined by any single characteristic other than our inability to easily classify them in one of the other families (these are sometimes called “decorative” or “display” fonts). A few such fonts are Western, Woodblock, and Klingon. In theory, every font family will fall into one of these generic families. In practice, this may not be the case, but the exceptions (if any) are likely to be few and far between, and browsers are likely to drop any fonts they cannot classify as serif, sans-serif, monospace, or cursive into the “fantasy” bucket. 150 | Chapter 5: Fonts Using Generic Font Families You can call on any available font family by using the property font-family. font-family Values Initial value Applies to Computed value Inherited Animatable [ | ]# User agent-specific All elements As specified Yes No If you want a document to use a sans-serif font, but you do not particularly care which one, then the appropriate declaration would be: body {font-family: sans-serif;} This will cause the user agent to pick a sans-serif font family (such as Helvetica) and apply it to the body element. Thanks to inheritance, the same font family choice will be applied to all the elements that descend from the body—unless a more specific selector overrides it. Using nothing more than these generic families, an author can create a fairly sophisti‐ cated stylesheet. The following rule set is illustrated in Figure 5-1: body {font-family: serif;} h1, h2, h3, h4 {font-family: sans-serif;} code, pre, tt, kbd {font-family: monospace;} p.signature {font-family: cursive;} Thus, most of the document will use a serif font such as Times, including all para‐ graphs except those that have a class of signature, which will instead be rendered in a cursive font such as Author. Heading levels 1 through 4 will use a sans-serif font like Helvetica, while the elements code, pre, tt, and kbd will use a monospace font like Courier. Font Families | 151 Figure 5-1. Various font families Specifying a Font Family An author may, on the other hand, have more specific preferences for which font to use in the display of a document or element. In a similar vein, a user may want to create a user stylesheet that defines the exact fonts to be used in the display of all documents. In either case, font-family is still the property to use. Assume for the moment that all h1s should use Georgia as their font. The simplest rule for this would be the following: h1 {font-family: Georgia;} This will cause the user agent displaying the document to use Georgia for all h1s, as shown in Figure 5-2. Figure 5-2. An h1 element using Georgia This rule assumes that the user agent has Georgia available for use. If it doesn’t, the user agent will be unable to use the rule at all. It won’t ignore the rule, but if it can’t find a font called “Georgia,” it can’t do anything but display h1 elements using the user agent’s default font (whatever that is). All is not lost, however. By combining specific font names with generic font families, you can create documents that come out, if not exact, at least close to your intentions. 152 | Chapter 5: Fonts To continue the previous example, the following markup tells a user agent to use Georgia if it’s available, and to use another serif font if it’s not: h1 {font-family: Georgia, serif;} If a reader doesn’t have Georgia installed but does have Times, the user agent might use Times for h1 elements. Even though Times isn’t an exact match to Georgia, it’s probably close enough. For this reason, I strongly encourage you to always provide a generic family as part of any font-family rule. By doing so, you provide a fallback mechanism that lets user agents pick an alternative when they can’t provide an exact font match. Here are a few more examples: h1 {font-family: Arial, sans-serif;} h2 {font-family: Charcoal, sans-serif;} p {font-family: 'Times New Roman', serif;} address {font-family: Chicago, sans-serif;} If you’re familiar with fonts, you might have a number of similar fonts in mind for displaying a given element. Let’s say that you want all paragraphs in a document to be displayed using Times, but you would also accept Times New Roman, Georgia, New Century Schoolbook, and New York (all of which are serif fonts) as alternate choices. First, decide the order of preference for these fonts, and then string them together with commas: p {font-family: Times, 'Times New Roman', 'New Century Schoolbook', Georgia, 'New York', serif;} Based on this list, a user agent will look for the fonts in the order they’re listed. If none of the listed fonts are available, then it will just pick an available serif font. Using quotation marks You may have noticed the presence of single quotes in the previous example, which we haven’t seen before. Quotation marks are advisable in a font-family declaration only if a font name has one or more spaces in it, such as “New York,” or if the font name includes symbols such as # or $. Thus, a font called Karrank% should probably be quoted: h2 {font-family: Wedgie, 'Karrank%', Klingon, fantasy;} If you leave off the quotation marks, there is a chance that user agents will ignore that particular font name altogether, although they’ll still process the rest of the rule. Note that the quoting of a font name containing a symbol is not actually required any more. Instead, it’s recommended, which is as close to describing best practices as the CSS specification ever really gets. Similarly, it is recommended that you quote a font name containing spaces, though again, this is generally unnecessary in modern user agents. As it turns out, the only required quotation is for font names that match Font Families | 153 accepted font-family keywords. Thus, if you call for a font whose actual name is “cursive,” you’ll definitely need to quote it in order to distinguish it from the value keyword cursive: h2 {font-family: Author, "cursive", cursive;} Font names that use a single word (which doesn’t conflict with any of the keywords for font-family) need not be quoted, and generic family names (serif, monospace, etc.) should never be quoted when they refer to the actual generic families. If you quote a generic name, then the user agent will assume that you are asking for a spe‐ cific font with that name (for example, “serif ”), not a generic family. As for which quotation marks to use, both single and double quotes are acceptable. Remember that if you place a font-family rule in a style attribute, which you gen‐ erally shouldn’t, you’ll need to use whichever quotes you didn’t use for the attribute itself. Therefore, if you use double quotes to enclose the font-family rule, then you’ll have to use single quotes within the rule, as in the following markup: p {font-family: sans-serif;} /* sets paragraphs to sans-serif by default */

...

...

If you use double quotes in such a circumstance, they interfere with the attribute syn‐ tax, as you can see in Figure 5-3. Figure 5-3. The perils of incorrect quotation marks Using @font-face A feature that originally debuted in CSS2 but wasn’t implemented until late in the first decade of the 2000s, @font-face lets you use custom fonts in your designs. While there’s no guarantee that every last user will see the font you want, this feature is very widely supported. Suppose you want to use a very specific font in your stylesheets, one that is not widely installed. Through the magic of @font-face, you can define a specific family name to correspond to a font file on your server. The user agent will download that file and 154 | Chapter 5: Fonts use it to render the text in your page, the same as if it were installed on the user’s machine. For example: @font-face { font-family: "SwitzeraADF"; src: url("SwitzeraADF-Regular.otf"); } This allows the author to have conforming user agents load the defined .otf file and use that font to render text when called upon via font-family: SwitzeraADF. The examples in this section refer to SwitzeraADF, a font face col‐ lection available from the Arkandis Digital Foundry. The intent of @font-face is to allow lazy loading of font faces. This means that only those faces needed to render a document will actually be loaded, with the rest being left alone. In fact, a browser that downloads all declared font faces without consider‐ ing whether they’re actually needed is considered to be buggy. Required Descriptors All the parameters that define the font you’re referencing are contained within the @font-face { } construct. These are called descriptors, and very much like proper‐ ties, they take the format descriptor: value;. In fact, most of the descriptor names refer directly to property names, as will be explained in just a moment. There are two required descriptors: font-family and src. font-family Value Initial value Not defined src Values [ [ [format(#)]? ] | ]# Initial value Not defined Using @font-face | 155 The point of src is pretty straightforward: it lets you define one or more sources for the font face you’re defining, using a comma-separated list if there are in fact multiple sources. You can point to a font face at any URI, but there is a restriction: font faces can only be loaded from the same origin as the stylesheet. Thus, you can’t point your src at someone else’s site and download their font; you’ll need to host a local copy on your own server, or use a font-hosting service that provides both the stylesheet(s) and the font file(s). There is an exception to the same-origin restriction, which is that servers can permit cross-site loading using the HTTP header Access-Control-Allow-Origin. You may well be wondering how it is that we’re defining font-family here when it was already defined in a previous section. The difference is that this font-family is the font-family descriptor, and the previously-defined font-family was the fontfamily property. If that seems confusing, stick with me a moment and all should become clear. In effect, @font-face lets you create low-level definitions that underpin the fontrelated properties like font-family. When you define a font family name via the descriptor font-family: "SwitzeraADF";, you’re setting up an entry in the user agent’s table of font families for “SwitzeraADF.” It thus joins all the usual suspects like Helvetica, Georgia, Courier, and so forth, as a font you can just refer to in your fontfamily property values: @font-face { font-family: "SwitzeraADF"; /* descriptor */ src: url("SwitzeraADF-Regular.otf"); } h1 {font-family: SwitzeraADF, Helvetica, sans-serif;} /* property */ Note how the font-family descriptor value and the entry in the font-family prop‐ erty match. If they didn’t match, then the h1 rule would ignore the first font family name listed in the font-family value and move on to the next. As long as the font has cleanly downloaded and is in a format the user agent can handle, then it will be used in the manner you direct, as illustrated in Figure 5-4. 156 | Chapter 5: Fonts Figure 5-4. Using a downloaded font In a similar manner, the comma-separated src descriptor value provides fallbacks. That way, if (for whatever reason) the user agent is unable to download the first source, it can fall back to the second source and try to load the file there: @font-face { font-family: "SwitzeraADF"; src: url("SwitzeraADF-Regular.otf"), url("/fonts/SwitzeraADF-Regular.otf"); } Remember that the same-origin policy generally applies in this case, so pointing to a copy of the font some other server will usually fail, unless said server is set up to per‐ mit cross-origin access. If you want to be sure the user agent understands what kind of font you’re telling it to use, that can be done with the optional format(): @font-face { font-family: "SwitzeraADF"; src: url("SwitzeraADF-Regular.otf") format("opentype"); } The advantage of supplying a format() description is that user agents can skip down‐ loading files in formats that they don’t support, thus reducing bandwidth use and loading speed. It also lets you explicitly declare a format for a file that might not have a common filename extension and thus be unfamiliar to the user agent: @font-face { font-family: "SwitzeraADF"; src: url("SwitzeraADF-Regular.otf") format("opentype"), url("SwitzeraADF-Regular.true") format("truetype"); } Using @font-face | 157 The Flash If you’re a designer or developer of a certain vintage, you may remember the days of FOUC: the Flash of Unstyled Content. This happened in earlier browsers that would load the HTML and display it to the screen before the CSS was finished loading, or at least before the layout of the page via CSS was finished. Thus, what would appear was a split-second of plain ol’ text (using the browser’s default styles) before it was replaced with the CSS-decorated layout. There is a cousin to this problem, which is the Flash of Un-Fonted Text, or FOUFT. This happens when a browser has loaded the page and the CSS and displays the laidout page before it’s done loading custom fonts. This causes text to appear in the default font, or a fallback font, before being replaced by text using the custom-loaded font. Since the replacement of text with the custom-loaded font face can change its layout size, authors should take care in selecting fallback fonts. If there is a significant height difference between the font used to initially display the text and the custom font even‐ tually loaded and used, significant page reflows are likely to occur. There’s no automa‐ ted way to enforce this, though font-size-adjust (covered later) can help in supporting user agents. You have to look at your intended font and find other faces that have a similar height. The core reason for the “flash” behavior is pretty much the same now as it was then: the browser is ready to show something before it has all the resources on hand, so it goes ahead and does so, replacing it with the prettier version once it can. The FOUC was eventually solved, and it’s likely that some day we’ll look back at the FOUFT the same way we do at the FOUC now. Until then, we’ll have to take comfort in the fact that the FOUFT isn’t usually as jarring as was the FOUC. Table 5-1 lists all of the allowed format values (as of late 2017). Table 5-1. Recognized font format values Value Format embedded-opentype EOT (Embedded OpenType) opentype OTF (OpenType) svg SVG (Scalable Vector Graphics) truetype TTF (TrueType) woff WOFF (Web Open Font Format) 158 | Chapter 5: Fonts In addition to the combination of url() and format(), you can also supply a font family name (or several names) in case the font is already locally available on the user’s machine, using the aptly-named local(): @font-face { font-family: "SwitzeraADF"; src: local("Switzera-Regular"), local("SwitzeraADF-Regular "), url("SwitzeraADF-Regular.otf") format("opentype"), url("SwitzeraADF-Regular.true") format("truetype"); } In this example, the user agent looks to see if it already has a font family named “Switzera-Regular” or “SwitzeraADF-Regular” available. If so, it will use the name SwitzeraADF to refer to that locally installed font. If not, it will use the url() value to try downloading the remote font. Note that this capability allows an author to create custom names for locally installed fonts. For example, you could set up a shorter name for Helvetica (or, failing that, Helvetica Neue) like so: @font-face { font-family: "H"; src: local("Helvetica"), local("Helvetica Neue"); } h1, h2, h3 {font-family: H, sans-serif;} As long as the user has Helvetica installed on their machine, then those rules will cause the first three heading levels to be rendered using Helvetica. It seems a little gimmicky, but it could have a real impact on reducing stylesheet file size in certain situations. On being bulletproof The tricky part with @font-face is that different browsers of different eras supported different font formats. (To the insider, Table 5-1 reads as a capsule history of down‐ loadable font support.) In order to cover the widest possible landscape, you should turn to what is known as the “Bulletproof @font-face Syntax.” Initially developed by Paul Irish and refined by the folks at FontSpring, it looks like this: @font-face { font-family: "SwitzeraADF"; src: url("SwitzeraADF-Regular.eot"); src: url("SwitzeraADF-Regular.eot?#iefix") format("embedded-opentype"), url("SwitzeraADF-Regular.woff") format("woff"), url("SwitzeraADF-Regular.ttf") format("truetype"), url("SwitzeraADF-Regular.svg#switzera_adf_regular") format("svg"); } Using @font-face | 159 Let’s break it down piece by piece. The first bit, assigning the font-family name, is straightforward enough. After that, we see: src: url("SwitzeraADF-Regular.eot"); src: url("SwitzeraADF-Regular.eot?#iefix") format("embedded-opentype"), This supplies an EOT (Embedded OpenType) to browsers that understand only EOTs —IE6 through IE9. The first line is for IE9 when it’s in “Compatibility Mode,” and the second line hands the same file to IE6-IE8. The ?#iefix bit in that line exploits a parsing bug in those browsers to step around another parsing bug that causes them to 404 any @font-face with multiple formats listed. IE9 fixed its bugs without expand‐ ing its font formats, so the first line is what lets it join the party: url("SwitzeraADF-Regular.woff") format("woff"), This line supplies a Web Open Font Format file to browsers that understand it, which includes most modern browsers. At this point, in fact, you’ll have covered the vast majority of your desktop users. url("SwitzeraADF-Regular.ttf") format("truetype"), This line hands over the file format understood by most iOS and Android devices, thus covering most of your handheld users: url("SwitzeraADF-Regular.svg#switzera_adf_regular") format("svg"); Here, at the end, we supply the only font format understood by old iOS devices. This covers almost all of your remaining handheld users. This gets a bit unwieldy if you’re specifying more than a couple of faces, and typing it in even once is kind of a pain in the wrists. Fortunately, there are services available that will accept your font faces and generate all the @font-face rules you need, con‐ vert those faces to all the formats required, and hand it all back to you as a single package. One of the best is Font Squirrel’s @Font-Face Kit Generator. Just make sure you’re legally able to convert and use the font faces you’re running through the gener‐ ator (see the next sidebar, “Custom Font Considerations” on page 161, for more information). Other Font Descriptors In addition to the required font-family and src descriptors, there are a number of optional descriptors that can be used to associate font faces with specific font prop‐ erty values. Just as with font-family, these descriptors (summarized in Table 5-2) 160 | Chapter 5: Fonts correspond directly to CSS properties (explained in detail later in this chapter) and affect how user agents respond to the values supplied for those properties. Custom Font Considerations There are two things you need to keep in mind when using customized fonts. The first is that you have the rights to use the font in a web page, and the second is whether it’s a good idea to do so. Much like stock photography, font families come with licenses that govern their use, and not every font license permits its use on the web. You can completely avoid this question by only using FOSS (Free and Open-Source Software) fonts, or by using a commercial service like Fontdeck or Typekit that will deal with the licensing and for‐ mat conversion issues so you don’t have to. Otherwise, you need to make sure that you have the right to use a font face in the way you want to use it, just the same as you make sure you have the proper license for any images you bought. In addition, the more font faces you call upon, the more resources the web server has to hand over and the higher the overall page weight will become. Most faces are not overly large—usually 50K to 100K—but they add up quickly if you decide to get fancy with your type, and truly complicated faces can be larger. As you might imagine, the same problems exist for images. As always, you will have to balance appearance against performance, leaning one way or the other depending on the circumstances. Furthermore, just as there are image optimization tools available, there are also font optimization tools. Typically these are subsetting tools, which construct fonts using only the symbols actually needed for display. If you’re using a service like Typekit or Fonts.com, they probably have subsetting tools available, or else do it dynamically when the font is requested. Table 5-2. Font descriptors Descriptor Default value font-style normal Description Distinguishes between normal, italic, and oblique faces font-weight normal Distinguishes between various weights (e.g., bold) font-stretch normal Distinguishes between varying degrees of character widths (e.g., condensed and expanded) font-variant normal Distinguishes between a staggeringly wide range of potential variant faces (e.g., small-caps); in most ways, a more “CSS-like” version of font-feature- font-featuresettings normal unicode-range U+0-10FFFF Defines the range of characters for which a given face may be used settings Permits direct access to low-level OpenType features (e.g., enabling ligatures) Using @font-face | 161 Because these font descriptors are optional, they may not be listed in a @font-face rule, but CSS does not allow descriptors to go without default values any more than it does for properties. If an optional descriptor is omitted, then it is set to the default value. Thus, if font-weight is not listed, the default value of normal is assumed. Restricting character range There is one font descriptor, unicode-range, which (unlike the others in Table 5-2) has no corresponding CSS property. This descriptor allows authors to define the range of characters to which a custom font can be applied. This can be useful when using a symbol font, or to ensure that a font face is only applied to characters that are in a specific language. unicode-range Values # Initial value U+0-10FFFF By default, the value of this property covers the entirety of Unicode, meaning that if a font can supply the glyph for a character, it will. Most of the time, this is exactly what you want. For all the other times, you’ll want to use a specific font face for a specific kind of content. To pick two examples from the CSS Fonts Module Level 3: unicode-range: U+590-5FF; /* Hebrew characters */ unicode-range: U+4E00-9FFF, U+FF00-FF9F, U+30??; /* Japanese kanji, hiragana, katakana */ In the first case, a single range is specified, spanning Unicode character code point 590 through code point 5FF. This covers the characters used in Hebrew. Thus, an author might specify a Hebrew font and restrict it to only be used for Hebrew charac‐ ters, even if the face contains glyphs for other code points: @font-face { font-family: "CMM-Ahuvah"; src: url("cmm-ahuvah.otf" format("opentype"); unicode-range: U+590-5FF; } In the second case, a series of ranges are specified in a comma-separated list to cover all the Japanese characters. The interesting feature there is the U+30?? value, which is a special format permitted in unicode-range values. The question marks are wild‐ cards meaning “any possible digit,” making U+30?? equivalent to U+3000-30FF. The question mark is the only “special” character pattern permitted in the value. 162 | Chapter 5: Fonts Ranges must always ascend. Any descending range (e.g., U+400-300) is treated as a parsing error and ignored. Besides ranges, you can also declare a single code point, which looks like U+221E. This is most often useful in conjunction with other code points and ranges, like so: unicode-range: U+4E00-9FFF, U+FF00-FF9F, U+30??, U+A5; /* Japanese kanji, hiragana, and katakana, plus yen/yuan currency symbol*/ You could use a single code point to declare that a specific face only be used to render one, and only one, character. Whether or not that’s a good idea is left to you, your design, the size of the font file, and your users’ connection speeds. Because @font-face is designed to optimize lazy loading, it’s possible to use unicoderange to download only the font faces a page actually needs. Suppose that you have a website that uses a mixture of English, Russian, and basic mathematical operators, but you don’t know which will appear on any given page. There could be all English, a mixture of Russian and math, and so on. Furthermore, suppose you have special font faces for all three types of content. You can make sure a user agent only downloads the faces it actually needs with a properly-constructed series of @font-face rules: @font-face { font-family: "MyFont"; src: url("myfont-general.otf" format("opentype"); } @font-face { font-family: "MyFont"; src: url("myfont-cyrillic.otf" format("opentype"); unicode-range: U+04??, U+0500-052F, U+2DE0-2DFF, U+A640-A69F, U+1D2B-1D78; } @font-face { font-family: "MyFont"; src: url("myfont-math.otf" format("opentype"); unicode-range: U+22??; /* equivalent to U+2200-22FF */ } Because the first rule doesn’t specify a Unicode range, it is always downloaded— unless a page happens to contain no characters at all (and maybe even then). The sec‐ ond rule causes myfont-cyrillic.otf to be downloaded only if the page contains characters in its declared Unicode range; the third rule does the same for basic math‐ ematical operators. Combining Descriptors Something that might not be immediately obvious is that you can supply multiple descriptors in order to assign specific faces for specific property combinations. For example, you can assign one face to bold text, another to italic text, and a third to text that is both bold and italic. Using @font-face | 163 This is actually implicit in the fact that any undeclared descriptor is assigned its default value. Let’s consider a basic set of three face assignments: @font-face { font-family: "SwitzeraADF"; font-weight: normal; font-style: normal; font-stretch: normal; src: url("SwitzeraADF-Regular.otf") format("opentype"); } @font-face { font-family: "SwitzeraADF"; font-weight: bold; font-style: normal; font-stretch: normal; src: url("SwitzeraADF-Bold.otf") format("opentype"); } @font-face { font-family: "SwitzeraADF"; font-weight: normal; font-style: italic; font-stretch: normal; src: url("SwitzeraADF-Italic.otf") format("opentype"); } Here, we’ve made the implicit explicit: any time a descriptor isn’t being altered, its default value is listed. This is exactly the same as a set of three rules in which we remove every descriptor that shows a value of normal: @font-face { font-family: "SwitzeraADF"; src: url("SwitzeraADF-Regular.otf") format("opentype"); } @font-face { font-family: "SwitzeraADF"; font-weight: bold; src: url("SwitzeraADF-Bold.otf") format("opentype"); } @font-face { font-family: "SwitzeraADF"; font-style: italic; src: url("SwitzeraADF-Italic.otf") format("opentype"); } In all three rules, there is no font-stretching beyond the normal amount, and the val‐ ues of font-weight and font-style vary by which face is being assigned. So what if we want to assign a specific face to unstretched text that’s both bold and italic? @font-face { font-family: "SwitzeraADF"; font-weight: bold; font-style: italic; 164 | Chapter 5: Fonts font-stretch: normal; src: url("SwitzeraADF-BoldItalic.otf") format("opentype"); } And then what about bold, italic, condensed text? @font-face { font-family: "SwitzeraADF"; font-weight: bold; font-style: italic; font-stretch: condensed; src: url("SwitzeraADF-BoldCondItalic.otf") format("opentype"); } How about normal-weight, italic, condensed text? @font-face { font-family: "SwitzeraADF"; font-weight: normal; font-style: italic; font-stretch: condensed; src: url("SwitzeraADF-CondItalic.otf") format("opentype"); } We could keep this up for quite a while, but let’s stop there. If we take all those rules and strip out anything with a normal value, we end up with this result, illustrated in Figure 5-5: @font-face { font-family: "SwitzeraADF"; src: url("SwitzeraADF-Regular.otf") format("opentype"); } @font-face { font-family: "SwitzeraADF"; font-weight: bold; src: url("SwitzeraADF-Bold.otf") format("opentype"); } @font-face { font-family: "SwitzeraADF"; font-style: italic; src: url("SwitzeraADF-Italic.otf") format("opentype"); } @font-face { font-family: "SwitzeraADF"; font-weight: bold; font-style: italic; src: url("SwitzeraADF-BoldItalic.otf") format("opentype"); } @font-face { font-family: "SwitzeraADF"; font-weight: bold; font-stretch: condensed; src: url("SwitzeraADF-BoldCond.otf") format("opentype"); } Using @font-face | 165 @font-face { font-family: "SwitzeraADF"; font-style: italic; font-stretch: condensed; src: url("SwitzeraADF-CondItalic.otf") format("opentype"); } @font-face { font-family: "SwitzeraADF"; font-weight: bold; font-style: italic; font-stretch: condensed; src: url("SwitzeraADF-BoldCondItalic.otf") format("opentype"); } Figure 5-5. Employing a variety of faces As you can see, there are a lot of possible combinations just for those three descrip‐ tors—consider that there are 11 possible values for font-weight, and 10 for fontstretch—but you’ll likely never have to run through them all. In fact, most font families don’t have as many faces as SwitzeraADF offers (24 at last count), so there wouldn’t be much point in writing out all the possibilities. Nevertheless, the options are there, and in some cases you may find that you need to assign, say, a specific face for bold condensed text so that the user agent doesn’t try to compute them for you. Font Weights Now that we’ve covered @font-face and its descriptors, let’s get back to properties. We’re all used to normal and bold text, at the very least, which are sort of the two most basic font weights available. CSS gives you a lot more control over font weights with the property font-weight. font-weight 166 Values normal | bold | bolder | lighter | 100 | 200 | 300 | 400 | 500 | 600 | 700 | 800 | 900 Initial value normal Applies to All elements | Chapter 5: Fonts Computed value One of the numeric values (100, etc.), or one of the numeric values plus one of the relative values (bolder or lighter) Note Has a corresponding @font-face descriptor Inherited Animatable Yes No Generally speaking, the heavier a font weight becomes, the darker and “more bold” a font appears. There are a great many ways to label a heavy font face. For example, the font family known as SwitzeraADF has a number of variants, such as SwitzeraADF Bold, SwitzeraADF Extra Bold, SwitzeraADF Light, and SwitzeraADF Regular. All of these use the same basic font shapes, but each has a different weight. So let’s say that you want to use SwitzeraADF for a document, but you’d like to make use of all those different heaviness levels. You could refer to them directly through the font-family property, but you really shouldn’t have to do that. Besides, it’s no fun having to write a stylesheet like this: h1 {font-family: 'SwitzeraADF Extra Bold, sans-serif;} h2 {font-family: 'SwitzeraADF Bold, sans-serif;} h3 {font-family: 'SwitzeraADF Bold', sans-serif;} h4, p {font-family: SwitzeraADF Regular, sans-serif;} small {font-family: 'SwitzeraADF Light', sans-serif;} That’s pretty tedious. It would make far more sense to specify a single font family for the whole document and then assign different weights to various elements. You can do this via @font-face and use the various values for the property font-weight. This is a fairly simple font-weight declaration: b {font-weight: bold;} This declaration says the b element should be displayed using a bold font face; or, to put it another way, a font face that is heavier than the normal font face. This is proba‐ bly expected behavior, since b does cause text to be bold. What’s really happening behind the scenes is that a heavier face of the font is used for displaying a b element. Thus, if you have a paragraph displayed using Times, and part of it is bold, then there are really two faces of the same font in use: Times and Time‐ sBold. The regular text is displayed using Times, and the bold text is displayed using TimesBold. How Weights Work To understand how a user agent determines the heaviness, or weight, of a given font variant (not to mention how weight is inherited), it’s easiest to start by talking about the keywords 100 through 900. These number keywords were defined to map to a Font Weights | 167 relatively common feature of font design in which a font is given nine levels of weight. If a font family has faces for all nine weight levels available, then the numbers are mapped directly to the predefined levels, with 100 as the lightest variant of the font and 900 as the heaviest. In fact, there is no intrinsic weight in these numbers. The CSS specification says only that each number corresponds to a weight at least as heavy as the number that pre‐ cedes it. Thus, 100, 200, 300, and 400 might all map to the same relatively lightweight variant; 500 and 600 could correspond to the same heavier font variant; and 700, 800, and 900 could all produce the same very heavy font variant. As long as no keyword corresponds to a variant that is lighter than the variant assigned to the previous key‐ word, everything will be all right. As it happens, these numbers are defined to be equivalent to certain common variant names, not to mention other values for font-weight. 400 is defined to be equivalent to normal, and 700 corresponds to bold. The other numbers do not match up with any other values for font-weight, but they can correspond to common variant names. If there is a font variant labeled something such as “Normal,” “Regular,” “Roman,” or “Book,” then it is assigned to the number 400 and any variant with the label “Medium” is assigned to 500. However, if a variant labeled “Medium” is the only variant available, it is assigned to 400 instead of 500. A user agent has to do even more work if there are fewer than nine weights in a given font family. In this case, it must fill in the gaps in a predetermined way: • If the value 500 is unassigned, it is given the same font weight as that assigned to 400. • If 300 is unassigned, it is given the next variant lighter than 400. If no lighter var‐ iant is available, 300 is assigned the same variant as 400. In this case, it will usu‐ ally be “Normal” or “Medium.” This method is also used for 200 and 100. • If 600 is unassigned, it is given the next variant darker than that assigned for 500. If no darker variant is available, 600 is assigned the same variant as 500. This method is also used for 700, 800, and 900. To illustrate this weighting scheme more clearly, let’s look at three examples of font weight assignment. In the first example, assume that the font family Karrank% is an OpenType font, so it has nine weights already defined. In this case, the numbers are assigned to each level, and the keywords normal and bold are assigned to the num‐ bers 400 and 700, respectively. This is the most straightforward example, and there‐ fore the one that almost never occurs in the real world. (It is quite rare for a font family to have nine weight levels, and those that do are usually very expensive.) 168 | Chapter 5: Fonts In our second example, consider the font family SwitzeraADF, which was discussed near the beginning of this section. Hypothetically, its variants might be assigned numeric values for font-weight, as shown in Table 5-3. Table 5-3. Hypothetical weight assignments for a specific font family Font face SwitzeraADF Light Assigned keyword Assigned number(s) SwitzeraADF Regular normal 400 bold 600, 700 100, 200, 300 SwitzeraADF Medium SwitzeraADF Bold 500 SwitzeraADF Extra Bold 800, 900 The first three number values are assigned to the lightest weight. The “Regular” face gets the keyword normal, as expected, and the number weight 400. Since there is a “Medium” font, it’s assigned to the number 500. There is nothing to assign to 600, so it’s mapped to the “Bold” font face, which is also the variant to which 700 and bold are assigned. Finally, 800 and 900 are assigned to the “Black” and “UltraBlack” var‐ iants, respectively. Note that this last assignment would happen only if those faces had the top two weight levels already assigned. Otherwise, the user agent might ignore them and assign 800 and 900 to the “Bold” face instead, or it might assign them both to one or the other of the “Black” variants. For our third and final example, let’s consider a stripped-down version of Times. In Table 5-4, there are only two weight variants: “TimesRegular” and “TimesBold.” Table 5-4. Hypothetical weight assignments for “Times” Font face Assigned keyword Assigned numbers TimesRegular normal 100, 200, 300, 400, 500 TimesBold bold 600, 700, 800, 900 The assignment of the keywords normal and bold is to the regular-weight and boldweight faces, as you might expect. As for the numbers, 100 through 300 are assigned to the “Regular” face because there isn’t a lighter face available. 400 is assigned to “Regular” as expected, but what about 500? It is assigned to the “Regular” (or normal) face because there isn’t a “Medium” face available; thus, it is assigned the same font face as 400. As for the rest, 700 goes with bold as always, while 800 and 900, lacking a heavier face, are assigned to the next-lighter face, which is the “Bold” font face. Finally, 600 is assigned to the next-heavier face, which is the “Bold” face. font-weight is inherited, so if you set a paragraph to be bold: p.one {font-weight: bold;} Font Weights | 169 Then all of its children will inherit that boldness, as we see in Figure 5-6. Figure 5-6. Inherited font-weight This isn’t unusual, but the situation gets interesting when you use the last two values we have to discuss: bolder and lighter. In general terms, these keywords have the effect you’d anticipate: they make text more or less bold compared to its parent’s font weight. First, let’s consider bolder. Getting Bolder If you set an element to have a weight of bolder, then the user agent first must deter‐ mine what font-weight value was inherited from the parent element. It then selects the lowest number which corresponds to a font weight darker than what was inher‐ ited. If none is available, then the user agent sets the element’s font weight to the next numerical value, unless the value is already 900, in which case the weight remains at 900. Thus, you might encounter the following situations, illustrated in Figure 5-7: p {font-weight: normal;} p em {font-weight: bolder;} /* results in bold text, evaluates to '700' */ h1 {font-weight: bold;} h1 b {font-weight: bolder;} /* if no bolder face exists, evaluates to '800' */ div {font-weight: 100;} /* assume 'Light' face exists; see explanation */ div strong {font-weight: bolder;} /* results in normal text, weight '400' */ Figure 5-7. Text trying to be bolder In the first example, the user agent moves up the weight ladder from normal to bold; in numeric terms, it jumps from 400 to 700. In the second example, h1 text is already set to bold. If there is no bolder face available, then the user agent sets the weight of b text within an h1 to 800, since that is the next step up from 700 (the numeric equiva‐ lent of bold). Since 800 is assigned to the same font face as 700, there is no visible 170 | Chapter 5: Fonts difference between normal h1 text and bold h1 text, but the weights are different nonetheless. In the last example, paragraphs are set to be the lightest possible font weight, which we assume exists as a “Light” variant. Furthermore, the other faces in this font family are “Regular” and “Bold.” Any em text within a paragraph will evaluate to normal since that is the next-heaviest face within the font family. However, what if the only faces in the font are “Regular” and “Bold”? In that case, the declarations would evalu‐ ate like this: /* assume only two faces for this example: 'Regular' and 'Bold' p {font-weight: 100;} /* looks the same as 'normal' text */ p span {font-weight: bolder;} /* maps to '700' */ */ As you can see, the weight 100 is assigned to the normal font face, but the value of font-weight is still 100. Thus, any span text that is descended from a p element will inherit the value of 100 and then evaluate to the next-heaviest face, which is the “Bold” face with a numerical weight of 700. Let’s take this one step further and add two more rules, plus some markup, to illus‐ trate how all of this works (see Figure 5-8 for the results): /* assume only two faces for this example: 'Regular' and 'Bold' p {font-weight: 100;} /* looks the same as 'normal' text */ p span {font-weight: 400;} /* so does this */ strong {font-weight: bolder;} /* even bolder than its parent */ strong b {font-weight: bolder;} /*bolder still */ */

This paragraph contains elements of increasing weight: there is a span element that contains a strongly emphasized element and a bold element.

Figure 5-8. Moving up the weight scale In the last two nested elements, the computed value of font-weight is increased because of the liberal use of the keyword bolder. If you were to replace the text in the paragraph with numbers representing the font-weight of each element, you would get the results shown here:

100 400 700 800 .

The first two weight increases are large because they represent jumps from 100 to 400 and from 400 to bold (700). From 700, there is no heavier face, so the user agent Font Weights | 171 moves the value of font-weight one notch up the numeric scale (800). Furthermore, if you were to insert a strong element into the b element, it would come out like this:

100 400 700 800 900 .

If there were yet another b element inserted into the innermost strong element, its weight would also be 900, since font-weight can never be higher than 900. Assuming that there are only two font faces available, then the text would appear to be either regular or bold, as you can see in Figure 5-9:

regular regular bold bold bold .

Figure 5-9. Visual weight, with descriptors Lightening Weights As you might expect, lighter works in just the same way, except it causes the user agent to move down the weight scale instead of up. With a quick modification of the previous example, you can see this very clearly: /* assume only two faces for this example: 'Regular' and 'Bold' */ p {font-weight: 900;} /* as bold as possible, which will look 'bold' */ p span {font-weight: 700;} /* this will also be bold */ strong {font-weight: lighter;} /* lighter than its parent */ b {font-weight: lighter;} /* lighter still */

900 700 400 300 200 .

bold bold regular regular regular .

Ignoring the fact that this would be entirely counterintuitive, what you see in Figure 5-10 is that the main paragraph text has a weight of 900. When the strong text is set to be lighter, it evaluates to the next-lighter face, which is the regular face, or 400 (the same as normal) on the numeric scale. The next step down is to 300, which is the same as normal since no lighter faces exist. From there, the user agent can reduce the weight only one numeric step at a time until it reaches 100 (which it doesn’t do in 172 | Chapter 5: Fonts the example). The second paragraph shows which text will be bold and which will be regular. Figure 5-10. Making text lighter The font-weight descriptor With the font-weight descriptor, authors can assign faces of varying weights to the weighting levels permitted by the font-weight property. For example, the following rules explicitly assign five faces to six different font-weight values: @font-face { font-family: "SwitzeraADF"; font-weight: normal; src: url("f/SwitzeraADF-Regular.otf") format("opentype"); } @font-face { font-family: "SwitzeraADF"; font-weight: bold; src: url("f/SwitzeraADF-Bold.otf") format("opentype"); } @font-face { font-family: "SwitzeraADF"; font-weight: 300; src: url("f/SwitzeraADF-Light.otf") format("opentype"); } @font-face { font-family: "SwitzeraADF"; font-weight: 500; src: url("f/SwitzeraADF-DemiBold.otf") format("opentype"); } @font-face { font-family: "SwitzeraADF"; font-weight: 700; src: url("f/SwitzeraADF-Bold.otf") format("opentype"); } @font-face { font-family: "SwitzeraADF"; font-weight: 900; src: url("f/SwitzeraADF-ExtraBold.otf") format("opentype"); } With these faces assigned, the author now has a number of weighting levels available for his use, as illustrated in Figure 5-11: h1, h2, h3, h4 {font: 225% SwitzeraADF, Helvetica, sans-serif;} h1 {font-weight: 900;} h2 {font-size: 180%; font-weight: 700;} h3 {font-size: 150%; font-weight: 500;} h4 {font-size: 125%; font-weight: 300;} Font Weights | 173 Figure 5-11. Using declared font-weight faces In any given situation, the user agent picks which face to use depending on the exact value of a font-weight property, using the resolution algorithm detailed in the earlier section, “How Weights Work” on page 167. Authors may use any value for the fontweight descriptor that is permitted for the font-weight property except the inherit keyword. Font Size The methods for determining font size are both very familiar and very different. font-size Values xx-small | x-small | small | medium | large | x-large | xx-large | smaller | larger | | Initial value medium Applies to Percentages Computed value Inherited Animatable All elements Calculated with respect to the parent element’s font size An absolute length Yes Yes (numeric keywords only) In a fashion very similar to the font-weight keywords bolder and lighter, the property font-size has relative-size keywords called larger and smaller. Much like what we saw with relative font weights, these keywords cause the computed value of font-size to move up and down a scale of size values, which you’ll need to under‐ 174 | Chapter 5: Fonts stand before you can explore larger and smaller. First, though, we need to examine how fonts are sized in the first place. In fact, the actual relation of the font-size property to what you see rendered is determined by the font’s designer. This relationship is set as an em square (some call it an em box) within the font itself. This em square (and thus the font size) doesn’t have to refer to any boundaries established by the characters in a font. Instead, it refers to the distance between baselines when the font is set without any extra leading (lineheight in CSS). It is quite possible for fonts to have characters that are taller than the default distance between baselines. For that matter, a font might be defined such that all of its characters are smaller than its em square, as many fonts do. Some hypotheti‐ cal examples are shown in Figure 5-12. Figure 5-12. Font characters and em squares Thus, the effect of font-size is to provide a size for the em box of a given font. This does not guarantee that any of the actual displayed characters will be this size. Absolute Sizes Having established all of that, we turn now to the absolute-size keywords. There are seven absolute-size values for font-size: xx-small, x-small, small, medium, large, x-large, and xx-large. These are not defined precisely, but are relative to each other, as Figure 5-13 demonstrates: p.one {font-size: xx-small;} p.two {font-size: x-small;} p.three {font-size: small;} p.four {font-size: medium;} p.five {font-size: large;} Font Size | 175 p.six {font-size: x-large;} p.seven {font-size: xx-large;} According to the CSS1 specification, the difference (or scaling factor) between one absolute size and the next is about 1.5 going up the ladder, or 0.66 going down. Thus, if medium is the same as 10px, then large should be the same as 15px. This was later determined to be too large a scaling factor. In CSS2 it was suggested that it be some‐ where between 1.0 and 1.2, and in CSS3 drafts a complicated series is provided (for example, small is listed as eight-ninths the size of medium, while xx-small is threefifths). In all case, the scaling factors are guidelines, as user agents are free to alter them for any reason. Figure 5-13. Absolute font sizes Working from the assumption that medium equals 16px, for different scaling factors, we get the absolute size equivalents shown in Table 5-5. (The values shown are rounded-off integers.) Table 5-5. Scaling factors translated to pixels Keyword CSS1 CSS2 CSS3 (draft) xx-small 5px 9px 10px x-small 7px 11px 12px small 11px 13px 14px medium 16px 16px 16px large 24px 19px 19px x-large 36px 23px 24px xx-large 54px 28px 32px 176 | Chapter 5: Fonts Relative Sizes Comparatively speaking, the keywords larger and smaller are simple: they cause the size of an element to be shifted up or down the absolute-size scale, relative to their parent element, using the same scaling factor employed to calculate absolute sizes. In other words, if the browser used a scaling factor of 1.2 for absolute sizes, then it should use the same factor when applying relative-size keywords: p {font-size: medium;} strong, em {font-size: larger;}

This paragraph element contains a strong-emphasis element which itself contains an emphasis element that also contains a strong element.

medium large x-large xx-large

Unlike the relative values for weight, the relative-size values are not necessarily con‐ strained to the limits of the absolute-size range. Thus, a font’s size can be pushed beyond the sizes for xx-small and xx-large. For example: h1 {font-size: xx-large;} em {font-size: larger;}

A Heading with Emphasis added

This paragraph has some emphasis as well.

As you can see in Figure 5-14, the emphasized text in the h1 element is slightly larger than xx-large. The amount of scaling is left up to the user agent, with the scaling factor of 1.2 being preferred but not required. The em text in the paragraph is shifted one slot up the absolute-size scale (large). Figure 5-14. Relative font sizing at the edges of the absolute sizes User agents are not required to increase or decrease font size beyond the limits of the absolute-size keywords. Font Size | 177 Percentages and Sizes In a way, percentage values are very similar to the relative-size keywords. A percent‐ age value is always computed in terms of whatever size is inherited from an element’s parent. Percentages, unlike the size keywords previously discussed, permit much finer control over the computed font size. Consider the following example, illustrated in Figure 5-15: body {font-size: 15px;} p {font-size: 12px;} em {font-size: 120%;} strong {font-size: 135%;} small, .fnote {font-size: 70%;}

This paragraph contains both emphasis and strong emphasis, both of which are larger than their parent element. The small text, on the other hand, is smaller by a quarter.

This is a 'footnote' and is smaller than regular text.

12px 14.4px 12px 16.2px 12px 9px 12px

10.5px

Figure 5-15. Throwing percentages into the mix In this example, the exact pixel size values are shown. These are the values calculated by the browser, regardless of the actual displayed size of the characters onscreen. Incidentally, CSS defines the length value em to be equivalent to percentage values, in the sense that 1em is the same as 100% when sizing fonts. Thus, the following would yield identical results, assuming that both paragraphs have the same parent element: p.one {font-size: 166%;} p.two {font-size: 1.6em;} When using em measurements, the same principles apply as with percentages, such as the inheritance of computed sizes and so forth. 178 | Chapter 5: Fonts Font Size and Inheritance Figure 5-12 also demonstrates that, although font-size is inherited in CSS, it is the computed values that are inherited, not percentages. Thus, the value inherited by the strong element is 12px, and this value is modified by the declared value 135% to arrive at 16.2px. For the “footnote” paragraph, the percentage is calculated in relation to the font-size value that’s inherited from the body element, which is 15px. Multi‐ plying that value by 75% yields 11.25px. As with the relative-size keywords, percentages are effectively cumulative. Thus, the following markup is displayed as shown in Figure 5-16: p {font-size: 12px;} em {font-size: 120%;} strong {font-size: 135%;}

This paragraph contains bothemphasis and strong emphasis, both of which are larger than the paragraph text.

12px 14.4px 19.44px 12px

Figure 5-16. The issues of inheritance The size value for the strong element shown in Figure 5-16 is computed as follows: 12 px × 120% = 14.4 px 14.4 px × 135% = 19.44 px (possibly rounded to 19 px for display; see the next sec‐ tion) The problem of runaway scaling can go the other direction, too. Consider for a moment a document that is nothing but a series of unordered lists, many of them nested inside other lists. Some of these lists are four nested levels deep. Imagine the effect of the following rule on such a document: ul {font-size: 80%;} Assuming a four-level deep nesting, the most deeply nested unordered list would have a computed font-size value 40.96 percent the size of the parent of the top-level list. Every nested list would have a font size 80 percent as big as its parent list, causing each level to become harder and harder to read. Rounding for display In most modern browsers, while fractional font-size values are maintained inter‐ nally, they are not always used by rendering engines. For example, study the letter‐ forms in Figure 5-17. Font Size | 179 In all cases, the O characters increase by 0.1 pixels in size as you go from left to right. Thus, the leftmost O has a font-size of 10px, the one at the midpoint has a size of 10.5px, and the one on the right is 11px. As Figure 5-17 reveals, different browser/OS combinations yield different results. For example, Opera, Safari, and Chrome for macOS show an abrupt jump from 10 pixels to 11 pixels at the 10.5px position. Internet Explorer and Firefox for Windows (both 7 and 8) do the same. Firefox for macOS, on the other hand, looks like it has a smooth line of same-size text. In fact, the characters are all being drawn subtly differ‐ ently, thanks to their subtly different font-size values. It’s hard to see without squint‐ ing (or a ruler), but the fact that it’s hard to tell there is an increase in size from one end of the line to the other is evidence enough. Figure 5-17. Fractional font sizes Nevertheless, every browser will yield up the same subpixel font-size values if you use an inspector or query the value directly via DOM scripting. The third O from the right will show a computed value of 10.8px, regardless of the size of the character dis‐ played onscreen. Keywords and monospace text There’s an interesting wrinkle to font size keywords and inheritance that becomes apparent when you look at what some browsers do with monospace text (e.g., Cou‐ rier). Consider the following, illustrated in Figure 5-18: p {font-size: medium;} /* the default value */ span {font-family: monospace; font-size: 1em;}

This is a 'p' with a 'span' inside.

Figure 5-18. Monospace size oddities 180 | Chapter 5: Fonts The default value of medium is generally resolved to 16px, assuming the user hasn’t changed the browser preferences (where the default text sizes are set). Indeed, if you query the paragraph text outside the span, inspectors will tell you that the computed font-size of the text is 16px (again, assuming the user hasn’t changed the preferen‐ ces). So you might expect the monospaced span to also have 16-pixel text. That’s exactly the case in some browsers; but in others, it will be 13px. The reason for this is that while the computed font-size of the paragraph is 16px, the keyword medium is what’s passed down through inheritance. Thus, the span starts out with font-size: medium. As a result, it looks to the user’s preference settings to determine the proper size, and most browsers are set to a 13px default size for all monospace text. This causes them to display 13-pixel monospace text in a 16-pixel parent, even though the monospace text was explicitly set to font-size: 1em. The effect carries through even with font sizes other than 1em (or 100%); in the follow‐ ing case, the monospace text will have a computed size of 26px instead of 32px (once more assuming the browser defaults have not changed): p {font-size: medium;} /* the default value */ span {font-family: monospace; font-size: 2em;}

This is a 'p' with a 'span' inside.

Note that not all browsers actually do this: some override the medium sizing assump‐ tions in favor of scaling off the computed font-size of the parent. This leads to inconsistent text display across browsers. As it happens, there is a way to work around this problem that works for all known browsers, at least as of late 2017. It goes like this: p {font-size: medium;} /* the default value */ span {font-family: monospace, serif; font-size: 1em;}

This is a 'p' with a 'span' inside.

See the extra serif in the font-family there? That somehow triggers a switch that makes all browsers treat font-size: 1em as being 100 percent of the paragraph’s computed font-size, not a medium-derived value. This is cross-browser-consistent and illustrated in Figure 5-19. Figure 5-19. Monospace size harmony Font Size | 181 Using Length Units The font-size can be set using any length value. All of the following font-size dec‐ larations should be equivalent: p.one {font-size: 36pt;} p.two {font-size: 3pc;} p.three {font-size: 0.5in;} p.four {font-size: 1.27cm;} p.five {font-size: 12.7mm;} The display in Figure 5-20 assumes that the user agent knows how many dots per inch are used in the display medium. Different user agents make different assump‐ tions—some based on the operating system, some based on preferences settings, and some based on the assumptions of the programmer who wrote the user agent. Never‐ theless, the five lines should always have the same font size. Thus, while the result may not exactly match reality (for example, the actual size of p.three may not be half an inch), the measurements should all be consistent with one another. Figure 5-20. Various font sizes There is one more value that is potentially the same as those shown in Figure 5-20, and that’s 36px, which would be the same physical distance if the display medium is 72 pixels per inch (ppi). However, there are very few monitors with that setting any‐ more. Most desktop displays are much higher, in the range of 96 ppi to 120 ppi; and mobile devices go much higher, currently in the 300 ppi to 500 ppi range. Despite these variations between operating systems and devices, many authors choose to use pixel values for font sizes. This approach seems especially attractive when mixing text and raster images (GIF, JPG, PNG, etc.) on a web page, since text can (in theory) be set to the same height as graphic elements on the page by declaring font-size: 11px; or something similar, as illustrated by Figure 5-21. 182 | Chapter 5: Fonts Figure 5-21. Keeping text and graphics in scale with pixel sizes Using pixel measurements for font-size is certainly one way to get “consistent” results with font-size (and, indeed, with any length at all), but there is a drawback. Not every browser makes it easy (or even possible) to resize text set in pixels, and there are situations where pixel-sized text can be badly sized in mobile devices that pretend to be full-screen devices (such as most versions of the iPhone). For these rea‐ sons alone, pixel-sizing text is generally not recommended. Automatically Adjusting Size Two of the main factors that influence a font’s legibility are its size and its x-height. The number that results from dividing the x-height by the font-size is referred to as the aspect value. Fonts with higher aspect values tend to be legible as the font’s size is reduced; conversely, fonts with low aspect values become illegible more quickly. CSS provides a way to deal with shifts in aspect values between font families with the property font-size-adjust. font-size-adjust Values | none | auto Initial value none Applies to All elements Inherited Yes Animatable Yes The goal of this property is to preserve legibility when the font used is not the author’s first choice. Because of the differences in font appearance, while one font may be legible at a certain size, another font at the same size is difficult or impossible to read. A good example is to compare the common fonts Verdana and Times. Consider Figure 5-22 and the following markup, which shows both fonts at a font-size of 10px: p {font-size: 10px;} p.cl1 {font-family: Verdana, sans-serif;} p.cl2 {font-family: Times, serif; } Font Size | 183 Figure 5-22. Comparing Verdana and Times The text in Times is much harder to read than the Verdana text. This is partly due to the limitations of pixel-based display, but it is also because Times becomes harder to read at smaller font sizes. As it turns out, the ratio of x-height to character size in Verdana is 0.58, whereas in Times it is 0.46. What you can do in this case is declare the aspect value of Verdana, and the user agent will adjust the size of the text that’s actually used. This is accom‐ plished using the formula: Declared font-size × (font-size-adjust value ÷ aspect value of available font) = Adjusted font-size So, in a situation where Times is used instead of Verdana, the adjustment is as fol‐ lows: 10px × (0.58 ÷ 0.46) = 12.6px which leads to the result shown in Figure 5-23: p {font: 10px Verdana, sans-serif; font-size-adjust: 0.58;} p.cl2 {font-family: Times, serif; } Figure 5-23. Adjusting Times The catch is that to allow a user agent to intelligently make size adjustments, it first has to know the aspect value of the fonts you specify. User agents that support @fontface will be able to pull that information directly from the font file, assuming the files contain the information—any professionally-produced font should, but there’s no guarantee. If a font file doesn’t contain the aspect value, a user agent may try to com‐ pute it; but again, there’s no guarantee that they will or even can. Assuming that the user agent can find or figure out aspect values, the auto value for font-size-adjust is a way of getting the desired effect even if you don’t know the 184 | Chapter 5: Fonts actual aspect value of your first-choice font. For example, given that the user agent can determine that the aspect value of Verdana is 0.58, then the following will have the same result as that shown in Figure 5-23: p {font: 10px Verdana, sans-serif; font-size-adjust: auto;} p.cl2 {font-family: Times, serif; } Declaring font-size-adjust: none; will suppress any adjustment of font sizes. This is the default state. As of late 2017, the only user agent line to support font-sizeadjust was the Gecko (Firefox) family. Font Style font-style is very simple: it’s used to select between normal text, italic text, and oblique text. That’s it! The only complication is in recognizing the difference between italic and oblique text and in understanding why browsers don’t always give you a choice. font-style Values italic | oblique | normal Initial value normal Applies to All elements Computed value As specified Note Has a corresponding @font-face descriptor Inherited Yes Animatable No The default value of font-style is, as you can see, normal. This refers to upright text, which is probably best described as text that is not italic or otherwise slanted. The vast majority of text in this book is upright, for instance. That leaves only an explana‐ tion of the difference between italic and oblique text. For that, it’s easiest to refer to Figure 5-24, which illustrates the differences very clearly. Basically, italic text is a separate font face, with small changes made to the structure of each letter to account for the altered appearance. This is especially true of serif fonts, Font Style | 185 where, in addition to the fact that the text characters “lean,” the serifs may be altered in an italic face. Oblique text, on the other hand, is just a slanted version of the nor‐ mal, upright text. Font faces with labels like “Italic,” “Cursive,” and “Kursiv” are usu‐ ally mapped to the italic keyword, while oblique is often assigned faces with labels such as “Oblique,” “Slanted,” and “Incline.” Figure 5-24. Italic and oblique text in detail If you want to make sure that a document uses italic text in familiar ways, you could write a stylesheet like this: p {font-style: normal;} em, i {font-style: italic;} These styles would make paragraphs use an upright font, as usual, and cause the em and i elements to use an italic font—again, as usual. On the other hand, you might decide that there should be a subtle difference between em and i: p {font-style: normal;} em {font-style: oblique;} i {font-style: italic;} If you look closely at Figure 5-25, you’ll see there is no apparent difference between the em and i elements. In practice, not every font is so sophisticated as to have both an italic face and an oblique face, and even fewer web browsers are sophisticated enough to tell the difference when both faces do exist. Figure 5-25. More font styles If either of these is the case, then there are a few things that can happen. If there is no Italic face available, but there is an Oblique face, then the latter can be used for the former. If the situation is reversed—an Italic face exists, but there is no defined Obli‐ que face—the user agent may not substitute the former for the latter, according to the specification. Finally, the user agent can simply generate the oblique face by comput‐ ing a slanted version of the upright font. In fact, this is what most often happens in a digital world, where it’s fairly simple to slant a font using a simple computation. 186 | Chapter 5: Fonts Furthermore, you may find that in some operating systems, a given font that has been declared as italic may switch from italic to oblique depending on the actual size of the font. The display of Times on a Macintosh running the Classic OS (Mac OS 9), for example, is shown in Figure 5-26, where the only difference is a single pixel in font size. Figure 5-26. Same font, same style, different sizes There isn’t much that can be done about this, unfortunately, except better font han‐ dling. Fortunately, modern operating systems such as macOS and Windows XP have very good font rendering technology, and @font-face allows authors to assign spe‐ cific italic and oblique faces to the respective font-style properties, should they so choose. Even though italic and oblique text often use the same face, font-style can still be quite useful. For example, it is a common typographic convention that a block quote should be italicized, but that any specially emphasized text within the quote should be upright. To employ this effect, which is illustrated in Figure 5-27, you would use these styles: blockquote {font-style: italic;} blockquote em, blockquote i {font-style: normal;} Figure 5-27. Common typographical conventions through CSS A related property tells the user agent whether it’s allowed to synthesize its own bold or italic faces when a family doesn’t contain them. The font-style Descriptor As a descriptor, font-style lets an author link specific faces to specific font-style val‐ ues. @font-face { font-family: "SwitzeraADF"; Font Style | 187 font-style: normal; src: url("SwitzeraADF-Regular.otf") format("opentype"); } @font-face { font-family: "SwitzeraADF"; font-style: italic; src: url("SwitzeraADF-Italic.otf") format("opentype"); } @font-face { font-family: "SwitzeraADF"; font-style: oblique; src: url("SwitzeraADF-Italic.otf") format("opentype"); } Given the above, the result of the following rules would be to render h2 and h3 ele‐ ments using “SwitzeraADF-Italic” instead of “SwitzeraADF-Regular,” as illustrated in Figure 5-28: h1, h2, h3 {font: 225% SwitzeraADF, Helvetica, sans-serif;} h2 {font-size: 180%; font-style: italic;} h3 {font-size: 150%; font-style: oblique;} Figure 5-28. Using declared font-style faces Ideally, if there were a SwitzeraADF face with an oblique typeface, the author could point to it instead of the italic variant. There isn’t such a face, though, so the author mapped the italic face to both the italic and oblique values. As with font-weight, the font-style descriptor can take all of the values of the font-style property except for inherit. Font Stretching In some font families, there are a number of variant faces that have wider or narrower letterforms. These often take names like “Condensed,” “Wide,” “Ultra Expanded,” and so on. The utility of such variants is that a designer can use a single font family while also having skinny and fat variants. CSS provides a property that allows an author to select among such variants, when they exist, without having to explicitly define them 188 | Chapter 5: Fonts in font-family declarations. It does this via the somewhat misleadingly named fontstretch. font-stretch Values normal | ultra-condensed | extra-condensed | condensed | semicondensed | semi-expanded | expanded | extra-expanded | ultraexpanded Initial value normal Applies to All elements Inherited Yes Animatable No Note Has a corresponding @font-face descriptor (see below) You might expect from the property name that this will stretch or squeeze a font like saltwater taffy, but that’s actually not the case at all. As the value names imply, this property instead behaves very much like the absolute-size keywords (e.g., xx-large) for the font-size property, with a range of absolute values that (in theory) let the author alter a font’s width. For example, an author might decide to stress the text in a strongly emphasized element by changing the font characters to a wider face than their parent element’s font characters. The catch is that this property only works if the font family in use has defined wider and narrower faces, which most do not (and those that do are usually very expen‐ sive). Thus this property is actually very different from font-size, which can change the size of any font face at any time. In contrast, declaring font-stretch: expanded will only have an effect if the font in use has an expanded face available. If it doesn’t, then nothing will happen: the font’s face will not change. For example, consider the very common font Verdana, which has only one width face; this is equivalent to font-stretch: normal. Declaring the following will have no effect on the width of the displayed text: body {font-family: Verdana;} strong {font-stretch: extra-expanded;} footer {font-stretch: extra-condensed;} All of the text will be at Verdana’s usual width. However, if the font family is changed to one that has a number of width faces, such as Futura, then things will be different, as shown in Figure 5-29: Font Stretching | 189 body {font-family: Verdana;} strong {font-stretch: extra-expanded;} footer {font-stretch: extra-condensed;} Figure 5-29. Stretching font characters As of late 2017, Safari for both macOS and iOS did not support font-stretch, nor did Opera Mini. The font-stretch Descriptor Much as with the font-weight descriptor, the font-stretch descriptor allows authors to explicitly assign faces of varying widths to the width values permitted in the fontstretch property. For example, the following rules explicitly assign three faces to the most directly analogous font-stretch values: @font-face { font-family: "SwitzeraADF"; font-stretch: normal; src: url("SwitzeraADF-Regular.otf") format("opentype"); } @font-face { font-family: "SwitzeraADF"; font-stretch: condensed; src: url("SwitzeraADF-Cond.otf") format("opentype"); } @font-face { font-family: "SwitzeraADF"; font-stretch: expanded; src: url("SwitzeraADF-Ext.otf") format("opentype"); } In a parallel to what we saw in previous sections, the author can call on these different width faces through the font-stretch property, as illustrated in Figure 5-30: h1, h2, h3 {font: 225% SwitzeraADF, Helvetica, sans-serif;} h2 {font-size: 180%; font-stretch: condensed;} h3 {font-size: 150%; font-stretch: expanded;} As before, the font-stretch descriptor can take all of the values of the font-stretch property except for inherit. 190 | Chapter 5: Fonts Figure 5-30. Using declared font-stretch faces Font Kerning Some fonts contain data regarding how characters should be spaced relative to each other, known as kerning. This spacing can vary depending on how characters are combined; for example, the character pair oc may have a different spacing than the pair ox. Similarly, AB and AW may have different separation distances, to the point that in some fonts, the top-right tip of the W is actually placed to the left of the bottom-right tip of the A. This kerning data can be explicitly called for or suppressed using the property font-kerning. font-kerning Values auto | normal | none Initial value auto Applies to All elements Inherited Yes Animatable No The value none is pretty simple: it tells the user agent to ignore any kerning informa‐ tion in the font. normal tells the user agent to kern the text normally; that is, accord‐ ing to the kerning data contained in the font. auto tells the user agent to do whatever it thinks best, possibly depending on the type of font in use. The OpenType specifica‐ tion, for example, recommends (but does not require) that kerning be applied when‐ ever the font supports it. If a font does not contain kerning data, font-kerning will have no effect. Font Kerning | 191 Note that if the property letter-spacing is applied to kerned text, the kerning is done and then the letters’ spacing is adjusted accord‐ ing to the value of letter-spacing, not the other way around. Font Variants Beyond font weights, font styles, and so forth, there are font variants. These are embedded within a font face and can cover things like various styles of historical liga‐ tures, small-caps presentation, ways of presenting fractions, the spacing of numbers, whether zeroes get slashes through them, and much more. CSS lets authors invoke these variants, when they exist, through font-variant. font-variant Values (CSS2.1) normal | small-caps Values (Level 3) normal | none | [ ‖ ‖ ‖ ‖ stylistic() ‖ historical-forms ‖ styleset(#) ‖ charactervariant(#) ‖ swash() ‖ orna ments() ‖ annotation() ‖ [ smallcaps | all-small-caps | petite-caps | all-petite-caps | unicase | titling-caps ] ‖ ‖ ‖ ‖ ordinal ‖ slashed-zero ‖ ‖ ‖ ruby ] Initial value normal Applies to Computed value Inherited Animatable Note All elements As specified Yes No Has a corresponding @font-face descriptor (see below) That’s quite a Values (Level 3) entry, isn’t it? Especially when the only values in CSS1 and CSS2 were the default of normal, which describes ordinary text, and small-caps, which calls for the use of small-caps text. Let’s concentrate just on those for a moment. 192 | Chapter 5: Fonts Instead of upper- and lowercase letters, a small-caps font employs uppercase letters of different sizes. Thus, you might see something like that shown in Figure 5-31: h1 {font-variant: small-caps;} h1 code, p {font-variant: normal;}

The Uses of font-variant On the Web

The property font-variant is very interesting...

Figure 5-31. The small-caps value in use As you may notice, in the display of the h1 element, there is a larger uppercase letter wherever an uppercase letter appears in the source and a small uppercase letter wher‐ ever there is a lowercase letter in the source. This is very similar to text-transform: uppercase, with the only real difference being that, here, the uppercase letters are of different sizes. However, the reason that small-caps is declared using a font property is that some fonts have a specific small-caps face, which a font property is used to select. What happens if no such face exists? There are two options provided in the specifica‐ tion. The first is for the user agent to create a small-caps face by scaling uppercase letters on its own. The second is to make all letters uppercase and the same size, exactly as if the declaration text-transform: uppercase; had been used instead. This is not an ideal solution, but it is permitted. Level 3 Values Now to examine that Values (Level 3) line. It is admittedly complicated, but there’s an easy way to explain it. It’s actually a shorthand for all the values permitted for the fol‐ lowing properties: • font-variant-ligatures • font-variant-caps • font-variant-numeric • font-variant-alternates • font-variant-east-asian Font Variants | 193 As an example (to pick one of the simpler ones), comes from the property font-variant-ligatures, and can be either common-ligatures or nocommon-ligatures. comes from font-variant-numeric and can be either diagonal-fractions or stacked-fractions. And so on. There are two barriers to the use of these admittedly much more powerful font var‐ iants: browser support and font support. The first is easy: as of late 2017, there isn’t widespread support for enabling font variants. Certainly you can use the CSS 2.1 var‐ iant values, but many of the Level 3 values are only supported by Gecko and WebKit. The second is also easy while also being complex: not every font supports every var‐ iant. For example, most Latin fonts won’t support any of the East Asian variants; for another, not every font will include support for, say, some of the numeric and ligature variants. To find out what a given font supports, you have to consult its documenta‐ tion, or do a lot of testing if no documentation is available. (Most commercial fonts do come with documentation, and most free fonts don’t.) The main thing to keep in mind is that even if a variant works in a given browser for one font, it may not for another; and just because a font has a given variant, that doesn’t mean that all browsers will let you invoke it. So it’s complicated, and there aren’t many detailed guides to help out. The various font-variant-* properties are not covered in detail here because as of late 2017, they were not well supported in browsers. For more details, see http://w3.org/TR/css3-fonts/. The font-variant descriptor The font-variant descriptor lets you decide which of a font face’s variants can or cannot be used, specified as a space-separated list. For example, you can enable the common ligature, small caps, and slashed-zeroes variants like so: font-variant: common-ligatures small-caps slashed-zero; You’ll no doubt have guessed by now that the font-variant descriptor can take all of the values of the font-variant property except for inherit. Note that this descriptor is very different than the other descriptors we’ve seen so far. With the font-stretch descriptor, for example, you can assign a specific font face to a given font-stretch property value. The font-variant descriptor, by contrast, defines which variants are permitted for the font face being declared in the @fontface rule, which can easily negate font variant values called for in properties later on. For example, given the following, paragraphs will not be displayed using a diagonalfractions or small-caps variant, even if such variants exist in SwitzeraADF: 194 | Chapter 5: Fonts @font-face { font-family: "SwitzeraADF"; font-weight: normal; src: url("SwitzeraADF-Regular.otf") format("opentype"); font-variant: stacked-fractions titling-caps slashed-zero; } p {font: small-caps 1em SwitzeraADF, sans-serif; font-variant-numeric: diagonal-fractions;} Font Features In a manner similar to font-variant, the font-feature-settings descriptor allows authors to exercise low-level control over which OpenType font features are available for use (so don’t go using this descriptor on .woff files). font-feature-settings Values normal | # Initial value normal Note Has a corresponding @font-face descriptor (see below) You can list one or more comma-separated OpenType features, as defined by the OpenType specification. For example, enabling common ligatures, small caps, and slashed zeroes would look something like this: font-feature-settings: "liga" on, "smcp" on, "zero" on; The exact format of a value is: [ | on | off ]? For many features, the only permitted integer values are 0 and 1, which are equivalent to off and on (and vice versa). There are some features that allow a range of numbers, however, in which case values greater than 1 both enable the feature and define the feature’s selection index. If a feature is listed but no number is provided, 1 (on) is assumed. Thus, the following descriptors are all equivalent: font-feature-settings: "liga"; /* 1 is assumed */ font-feature-settings: "liga" 1; /* 1 is declared */ font-feature-settings: "liga" on; /* on = 1 */ Remember that all values must be quoted. Thus, the first of the following descriptors will be recognized, but the second will be ignored: Font Features | 195 font-feature-settings: "liga", dlig; /* common ligatures are enabled; we wanted discretionary ligatures, but forgot quotes */ A further restriction is that OpenType requires that all feature tags be four ASCII characters long. Any feature name longer or shorter, or that uses non-ASCII charac‐ ters, is invalid and will be ignored. (This isn’t something you personally need to worry about unless you’re using a font that has it own made-up feature names and the font’s creator didn’t follow the naming rules.) By default, OpenType fonts always have the following features enabled unless the author explicitly disables them via font-feature-settings or font-variant: calt Contextual alternates ccmp Composed characters clig Contextual ligatures liga Standard ligatures locl Localized forms mark Mark to base positioning mkmk Mark to mark positioning rlig Required ligatures Additionally, other features may be enabled by default in specific situations, such as vertical alternatives (vert) for vertical runs of text. A complete list of standard OpenType feature names can be found at microsoft.com/typography/otspec/featurelist.htm. 196 | Chapter 5: Fonts The font-feature-settings Descriptor The font-feature-settings descriptor lets you decide which of an OpenType font face’s settings can or cannot be used, specified as a space-separated list. Now, hold up a second—isn’t that almost exactly what we did with font-variant just a few paragraphs ago? As a matter of fact, yes, it is. The font-variant descriptor cov‐ ers nearly everything font-feature-settings does, plus a little more besides. It just does so in a more CSS-like way, with value names instead of cryptic OpenType identi‐ fiers and Boolean toggles. Because of this, the CSS specification explicitly encourages authors to use font-variant instead of font-feature-settings, except in those cases where there’s a font feature that the value list of font-variant doesn’t include. Keep in mind that this descriptor merely makes features available for use (or sup‐ presses their use). It does not actually turn them on for the display of text; for that, see the section on the font-feature-settings property. Just as with the font-variant descriptor, the font-feature-settings descriptor defines which font features are permitted for the font face being declared in the @font-face rule. This can easily negate font feature values called for in properties later on. For example, given the following, paragraphs will not be displayed using alternative fractions nor small-caps, even if such features exist in SwitzeraADF: @font-face { font-family: "SwitzeraADF"; font-weight: normal; src: url("SwitzeraADF-Regular.otf") format("opentype"); font-feature-settings: "afrc" off, "smcp" off; } p {font: 1em SwitzeraADF, sans-serif; font-feature-settings: "afrc", "smcp";} As always, the font-feature-settings descriptor can take all of the values of the font-feature-settings property except for inherit. Font Synthesis It is sometimes the case that a given font family will lack alternate faces for things like bold or italic text. In such situations, the user agent may attempt to synthesize a face from the faces it has available, but this can lead to unattractive letterforms. To address this, CSS offers font-synthesis, which lets authors say how much synthesis they will or won’t permit in the rendering of a page. Font Synthesis | 197 font-synthesis Values none | weight ‖ style Initial value weight style Applies to All elements Inherited Yes Animatable No In many user agents, a font family that has no bold face can have one computed for it. This might be done by adding pixels to either side of each character glyph, for exam‐ ple. While this might seem useful, it can lead to results that are visually unappealing. This is why most font families actually have bold faces included: the font’s designer wanted to make sure that bolded text in that font looked good. Similarly, a font family that lacks an italic face an have one synthesized by simply slanting the characters in the normal face. This tends to look even worse than synthe‐ sized bold faces, particularly when it comes to serif fonts. Compare the difference between a synthesized italic version of Georgia (which we’re calling “oblique” here) and the actual italic face included in Georgia, illustrated in Figure 5-32. In supporting user agents, declaring font-synthesis: none blocks the user agent from doing any such synthesis for the affected elements. You can block it for the whole document with html (font-synthesis: none;}, for example. The downside is that any attempts to bold or italicize text using a font that doesn’t offer the appro‐ priate faces will stay unbolded or unitalicized. The upside is that you don’t have to worry about a user agent trying to synthesize those variants and doing a poor job of it. As of late 2017, only Firefox supported font-synthesis. 198 | Chapter 5: Fonts Figure 5-32. Synthesized versus designed italics The font Property All of these properties are very sophisticated, but using them all could get a little tedious: h1 {font-family: font-weight: h2 {font-family: font-weight: Verdana, Helvetica, Arial, sans-serif; font-size: 30px; 900; font-style: italic; font-variant: small-caps;} Verdana, Helvetica, Arial, sans-serif; font-size: 24px; bold; font-style: italic; font-variant: normal;} Some of this problem could be solved by grouping selectors, but wouldn’t it be easier to combine everything into a single property? Enter font, which is the shorthand property for all the other font properties (and a little more besides). font Values Initial value Applies to Percentages [[ ‖ [ normal | small-caps ] ‖ ]? [ / ]? ] | caption | icon | menu | message-box | small-caption | status-bar Refer to individual properties All elements Calculated with respect to the parent element for and with respect to the element’s for Computed value See individual properties (font-style, etc.) Inherited Yes Animatable Refer to individual properties Generally speaking, a font declaration can have any one value from each of the listed font properties, or else a system font value (described in “Using System Fonts” on page 202). Therefore, the preceding example could be shortened as follows (and have exactly the same effect, as illustrated by Figure 5-33): h1 {font: italic 900 small-caps 30px Verdana, Helvetica, Arial, sans-serif;} h2 {font: bold normal italic 24px Verdana, Helvetica, Arial, sans-serif;} The font Property | 199 Figure 5-33. Typical font rules I say that the styles “could be” shortened in this way because there are a few other possibilities, thanks to the relatively loose way in which font can be written. If you look closely at the preceding example, you’ll see that the first three values don’t occur in the same order. In the h1 rule, the first three values are the values for font-style, font-weight, and font-variant, in that order. In the second, they’re ordered fontweight, font-variant, and font-style. There is nothing wrong here because these three can be written in any order. Furthermore, if any of them has a value of normal, that can be left out altogether. Therefore, the following rules are equivalent to the pre‐ vious example: h1 {font: italic 900 small-caps 30px Verdana, Helvetica, Arial, sans-serif;} h2 {font: bold italic 24px Verdana, Helvetica, Arial, sans-serif;} In this example, the value of normal was left out of the h2 rule, but the effect is exactly the same as in the preceding example. It’s important to realize, however, that this free-for-all situation applies only to the first three values of font. The last two are much stricter in their behavior. Not only must font-size and font-family appear in that order as the last two values in the declaration, but both must always be present in a font declaration. Period, end of story. If either is left out, then the entire rule will be invalidated and very likely to be ignored completely by a user agent. Thus, the following rules will get you the result shown in Figure 5-34: h1 h2 h3 h4 200 | {font: {font: {font: {font: normal normal italic 30px sans-serif;} /*no problem here */ 1.5em sans-serif;} /* also fine; omitted values set to 'normal' */ sans-serif;} /* INVALID--no 'font-size' provided */ lighter 14px;} /* INVALID--no 'font-family' provided */ Chapter 5: Fonts Figure 5-34. The necessity of both size and family Adding the Line Height So far, we’ve treated font as though it has only five values, which isn’t quite true. It is also possible to set the value of the property line-height using font, despite that fact that line-height is a text property (not covered in this text), not a font property. It’s done as a sort of addition to the font-size value, separated from it by a forward slash (/): body {font-size: 12px;} h2 {font: bold italic 200%/1.2 Verdana, Helvetica, Arial, sans-serif;} These rules, demonstrated in Figure 5-35, set all h2 elements to be bold and italic (using face for one of the sans-serif font families), set the font-size to 24px (twice the body’s size), and set the line-height to 28.8px. Figure 5-35. Adding line height to the mix This addition of a value for line-height is entirely optional, just as the first three font values are. If you do include a line-height, remember that the font-size always comes before line-height, never after, and the two are always separated by a slash. This may seem repetitive, but it’s one of the most common errors made by CSS authors, so I can’t say it enough: the required values for font are font-size and font-family, in that order. Everything else is strictly optional. The font Property | 201 Using Shorthands Properly It is important to remember that font, being a shorthand property, can act in unex‐ pected ways if you are careless with its use. Consider the following rules, which are illustrated in Figure 5-36: h1, h2, h3 {font: italic small-caps 250% sans-serif;} h2 {font: 200% sans-serif;} h3 {font-size: 150%;}

This is an h1 element

This is an h2 element

This is an h3 element

Figure 5-36. Shorthand changes Did you notice that the h2 element is neither italicized nor small-capped, and that none of the elements are bold? This is the correct behavior. When the shorthand property font is used, any omitted values are reset to their defaults. Thus, the previ‐ ous example could be written as follows and still be exactly equivalent: h1, h2, h3 {font: italic normal small-caps 250% sans-serif;} h2 {font: normal normal normal 200% sans-serif;} h3 {font-size: 150%;} This sets the h2 element’s font style and variant to normal, and the font-weight of all three elements to normal. This is the expected behavior of shorthand properties. The h3 does not suffer the same fate as the h2 because you used the property font-size, which is not a shorthand property and therefore affects only its own value. Using System Fonts In situations where you want to make a web page blend in with the user’s operating system, the system font values of font come in handy. These are used to take the font size, family, weight, style, and variant of elements of the operating system, and apply them to an element. The values are as follows: caption Used for captioned controls, such as buttons 202 | Chapter 5: Fonts icon Used to label icons menu Used in menus—that is, drop-down menus and menu lists message-box Used in dialog boxes small-caption Used for labeling small controls status-bar Used in window status bars For example, you might want to set the font of a button to be the same as that of the buttons found in the operating system. For example: button {font: caption;} With these values, it is possible to create web-based applications that look very much like applications native to the user’s operating system. Note that system fonts may only be set as a whole; that is, the font family, size, weight, style, etc., are all set together. Therefore, the button text from our previous example will look exactly the same as button text in the operating system, whether or not the size matches any of the content around the button. You can, however, alter the indi‐ vidual values once the system font has been set. Thus, the following rule will make sure the button’s font is the same size as its parent element’s font: button {font: caption; font-size: 1em;} If you call for a system font and no such font exists on the user’s machine, the user agent may try to find an approximation, such as reducing the size of the caption font to arrive at the small-caption font. If no such approximation is possible, then the user agent should use a default font of its own. If it can find a system font but can’t read all of its values, then it should use the default value. For example, a user agent may be able to find a status-bar font but not get any information about whether the font is small-caps. In that case, the user agent will use the value normal for the smallcaps property. Font Matching As we’ve seen, CSS allows for the matching of font families, weights, and variants. This is all accomplished through font matching, which is a vaguely complicated pro‐ cedure. Understanding it is important for authors who want to help user agents make good font selections when displaying their documents. I left it for the end of the Font Matching | 203 chapter because it’s not really necessary to understand how the font properties work, and some readers will probably want to skip this part. If you’re still interested, here’s how font matching works: 1. The user agent creates, or otherwise accesses, a database of font properties. This database lists the various CSS properties of all of the fonts to which the user agent has access. Typically, this will be all fonts installed on the machine, although there could be others (for example, the user agent could have its own built-in fonts). If the user agent encounters two identical fonts, it will just ignore one of them. 2. The user agent takes apart an element to which font properties have been applied and constructs a list of font properties necessary for the display of that element. Based on that list, the user agent makes an initial choice of a font family to use in displaying the element. If there is a complete match, then the user agent can use that font. Otherwise, it needs to do a little more work. 3. A font is first matched against the font-stretch property. 4. A font is next matched against the font-style property. The keyword italic is matched by any font that is labeled as either “italic” or “oblique.” If neither is available, then the match fails. 5. The next match is to font-weight, which can never fail thanks to the way fontweight is handled in CSS (explained in the earlier section, “How Weights Work” on page 167). 6. Then, font-size is tackled. This must be matched within a certain tolerance, but that tolerance is defined by the user agent. Thus, one user agent might allow matching within a 20 percent margin of error, whereas another might allow only 10 percent differences between the size specified and the size that is actually used. 7. If there was no font match in Step 2, the user agent looks for alternate fonts within the same font family. If it finds any, then it repeats Step 2 for that font. 8. Assuming a generic match has been found, but it doesn’t contain everything needed to display a given element—the font is missing the copyright symbol, for instance—then the user agent goes back to Step 3, which entails a search for another alternate font and another trip through Step 2. 9. Finally, if no match has been made and all alternate fonts have been tried, then the user agent selects the default font for the given generic font family and does the best it can to display the element correctly. 204 | Chapter 5: Fonts Furthermore, the user agent does the following to resolve handling of font variants and features: 1. First, check for font features enabled by default, including features required for a given script. The core set of default-enabled features is "calt", "ccmp", "clig", "liga", "locl", "mark", "mkmk", and "rlig". 2. Then, if the font is defined via an @font-face rule, check for the features implied by the font-variant descriptor in the @font-face rule. Then check for the font features implied by the font-feature-settings descriptor in the @font-face rule. 3. Then check feature settings determined by properties other than font-variant or font-feature-settings. (For example, setting a non-default value for the letter-spacing property will disable ligatures.) 4. Then check for features implied by the value of the font-variant property, the related font-variant subproperties (e.g., font-variant-ligatures), and any other property that may call for the use of OpenType features (e.g., fontkerning). 5. Finally, check for the features implied by the value of font-feature-settings property. The whole process is long and tedious, but it helps to understand how user agents pick the fonts they do. For example, you might specify the use of Times or any other serif font in a document: body {font-family: Times, serif;} For each element, the user agent should examine the characters in that element and determine whether Times can provide characters to match. In most cases, it can do so with no problem. Assume, however, that a Chinese character has been placed in the middle of a paragraph. Times has nothing that can match this character, so the user agent has to work around the character or look for another font that can fulfill the needs of displaying that element. Any Western font is highly unlikely to contain Chi‐ nese characters, but should one exist (let’s call it AsiaTimes), the user agent could use it in the display of that one element—or simply for the single character. Thus, the whole paragraph might be displayed using AsiaTimes, or everything in the paragraph might be in Times except for the single Chinese character, which is displayed in AsiaTimes. Summary From what was initially a very simplistic set of font properties, CSS has rapidly grown to allow fine-grained and wide-ranging influence over how fonts are displayed on the Summary | 205 web. From custom fonts downloaded over the web to custom-built families assem‐ bled out of a variety of individual faces, authors may be fairly said to overflow with font power. The typographic options available to authors today are far stronger than ever, but always remember: you must use this power wisely. While you can have 17 different fonts in use on your site, that definitely doesn’t mean that you should. Quite aside from the aesthetic difficulties this could present for your users, it would also make the total page weight much, much higher than it needs to be. As with any other aspect of web design, authors are advised to use their power wisely, not wildly. 206 | Chapter 5: Fonts CHAPTER 6 Text Properties Sure, a lot of web design involves picking the right colors and getting the coolest look for your pages, but when it comes right down to it, you probably spend more of your time worrying about where text will go and how it will look. Such concerns gave rise to HTML tags such as and in the web’s early days, which allowed you some measure of control over the appearance and placement of text. Because text is so important, there are many CSS properties that affect it in one way or another. What is the difference between text and fonts? At the simplest level, text is the content, and fonts are used to display that content. Using text properties, you can affect the position of text in relation to the rest of the line, superscript it, underline it, and change the capitalization. You can even simulate, to a limited degree, the use of a typewriter’s Tab key. Indentation and Inline Alignment Let’s start with a discussion of how you can affect the inline positioning of text within a line. Think of these basic actions as the same types of steps you might take to create a newsletter or write a report. First, however, let’s take a moment to talk about the terms inline and block as they’ll be used in this chapter. In fact, let’s take them in reverse. If your primary language is Western-derived, then you’re used to a block direction of top to bottom, and an inline direction of left to right. Let’s examine those terms more closely. The block direction is the direction in which block elements are placed by default in the current writing mode. In English, for example, the block direction is top to bot‐ tom, or vertical, as one paragraph (or other text element) is placed beneath the one before. 207 The inline direction is the direction in which inline elements are written within a block. To again take English as an example, the inline direction is left to right, or hor‐ izontal. In languages like Arabic and Hebrew, the inline direction is right to left instead. Let’s reconsider English for a moment. A plain page of English text, displayed on a screen, has a vertical block direction and a horizontal inline direction. But if the page is rotated 90 degrees anticlockwise using CSS Transforms, then suddenly the block direction is horizontal and the inline direction is vertical. (And bottom to top, at that.) This approach to content and layout is relatively new as of 2017, and a conversion from the old layout language, which was highly dependent on concepts of “horizon‐ tal” and “vertical,” is still underway. While the rest of the chapter will try to use the terms “block direction” and “inline direction,” please forgive any lapses into “vertical” and “horizontal.” Indenting Text Most books we read in Western languages format paragraphs of text with the first line indented, and no blank line between paragraphs. Some sites used to create the illu‐ sion of indented text by placing a small transparent image before the first letter in a paragraph, which shoved the text over. Thanks to CSS, there’s a much better way to indent text: text-indent. text-indent Values Initial value | Applies to Percentages Computed value Inherited Animatable Block-level elements Refer to the width of the containing block For percentage values, as specified; for length values, the absolute length Yes Yes 0 Using text-indent, the first line of any element can be indented by a given length, even if that length is negative. A common use for this property is to indent the first line of a paragraph: p {text-indent: 3em;} 208 | Chapter 6: Text Properties This rule will cause the first line of any paragraph to be indented three ems, as shown in Figure 6-1. Figure 6-1. Text indenting In general, you can apply text-indent to any element that generates a block box, and the indentation will occur along the inline direction. You can’t apply it to inline ele‐ ments or on replaced elements such as images. However, if you have an image within the first line of a block-level element, it will be shifted over with the rest of the text in the line. If you want to “indent” the first line of an inline element, you can create the effect with left padding or margin. You can also set negative values for text-indent, a technique that leads to a number of interesting effects. The most common use is a hanging indent, where the first line hangs out to one side of the rest of the element: p {text-indent: −4em;} Be careful when setting a negative value for text-indent; the first few words may be chopped off by the edge of the browser window if you aren’t careful. To avoid display problems, I recommend you use a margin or some padding to accommodate the neg‐ ative indentation: p {text-indent: −4em; padding-left: 4em;} Negative indents can, however, be used to your advantage. Consider the following example, demonstrated in Figure 6-2, which adds a floated image to the mix: p.hang {text-indent: −25px;}

This paragraph has a negatively indented first line, which overlaps the floated image that precedes the text. Subsequent lines do not overlap the image, since they are not indented in any way.

Indentation and Inline Alignment | 209 Figure 6-2. A floated image and negative text indenting A variety of interesting designs can be achieved using this simple technique. This specific effect, of trying to make text wrap along the edge of a floated image, is more robustly managed with CSS Float Shapes. See Chapter 10 for details. Any unit of length, including percentage values, may be used with text-indent. In the following case, the percentage refers to the width of the parent element of the ele‐ ment being indented. In other words, if you set the indent value to 10%, the first line of an affected element will be indented by 10 percent of its parent element’s width, as shown in Figure 6-3: div {width: 400px;} p {text-indent: 10%;}

This paragraph is contained inside a DIV, which is 400px wide, so the first line of the paragraph is indented 40px (400 * 10% = 40). This is because percentages are computed with respect to the width of the element.

Figure 6-3. Text indenting with percentages Note that this indentation only applies to the first line of an element, even if you insert line breaks. The interesting part about text-indent is that because it’s inher‐ ited, it can have unexpected effects. For example, consider the following markup, which is illustrated in Figure 6-4: div#outer {width: 500px;} div#inner {text-indent: 10%;} p {width: 200px;}

This first line of the DIV is indented by 50 pixels. 210 | Chapter 6: Text Properties 

This paragraph is 200px wide, and the first line of the paragraph is indented 50px. This is because computed values for 'text-indent' are inherited, instead of the declared values.

Figure 6-4. Inherited text indenting Text Alignment Even more basic than text-indent is the property text-align, which affects how the lines of text in an element are aligned with respect to one another. text-align Values start | end | left | right | center | justify | match-parent | start end Initial value In CSS3, start; in CSS 2.1, this was user agent-specific, likely depending on writing direction (e.g., left for Western languages like English) Applies to Block-level elements Computed value As specified, except in the case of match-parent Inherited Yes Animatable No Note CSS2 included a value that was dropped from CSS 2.1 due to a lack of implementation The quickest way to understand how these values work is to examine Figure 6-5, which sticks with three most widely supported values for the moment. Indentation and Inline Alignment | 211 Figure 6-5. Selected behaviors of the text-align property The values left, right, and center cause the text within elements to be aligned exactly as described. Because text-align applies only to block-level elements, such as paragraphs, there’s no way to center an anchor within its line without aligning the rest of the line (nor would you want to, since that would likely cause text overlap). Historically, which is to say under CSS 2.1 rules, the default value of text-align is left in left-to-right languages, and right in right-to-left languages. (CSS 2.1 had no notion of vertical writing modes.) In CSS3, left and right are mapped to the start or end edge, respectively, of a vertical language. This is illustrated in Figure 6-6. Figure 6-6. Left, right, and center in vertical writing modes 212 | Chapter 6: Text Properties As you no doubt expect, center causes each line of text to be centered within the ele‐ ment. Although you may be tempted to believe that text-align: center is the same as the element, it’s actually quite different. affected not only text, but also centered whole elements, such as tables. text-align does not control the alignment of elements, only their inline content. Figures 6-5 and 6-6 illustrate this clearly in various writing directions. Start and end alignment CSS3 (which is to say, the CSS Text Module Level 3 specification) added a number of new values to text-align, and even changed the default property value as compared to CSS 2.1. The new default value of start means that the text is aligned to the start edge of its line box. In left-to-right languages like English, that’s the left edge; in right-to-left lan‐ guages such as Arabic, it’s the right edge. In vertical languages, for that matter, it will be the top or bottom, depending on the writing direction. The upshot is that the default value is much more aware of the document’s language direction while leaving the default behavior the same in the vast majority of existing cases. In a like manner, end aligns text with the end edge of each line box—the right edge in LTR languages, the left edge in RTL languages, and so forth. The effects of these val‐ ues are shown in Figure 6-7. Figure 6-7. Start and end alignment Justified text An often-overlooked alignment value is justify, which raises some issues of its own. In justified text, both ends of a line of text are placed at the inner edges of the parent element, as Figure 6-8 shows. Then, the spacing between words and letters is adjusted so that each line is precisely the same length. Justified text is common in the print world (for example, in this book), but under CSS, a few extra considerations come into play. Indentation and Inline Alignment | 213 Figure 6-8. Justified text The user agent—and not CSS, at least as of late 2017—determines how justified text should be stretched to fill the space between the left and right edges of the parent. Some browsers, for example, might add extra space only between words, while others might distribute the extra space between letters (although the CSS specification states that “user agents may not further increase or decrease the inter-character space” if the property letter-spacing has been assigned a length value). Other user agents may reduce space on some lines, thus mashing the text together a bit more than usual. All of these possibilities will affect the appearance of an element, and may even change its height, depending on how many lines of text result from the user agent’s justification choices. There is a property meant to provide authors more say over how full justification is accomplished: text-justify. As of late 2017, it was barely supported in any browser, with plans to add it to Firefox and some buggy experimental work in Chrome. Parent matching There’s one more value to be covered, which is match-parent. This isn’t supported by browsers, but its intent is mostly covered by inherit anyway. The idea is, if you declare text-align: match-parent, the alignment of the element will match the alignment of its parent. So far, that sounds exactly like inherit, but there’s a difference: if the parent’s align‐ ment value is start or end, the result of match-parent is to assign a computed value of left or right to the element. That wouldn’t happen with inherit, which would apply start or end to the element with no changes. The value start end, while technically part of the text-align syn‐ tax in late 2017, is not covered because it remains unimplemented and is at risk of being dropped from the specification. 214 | Chapter 6: Text Properties Aligning the Last Line There may be times when you want to align the text in the very last line of an element differently than you did the rest of the content. For example, you might left-align the last line of an otherwise fully justified block of text, or choose to swap from left to center alignment. For those situations, there is text-align-last. text-align-last Values auto | start | end | left | right | center | justify Initial value auto Applies to Computed value Inherited Animatable Block-level elements As specified Yes No As with text-align, the quickest way to understand how these values work is to examine Figure 6-9. Figure 6-9. Differently aligned last lines As the figure shows, the last lines of the elements are aligned independently of the rest of the elements, according to the elements’ text-align-last values. A close study of Figure 6-9 will reveal that there’s more at play than just the last lines of block-level elements. In fact, text-align-last applies to any line of text that immediately precedes a forced line break, whether or not said line break is triggered by the end of an element. Thus, a line break occasioned by a
tag will make the line of text immediately before that break use the value of text-align-last. So too will it affect the last line of text in a block-level element, since a line break is gener‐ ated by the element’s closure. Indentation and Inline Alignment | 215 There’s an interesting wrinkle in text-align-last: if the first line of text in an ele‐ ment is also the last line of text in the element, then the value of text-align-last takes precedence over the value of text-align. Thus, the following styles will result in a centered paragraph, not a start-aligned paragraph: p {text-align: start; text-align-last: center;}

A paragraph.

As of late 2017, support for text-align-last was missing in Safari and Opera Mini, and Internet Explorer and Edge only supported left, right, and center. Inline Alignment Now that we’ve covered alignment along the inline direction, let’s move on to the ver‐ tical alignment of inline elements along the block direction—things like superscript‐ ing and “vertical alignment,” as it’s called. (Vertical with respect to the line of text, if the text is laid out horizontally.) Since the construction of lines is a very complex topic that merits its own small book, I’ll just stick to a quick overview here. The Height of Lines The distance between lines can be affected by changing the “height” of a line. note that “height” here is with respect to the line of text itself, assuming that the longer axis of a line is “width” even if it’s written vertically. The property names we cover from here will reveal a strong bias toward Western languages and their writing direc‐ tions; this is an artifact of the early days of CSS, when Western languages were the only ones that could be easily represented. The line-height property refers to the distance between the baselines of lines of text rather than the size of the font, and it determines the amount by which the height of each element’s box is increased or decreased. In the most basic cases, specifying lineheight is a way to increase (or decrease) the vertical space between lines of text, but this is a misleadingly simple way of looking at how line-height works. line-height controls the leading, which is the extra space between lines of text above and beyond the font’s size. In other words, the difference between the value of line-height and the size of the font is the leading. 216 | Chapter 6: Text Properties line-height Values | | | normal Initial value normal Applies to Percentages Computed value Inherited Animatable All elements (but see text regarding replaced and block-level elements) Relative to the font size of the element For length and percentage values, the absolute value; otherwise, as specified Yes Yes When applied to a block-level element, line-height defines the minimum distance between text baselines within that element. Note that it defines a minimum, not an absolute value, and baselines of text can wind up being pushed further apart than the value of line-height. line-height does not affect layout for replaced elements, but it still applies to them. Constructing a line Every element in a line of text generates a content area, which is determined by the size of the font. This content area in turn generates an inline box that is, in the absence of any other factors, exactly equal to the content area. The leading generated by line-height is one of the factors that increases or decreases the height of each inline box. To determine the leading for a given element, subtract the computed value of fontsize from the computed value of line-height. That value is the total amount of leading. And remember, it can be a negative number. The leading is then divided in half, and each half-leading is applied to the top and bottom of the content area. The result is the inline box for that element. As an example, let’s say the font-size (and therefore the content area) is 14 pixels tall, and the line-height is computed to 18 pixels. The difference (4 pixels) is divi‐ ded in half, and each half is applied to the top and bottom of the content area. This creates an inline box that is 18 pixels tall, with 2 extra pixels above and below the con‐ tent area. This sounds like a roundabout way to describe how line-height works, but there are excellent reasons for the description. Once all of the inline boxes have been generated for a given line of content, they are then considered in the construction of the line box. A line box is exactly as tall as Inline Alignment | 217 needed to enclose the top of the tallest inline box and the bottom of the lowest inline box. Figure 6-10 shows a diagram of this process. Figure 6-10. Line box diagram Assigning values to line-height Let’s now consider the possible values of line-height. If you use the default value of normal, the user agent must calculate the space between lines. Values can vary by user agent, but they’re generally around 1.2 times the size of the font, which makes line boxes taller than the value of font-size for a given element. Many values are simple length measures (e.g., 18px or 2em), but raw values are preferable in many situations. Be aware that even if you use a valid length meas‐ urement, such as 4cm, the browser (or the operating system) may be using an incor‐ rect metric for real-world measurements, so the line height may not show up as exactly four centimeters on your monitor. em, ex, and percentage values are calculated with respect to the font-size of the ele‐ ment. The results of the following CSS and HTML are shown in Figure 6-11: body {line-height: 18px; font-size: 16px;} p.cl1 {line-height: 1.5em;} p.cl2 {font-size: 10px; line-height: 150%;} p.cl3 {line-height: 0.33in;}

This paragraph inherits a 'line-height' of 14px from the body, as well as a 'font-size' of 13px.

This paragraph has a 'line-height' of 27px(18 * 1.5), so it will have slightly more line-height than usual.

This paragraph has a 'line-height' of 15px (10 * 150%), so it will have slightly more line-height than usual.

This paragraph has a 'line-height' of 0.33in, so it will have slightly more line-height than usual.

218 | Chapter 6: Text Properties Figure 6-11. Simple calculations with the line-height property Line-height and inheritance When the line-height is inherited by one block-level element from another, things get a bit trickier. line-height values inherit from the parent element as computed from the parent, not the child. The results of the following markup are shown in Figure 6-12. It probably wasn’t what the author had in mind: body {font-size: 10px;} div {line-height: 1em;} p {font-size: 18px;} /* computes to '10px' */

This paragraph's 'font-size' is 18px, but the inherited 'line-height' value is only 10px. This may cause the lines of text to overlap each other by a small amount.

Figure 6-12. Small line-height, large font-size, slight problem Why are the lines so close together? Because the computed line-height value of 10px was inherited by the paragraph from its parent div. One solution to the small line-height problem depicted in Figure 6-12 is to set an explicit line-height for every element, but that’s not very practical. A better alternative is to specify a number, which actually sets a scaling factor: body {font-size: 10px;} div {line-height: 1;} p {font-size: 18px;} When you specify a number, you cause the scaling factor to be an inherited value instead of a computed value. The number will be applied to the element and all of its child elements so that each element has a line-height calculated with respect to its own font-size (see Figure 6-13): Inline Alignment | 219 div {line-height: 1.5;} p {font-size: 18px;}

This paragraph's 'font-size' is 18px, and since the 'line-height' set for the parent div is 1.5, the 'line-height' for this paragraph is 27px (18 * 1.5).

Figure 6-13. Using line-height factors to overcome inheritance problems Though it seems like line-height distributes extra space both above and below each line of text, it actually adds (or subtracts) a certain amount from the top and bottom of an inline element’s content area to create an inline box. Assume that the default font-size of a paragraph is 12pt and consider the following: p {line-height: 16pt;} Since the “inherent” line height of 12-point text is 12 points, the preceding rule will place an extra 4 points of space around each line of text in the paragraph. This extra amount is divided in two, with half going above each line and the other half below. You now have 16 points between the baselines, which is an indirect result of how the extra space is apportioned. If you specify the value inherit, then the element will use the computed value for its parent element. This isn’t really any different than allowing the value to inherit natu‐ rally, except in terms of specificity and cascade resolution. Now that you have a basic grasp of how lines are constructed, let’s talk about “verti‐ cally” aligning elements relative to the line box—that is, displacing them along the block direction. Vertically Aligning Text If you’ve ever used the elements sup and sub (the superscript and subscript elements), or used an image with markup such as , then you’ve done some rudimentary vertical alignment. In CSS, the vertical-align prop‐ erty applies only to inline elements and replaced elements such as images and form inputs. vertical-align is not an inherited property. 220 | Chapter 6: Text Properties Because of the property name vertical-align, this section will use the terms “vertical” and “horizontal” to refer to the block and inline directions of the text. vertical-align Values baseline | sub | super | top | text-top | middle | bottom | textbottom | | Initial value baseline Applies to Percentages Inline elements and table cells Computed value Inherited Animatable Note For percentage and length values, the absolute length; otherwise, as specified No , Refer to the value of line-height for the element When applied to table cells, only the values baseline, top, middle, and bottom are recognized vertical-align accepts any one of eight keywords, a percentage value, or a length value. The keywords are a mix of the familiar and unfamiliar: baseline (the default value), sub, super, bottom, text-bottom, middle, top, and text-top. We’ll examine how each keyword works in relation to inline elements. Remember: vertical-align does not affect the alignment of con‐ tent within a block-level element. You can, however, use it to affect the vertical alignment of elements within table cells. Baseline alignment vertical-align: baseline forces the baseline of an element to align with the base‐ line of its parent. Browsers, for the most part, do this anyway, since you’d probably expect the bottoms of all text elements in a line to be aligned. If a vertically aligned element doesn’t have a baseline—that is, if it’s an image, a form input, or another replaced element—then the bottom of the element is aligned with the baseline of its parent, as Figure 6-14 shows: Inline Alignment | 221 img {vertical-align: baseline;}

The image found in this paragraph has its bottom edge aligned with the baseline of the text in the paragraph.

Figure 6-14. Baseline alignment of an image This alignment rule is important because it causes some web browsers to always put a replaced element’s bottom edge on the baseline, even if there is no other text in the line. For example, let’s say you have an image in a table cell all by itself. The image may actually be on a baseline, but in some browsers, the space below the baseline causes a gap to appear beneath the image. Other browsers will “shrink-wrap” the image with the table cell, and no gap will appear. The gap behavior is correct, despite its lack of appeal to most authors. See the aged and yet still relevant article “Images, Tables, and Mys‐ terious Gaps” for a more detailed explanation of gap behavior and ways to work around it. Superscripting and subscripting The declaration vertical-align: sub causes an element to be subscripted, meaning that its baseline (or bottom, if it’s a replaced element) is lowered with respect to its parent’s baseline. The specification doesn’t define the distance the element is lowered, so it may vary depending on the user agent. super is the opposite of sub; it raises the element’s baseline (or bottom of a replaced element) with respect to the parent’s baseline. Again, the distance the text is raised depends on the user agent. Note that the values sub and super do not change the element’s font size, so sub‐ scripted or superscripted text will not become smaller (or larger). Instead, any text in the sub- or superscripted element should be, by default, the same size as text in the parent element, as illustrated by Figure 6-15: span.raise {vertical-align: super;} span.lower {vertical-align: sub;}

This paragraph contains superscripted and subscripted text.

222 | Chapter 6: Text Properties Figure 6-15. Superscript and subscript alignment If you wish to make super- or subscripted text smaller than the text of its parent element, you can do so using the property font-size. Bottom feeding vertical-align: bottom aligns the bottom of the element’s inline box with the bot‐ tom of the line box. For example, the following markup results in Figure 6-16: .feeder {vertical-align: bottom;}

This paragraph, as you can see quite clearly, contains a image and a image, and then some text that is not tall.

Figure 6-16. Bottom alignment The second line of the paragraph in Figure 6-16 contains two inline elements, whose bottom edges are aligned with each other. They’re also below the baseline of the text. vertical-align: text-bottom refers to the bottom of the text in the line. For the purposes of this value, replaced elements, or any other kinds of non-text elements, are ignored. Instead, a “default” text box is considered. This default box is derived from the font-size of the parent element. The bottom of the aligned element’s inline box is then aligned with the bottom of the default text box. Thus, given the following markup, you get a result like the one shown in Figure 6-17: img.tbot {vertical-align: text-bottom;}

Here: a image, and then a image.

Inline Alignment | 223 Figure 6-17. Text-bottom alignment Getting on top Employing vertical-align: top has the opposite effect of bottom. Likewise, vertical-align: text-top is the reverse of text-bottom. Figure 6-18 shows how the following markup would be rendered: .up {vertical-align: top;} .textup {vertical-align: text-top;}

Here: a tall image, and then some text that's been vertically aligned.

Here: a image that's been vertically aligned, and then a image that's similarly aligned.

Figure 6-18. Aligning with the top and text-top of a line The exact position of this alignment will depend on which elements are in the line, how tall they are, and the size of the parent element’s font. In the middle There’s the value middle, which is usually (but not always) applied to images. It does not have the exact effect you might assume given its name. middle aligns the middle of an inline element’s box with a point that is 0.5ex above the baseline of the parent element, where 1ex is defined relative to the font-size for the parent element. Figure 6-19 shows this in more detail. 224 | Chapter 6: Text Properties Figure 6-19. Precise detail of middle alignment Since most user agents treat 1ex as one-half em, middle usually aligns the vertical midpoint of an element with a point one-quarter em above the parent’s baseline, though this is not a defined distance and so can vary from one user agent to another. Percentages Percentages don’t let you simulate align="middle" for images. Instead, setting a per‐ centage value for vertical-align raises or lowers the baseline of the element (or the bottom edge of a replaced element) by the amount declared, with respect to the parent’s baseline. (The percentage you specify is calculated as a percentage of lineheight for the element, not its parent.) Positive percentage values raise the element, and negative values lower it. Depending on how the text is raised or lowered, it can appear to be placed in adjacent lines, as shown in Figure 6-20, so take care when using percentage values: sub {vertical-align: −100%;} sup {vertical-align: 100%;}

We can either ^{soar to new heights} or, instead, _{sink into despair...}

Figure 6-20. Percentages and fun effects Let’s consider percentage values in more detail. Assume the following:

I felt that, if nothing else, I deserved a raise for my efforts.

Inline Alignment | 225 The 50%-aligned span element has its baseline raised nine pixels, which is half of the element’s inherited line-height value of 18px, not the seven pixels that would be half the font-size. Length alignment Finally, let’s consider vertical alignment with a specific length. vertical-align is very basic: it shifts an element up or down by the declared distance. Thus, verticalalign: 5px; will shift an element upward five pixels from its unaligned placement. Negative length values shift the element downward. This simple form of alignment did not exist in CSS1, but it was added in CSS2. It’s important to realize that vertically aligned text does not become part of another line, nor does it overlap text in other lines. Consider Figure 6-21, in which some ver‐ tically aligned text appears in the middle of a paragraph. Figure 6-21. Vertical alignments can cause lines to get taller As you can see, any vertically aligned element can affect the height of the line. Recall the description of a line box, which is exactly as tall as necessary to enclose the top of the tallest inline box and the bottom of the lowest inline box. This includes inline boxes that have been shifted up or down by vertical alignment. Word Spacing and Letter Spacing Now that we’ve dealt with vertical alignment of inline elements, let’s return to the inline direction for a look at manipulating word and letter spacing. As usual, these properties have some nonintuitive issues. Word Spacing The word-spacing property accepts a positive or negative length. This length is added to the standard space between words. In effect, word-spacing is used to modify interword spacing. Therefore, the default value of normal is the same as setting a value of zero (0). 226 | Chapter 6: Text Properties word-spacing Values | normal Initial value normal Applies to All elements Computed value For normal, the absolute length 0; otherwise, the absolute length Inherited Yes Animatable Yes If you supply a positive length value, then the space between words will increase. Set‐ ting a negative value for word-spacing brings words closer together: p.spread {word-spacing: 0.5em;} p.tight {word-spacing: −0.5em;} p.base {word-spacing: normal;} p.norm {word-spacing: 0;}

The spaces between words in this paragraph will be increased by 0.5em.

The spaces between words in this paragraph will be decreased by 0.5em.

The spaces between words in this paragraph will be normal.

The spaces between words in this paragraph will be normal.

Manipulating these settings has the effect shown in Figure 6-22. Figure 6-22. Changing the space between words So far, I haven’t actually given you a precise definition of “word.” In the simplest CSS terms, a “word” is any string of non-whitespace characters that is surrounded by whitespace of some kind. This definition has no real semantic meaning; it simply assumes that a document contains words, each of which is surrounded by one or more whitespace characters. A CSS-aware user agent cannot be expected to decide what is a valid word in a given language and what isn’t. This definition, such as it is, means word-spacing is unlikely to work in any languages that employ pictographs, Word Spacing and Letter Spacing | 227 or non-Roman writing styles. The property allows you to create very unreadable documents, as Figure 6-23 makes clear. Use word-spacing with care. Figure 6-23. Really wide word spacing Letter Spacing Many of the issues you encounter with word-spacing also occur with letterspacing. The only real difference between the two is that letter-spacing modifies the space between characters or letters. letter-spacing Values | normal Initial value normal Applies to All elements Computed value For length values, the absolute length; otherwise, normal Inherited Animatable Yes Yes As with the word-spacing property, the permitted values of letter-spacing include any length. The default keyword is normal (making it the same as letter-spacing: 0). Any length value you enter will increase or decrease the space between letters by that amount. Figure 6-24 shows the results of the following markup: p {letter-spacing: 0;} /* identical to 'normal' p.spacious {letter-spacing: 0.25em;} p.tight {letter-spacing: −0.25em;} */

The letters in this paragraph are spaced as normal.

The letters in this paragraph are spread out a bit.

The letters in this paragraph are a bit smashed together.

228 | Chapter 6: Text Properties Figure 6-24. Various kinds of letter spacing Using letter-spacing to increase emphasis is a time-honored technique. You might write the following declaration and get an effect like the one shown in Figure 6-25: strong {letter-spacing: 0.2em;}

This paragraph contains strongly emphasized text which is spread out for extra emphasis.

Figure 6-25. Using letter-spacing to increase emphasis If a page uses fonts with features like ligatures, and those features are enabled, then altering letter or word spacing can effectively dis‐ able them. Browsers will not recalculate ligatures or other joins when letter spacing is altered, for example. Spacing and Alignment The value of word-spacing may be influenced by the value of the property textalign. If an element is justified, the spaces between letters and words may be altered to fit the text along the full width of the line. This may in turn alter the spacing declared by the author with word-spacing. If a length value is assigned to letterspacing, then it cannot be changed by text-align; but if the value of letterspacing is normal, then inter-character spacing may be changed to justify the text. CSS does not specify how the spacing should be calculated, so user agents fill it in with their own algorithms. Note that the computed value is inherited, so child elements with larger or smaller text will have the same letter spacing as their parent element. You cannot define a scaling factor for word-spacing or letter-spacing to be inherited in place of the computed value (as is the case with line-height). As a result, you may run into problems such as those shown in Figure 6-26: p {letter-spacing: 0.25em; font-size: 20px;} small {font-size: 50%;} Word Spacing and Letter Spacing | 229 

This spacious paragraph features tiny text that is just as spacious, even though the author probably wanted the spacing to be in proportion to the size of the text.

Figure 6-26. Inherited letter spacing The only way to achieve letter spacing that’s in proportion to the size of the text is to set it explicitly, as follows: p {letter-spacing: 0.25em;} small {font-size: 50%; letter-spacing: 0.25em;} Text Transformation With the alignment properties covered, let’s look at ways to manipulate the capitaliza‐ tion of text using the property text-transform. text-transform Values uppercase | lowercase | capitalize | none Initial value none Applies to Computed value Inherited Animatable All elements As specified Yes No The default value none leaves the text alone and uses whatever capitalization exists in the source document. As their names imply, uppercase and lowercase convert text into all upper- or lowercase characters. Finally, capitalize capitalizes only the first letter of each word. Figure 6-27 illustrates each of these settings in a variety of ways: h1 {text-transform: capitalize;} strong {text-transform: uppercase;} p.cummings {text-transform: lowercase;} p.raw {text-transform: none;} 230 | Chapter 6: Text Properties 

The heading-one at the beginninG

By default, text is displayed in the capitalization it has in the source document, but it is possible to change this using the property 'text-transform'.

For example, one could Create TEXT such as might have been Written by the late Poet e.e.cummings.

If you feel the need to Explicitly Declare the transformation of text to be 'none', that can be done as well.

Figure 6-27. Various kinds of text transformation Different user agents may have different ways of deciding where words begin and, as a result, which letters are capitalized. For example, the text “heading-one” in the h1 element, shown in Figure 6-27, could be rendered in one of two ways: “Heading-one” or “Heading-One.” CSS does not say which is correct, so either is possible. You probably also noticed that the last letter in the h1 element in Figure 6-27 is still uppercase. This is correct: when applying a text-transform of capitalize, CSS only requires user agents to make sure the first letter of each word is capitalized. They can ignore the rest of the word. As a property, text-transform may seem minor, but it’s very useful if you suddenly decide to capitalize all your h1 elements. Instead of individually changing the content of all your h1 elements, you can just use text-transform to make the change for you: h1 {text-transform: uppercase;}

This is an H1 element

The advantages of using text-transform are twofold. First, you only need to write a single rule to make this change, rather than changing the h1 itself. Second, if you Text Transformation | 231 decide later to switch from all capitals back to initial capitals, the change is even eas‐ ier, as Figure 6-28 shows: h1 {text-transform: capitalize;}

This is an H1 element

Figure 6-28. Transforming an h1 element Remember that capitalize is a simple letter substitution at the beginning of each “word.” It does not mean that common headline-capitalization conventions, such as leaving articles (“a,” “an,” “the”) all lowercase, will be enforced. Text Decoration Next we come to text-decoration, which is a fascinating property that offers a truckload of interesting behaviors. text-decoration Values none | [ underline ‖ overline ‖ line-through ‖ blink ] Initial value none Applies to Computed value Inherited Animatable All elements As specified No No As you might expect, underline causes an element to be underlined, just like the U element in ancient HTML. overline causes the opposite effect—drawing a line across the top of the text. The value line-through draws a line straight through the middle of the text, which is also known as strikethrough text and is equivalent to the S and strike elements in HTML. blink causes the text to blink on and off, just like the much-maligned blink tag supported by Netscape. Figure 6-29 shows examples of each of these values: 232 | Chapter 6: Text Properties p.emph {text-decoration: underline;} p.topper {text-decoration: overline;} p.old {text-decoration: line-through;} p.annoy {text-decoration: blink;} p.plain {text-decoration: none;} Figure 6-29. Various kinds of text decoration It’s impossible to show the effect of blink in print, but it’s easy enough to imagine (perhaps all too easy). Incidentally, user agents are not required to actually blink blink text; and as of this writing, all known user agents were dropping or had dropped support for the blinking effect. (Internet Explorer never had it.) The value none turns off any decoration that might otherwise have been applied to an element. Usually, undecorated text is the default appearance, but not always. For example, links are usually underlined by default. If you want to suppress the under‐ lining of hyperlinks, you can use the following CSS rule to do so: a {text-decoration: none;} If you explicitly turn off link underlining with this sort of rule, the only visual differ‐ ence between the anchors and normal text will be their color (at least by default, though there’s no ironclad guarantee that there will be a difference in their colors). Bear in mind that many users are annoyed when they realize you’ve turned off link underlining. It’s a matter of opinion, so let your own tastes be your guide, but remember: if your link colors aren’t suffi‐ ciently different from normal text, users may have a hard time find‐ ing hyperlinks in your documents, particularly users with one form or another of color blindness. You can also combine decorations in a single rule. If you want all hyperlinks to be both underlined and overlined, the rule is: a:link, a:visited {text-decoration: underline overline;} Text Decoration | 233 Be careful, though: if you have two different decorations matched to the same ele‐ ment, the value of the rule that wins out will completely replace the value of the loser. Consider: h2.stricken {text-decoration: line-through;} h2 {text-decoration: underline overline;} Given these rules, any h2 element with a class of stricken will have only a linethrough decoration. The underline and overline decorations are lost, since shorthand values replace one another instead of accumulating. Weird Decorations Now, let’s look into the unusual side of text-decoration. The first oddity is that text-decoration is not inherited. No inheritance implies that any decoration lines drawn with the text—under, over, or through it—will be the same color as the parent element. This is true even if the descendant elements are a different color, as depicted in Figure 6-30: p {text-decoration: underline; color: black;} strong {color: gray;}

This paragraph, which is black and has a black underline, also contains strongly emphasized text which has the black underline beneath it as well.

Figure 6-30. Color consistency in underlines Why is this so? Because the value of text-decoration is not inherited, the strong element assumes a default value of none. Therefore, the strong element has no under‐ line. Now, there is very clearly a line under the strong element, so it seems silly to say that it has none. Nevertheless, it doesn’t. What you see under the strong element is the paragraph’s underline, which is effectively “spanning” the strong element. You can see it more clearly if you alter the styles for the boldface element, like this: p {text-decoration: underline; color: black;} strong {color: gray; text-decoration: none;}

This paragraph, which is black and has a black underline, also contains strongly emphasized text which has the black underline beneath it as well.

234 | Chapter 6: Text Properties The result is identical to the one shown in Figure 6-30, since all you’ve done is to explicitly declare what was already the case. In other words, there is no way to turn off underlining (or overlining or a line-through) generated by a parent element. When text-decoration is combined with vertical-align, even stranger things can happen. Figure 6-31 shows one of these oddities. Since the sup element has no deco‐ ration of its own, but it is elevated within an overlined element, the overline cuts through the middle of the sup element: p {text-decoration: overline; font-size: 12pt;} sup {vertical-align: 50%; font-size: 12pt;} Figure 6-31. Correct, although strange, decorative behavior By now you may be vowing never to use text decorations because of all the problems they could create. In fact, I’ve given you the simplest possible outcomes since we’ve explored only the way things should work according to the specification. In reality, some web browsers do turn off underlining in child elements, even though they aren’t supposed to. The reason browsers violate the specification is author expectations. Consider this markup: p {text-decoration: underline; color: black;} strong {color: silver; text-decoration: none;}

This paragraph, which is black and has a black underline, also contains boldfaced text which does not have black underline beneath it.

Figure 6-32 shows the display in a web browser that has switched off the underlining for the strong element. Figure 6-32. How some browsers really behave The caveat here is that many browsers do follow the specification, and future versions of existing browsers (or any other user agents) might one day follow the specification precisely. If you depend on using none to suppress decorations, it’s important to real‐ ize that it may come back to haunt you in the future, or even cause you problems in the present. Then again, future versions of CSS may include the means to turn off decorations without using none incorrectly, so maybe there’s hope. Text Decoration | 235 There is a way to change the color of a decoration without violating the specification. As you’ll recall, setting a text decoration on an element means that the entire element has the same color decoration, even if there are child elements of different colors. To match the decoration color with an element, you must explicitly declare its decora‐ tion, as follows: p {text-decoration: underline; color: black;} strong {color: silver; text-decoration: underline;}

This paragraph, which is black and has a black underline, also contains strongly emphasized text which has the black underline beneath it as well, but whose gray underline overlays the black underline of its parent.

In Figure 6-33, the strong element is set to be gray and to have an underline. The gray underline visually “overwrites” the parent’s black underline, so the decoration’s color matches the color of the strong element. Figure 6-33. Overcoming the default behavior of underlines Text Rendering A recent addition to CSS is text-rendering, which is actually an SVG property that is nevertheless treated as CSS by supporting user agents. It lets authors indicate what the user agent should prioritize when displaying text. text-rendering Values auto | optimizeSpeed | optimizeLegibility | geometricPrecision Initial value auto Applies to All elements Inherited Yes Animatable Yes The values optimizeSpeed and optimizeLegibility are relatively self-explanatory, indicating that drawing speed should be favored over legibility features like kerning and ligatures (for optimizeSpeed) or vice versa (for optimizeLegibility). 236 | Chapter 6: Text Properties The precise legibility features that are used with optimizeLegibility are not explic‐ itly defined, and the text rendering often depends on the operating system on which the user agent is running, so the exact results may vary. Figure 6-34 shows text opti‐ mized for speed, and then optimized for legibility. Figure 6-34. Different optimizations As you can see in Figure 6-34, the differences between the two optimizations are objectively rather small, but they can have a noticeable impact on readability. Some user agents will always optimize for legibility, even when optimizing for speed. This is likely an effect of rendering speeds having gotten so fast in the past few years. The value geometricPrecision, on the other hand, directs the user agent to draw the text as precisely as possible, such that it could be scaled up or down with no loss of fidelity. You might think that this is always the case, but not so. Some fonts change kerning or ligature effects at different text sizes, for example, providing more kerning space at smaller sizes and tightening up the kerning space as the size is increased. With geometricPrecision, those hints are ignored as the text size changes. If it helps, think of it as the user agent drawing the text as though all the text is a series of SVG paths, not font glyphs. Even by the usual standard of web standards, the value auto is pretty vaguely defined in SVG: the user agent shall make appropriate tradeoffs to balance speed, legibility and geomet‐ ric precision, but with legibility given more importance than speed and geometric pre‐ cision. That’s it: user agents get to do what they think is appropriate, leaning towards legibil‐ ity. Text Shadows Sometimes, you just really need your text to cast a shadow. That’s where text-shadow comes in. The syntax might look a little wacky at first, but it should become clear enough with just a little practice. Text Shadows | 237 text-shadow Values none | [ ‖ ?]# Initial value none Applies to All elements Inherited No Animatable Yes The default is to not have a drop shadow for text. Otherwise, it’s possible to define one or more shadows. Each shadow is defined by an optional color and three length values, the last of which is also optional. The color sets the shadow’s color so it’s possible to define green, purple, or even white shadows. If the color is omitted, the shadow will be the same color as the text. The first two length values determine the offset distance of the shadow from the text; the first is the horizontal offset and the second is the vertical offset. To define a solid, un-blurred green shadow offset five pixels to the right and half an em down from the text, as shown in Figure 6-35, you would write: text-shadow: green 5px 0.5em; Negative lengths cause the shadow to be offset to the left and upward from the origi‐ nal text. The following, also shown in Figure 6-35, places a light blue shadow five pix‐ els to the left and half an em above the text: text-shadow: rgb(128,128,255) −5px −0.5em; Figure 6-35. Simple shadows The optional third length value defines a blur radius for the shadow. The blur radius is defined as the distance from the shadow’s outline to the edge of the blurring effect. A radius of two pixels would result in blurring that fills the space between the shad‐ ow’s outline and the edge of the blurring. The exact blurring method is not defined, so different user agents might employ different effects. As an example, the following styles are rendered as shown in Figure 6-36: 238 | Chapter 6: Text Properties p.cl1 {color: black; text-shadow: gray 2px 2px 4px;} p.cl2 {color: white; text-shadow: 0 0 4px black;} p.cl3 {color: black; text-shadow: 1em 0.5em 5px red, −0.5em −1em hsla(100,75%, 25%,0.33);} Figure 6-36. Dropping shadows all over Note that large numbers of text shadows, or text shadows with very large blur values, can create performance slowdowns, particularly in low-power and CPU-constrained situations such as mobile devi‐ ces. Authors are advised to test thoroughly before deploying public designs that use text shadows. Handling Whitespace Now that we’ve covered a variety of ways to style the text, let’s talk about the property white-space, which affects the user agent’s handling of space, newline, and tab char‐ acters within the document source. white-space Values normal | nowrap | pre | pre-wrap | pre-line Initial value normal Applies to Computed value Inherited Animatable All elements (CSS 2.1); block-level elements (CSS1 and CSS2) As specified No No Using this property, you can affect how a browser treats the whitespace between words and lines of text. To a certain extent, default XHTML handling already does this: it collapses any whitespace down to a single space. So given the following markup, the rendering in a web browser would show only one space between each word and ignore the line-feed in the elements: Handling Whitespace | 239 

This paragraph has many spaces in it.

You can explicitly set this default behavior with the following declaration: p {white-space: normal;} This rule tells the browser to do as browsers have always done: discard extra white‐ space. Given this value, line-feed characters (carriage returns) are converted into spaces, and any sequence of more than one space in a row is converted to a single space. Should you set white-space to pre, however, the whitespace in an affected element is treated as though the elements were XHTML pre elements; whitespace is not ignored, as shown in Figure 6-37: p {white-space: pre;}

This paragraph has many spaces in it.

Figure 6-37. Honoring the spaces in markup With a white-space value of pre, the browser will pay attention to extra spaces and even carriage returns. In this respect, and in this respect alone, any element can be made to act like a pre element. The opposite value is nowrap, which prevents text from wrapping within an element, except wherever you use a br element. Using nowrap in CSS is much like setting a table cell not to wrap in HTML 4 with , except the white-space value can be applied to any element. The effects of the following markup are shown in Figure 6-38:

This paragraph is not allowed to wrap, which means that the only way to end a line is to insert a line-break element. If no such element is inserted, then the line will go forever, forcing the user to scroll horizontally to read whatever can't be initially displayed
in the browser window.

Figure 6-38. Suppressing line wrapping with the white-space property 240 | Chapter 6: Text Properties You can actually use white-space to replace the nowrap attribute on table cells: td {white-space: nowrap;}

The contents of this cell are not wrapped.

Neither are the contents of this cell.

Nor this one, or any after it, or any other cell in this table.

CSS prevents any wrapping from happening.

CSS 2.1 introduced the values pre-wrap and pre-line, which were absent in earlier versions of CSS. The effect of these values is to allow authors to better control white‐ space handling. If an element is set to pre-wrap, then text within that element has whitespace sequen‐ ces preserved, but text lines are wrapped normally. With this value, line-breaks in the source and those that are generated are also honored. pre-line is the opposite of pre-wrap and causes whitespace sequences to collapse as in normal text but honors new lines. For example, consider the following markup, which is illustrated in Figure 6-39:

This paragraph has a great many s p a c e s within content, but their preservation will not prevent wrapping or line breaking.

This paragraph has a great many s p a c e s within content, but their collapse will not prevent line wrapping or line breaking.

its textual line its textual Figure 6-39. Two different ways to handle whitespace Handling Whitespace | 241 Table 6-1 summarizes the behaviors of white-space properties. Table 6-1. White-space properties Value Whitespace Line feeds Auto line wrapping Honored Allowed pre-line Collapsed normal Collapsed Ignored Allowed nowrap Collapsed Ignored Prevented pre Preserved Honored Prevented pre-wrap Preserved Honored Allowed Setting Tab Sizes Since whitespace is preserved in some values of white-space, it stands to reason that tabs (i.e., Unicode code point 0009) will be displayed as, well, tabs. But how many spaces should each tab equal? That’s where tab-size comes in. tab-size Values Initial value | Applies to Computed value Inherited Animatable Block elements The absolute-length equivalent of the specified value Yes Yes 8 By default, any tab character will be treated the same as eight spaces in a row, but you can alter that by using a different integer value. Thus, tab-size: 4 will cause each tab to be rendered the same as if it were four spaces in a row. If a length value is supplied, then each tab is rendered using that length. For example, tab-size: 10px will cause a sequence of three tabs to be rendered as 30 pixels of whitespace. The effects of the following rules is illustrated in Figure 6-40. 242 | Chapter 6: Text Properties Figure 6-40. Differing tab lengths Note that tab-size is effectively ignored when the value of white-space causes whitespace to be collapsed (see Table 6-1). The value will still be computed in such cases, but there will be no visible effect no matter how many tabs appear in the source. Currently, tab-size is supported in WebKit and Gecko (as –moztab-size). In both cases, only integer values are supported, not length values. Wrapping and Hyphenation Hyphens can be very useful in situations where there are long words and short line lengths, such as blog posts on mobile devices and portions of The Economist. Authors can always insert their own hyphenation hints using the Unicode character U+00AD SOFT HYPHEN (or, in HTML, ­), but CSS also offers a way to enable hyphena‐ tion without littering up the document with hints. hyphens Values manual | auto | none Initial value manual Applies to Computed value Inherited Animatabale All elements As specified Yes No Wrapping and Hyphenation | 243 With the default value of manual, hyphens are only inserted where there are manually-inserted hyphenation markers in the document, such as U+00AD or ­. Otherwise, no hyphenation occurs. The value none, on the other hand, suppresses any hyphenation, even if manual break markers are present; thus, U+00AD and ­ are ignored. The far more interesting (and potentially inconsistent) value is auto, which permits the browser to insert hyphens and break words at “appropriate” places inside words, even where no manually inserted hyphenation breaks exist. This leads to interesting questions like what constitutes a “word” and under what circumstances it is appropri‐ ate to hyphenate a word, both of which are highly language-dependent. User agents are supposed to prefer manually inserted hyphen breaks to automatically determined breaks, but there are no guarantees. An illustration of hyphenation, or the suppres‐ sion thereof, in the following example is shown in Figure 6-41: .cl01 {hyphens: auto;} .cl02 {hyphens: manual;} .cl03 {hyphens: none;}

Supercalifragilisticexpialidocious antidisestablishmentarian ism.

Supercalifragilisticexpialidocious antidisestablishmentarian ism.

Super­cali­fragi­listic­expi­ali­ docious anti­dis­establish­ment­arian­ism.

Super­cali­fragi­listic­expi­ali­ docious anti­dis­establish­ment­arian­ism.

Figure 6-41. Hyphenation results Because hyphenation is so language-dependent, and because the CSS specification does not define precise (or even vague) rules regarding how user agents should carry out hyphenation, there is every chance that hyphenation will be different from one browser to the next. 244 | Chapter 6: Text Properties Furthermore, if you do choose to hyphenate, be careful about the elements to which you apply the hyphenation. hyphens is an inherited property, so declaring body {hyphens: auto;} will apply hyphenation to everything in your document—includ‐ ing textareas, code samples, block quotes, and so on. Blocking automatic hyphenation at the level of those elements is probably a good idea, using rules something like this: body {hyphens: auto;} code, var, kbd, samp, tt, dir, listing, plaintext, xmp, abbr, acronym, blockquote, q, textarea, input, option {hyphens: manual;} It’s probably obvious why suppressing hyphenation in code samples and code blocks is desirable, especially in languages that use hyphens in things like property and value names. (Ahem.) Similar logic holds for keyboard input text—you definitely don’t want a stray dash getting into your Unix command-line examples! And so on down the line. If you decide that you want to hyphenate some of these elements, just remove them from the selector. (It can be kind of fun to watch the text you’re typing into a textarea get auto-hyphenated as you type it.) As of late 2017, hyphens was supported by all major desktop browsers except Chrome/Blink, and required vendor prefixes in Safari and Edge. As noted, such support is always languagedependent. Hyphens can be suppressed by the effects of other properties, such as word-break, which affects how soft wrapping of text is calculated in various languages. word-break Values normal | break-all | keep-all Initial value normal Applies to Computed value Inherited Animatable All elements As specified Yes Yes When a run of text is too long to fit into a single line, it is soft wrapped. This is in contrast to hard wraps, which are things like line-feed characters and
elements. Where the text is soft wrapped is determined by the user agent (or the OS it uses), but word-break lets authors influence its decision-making. Wrapping and Hyphenation | 245 The default value of normal means that text should be wrapped like it always has been. In practical terms, this means that text is broken between words, though the definition of a word varies by language. In Latin-derived languages like English, this is almost always a space between letter sequences (e.g., words). In ideographic lan‐ guages like Japanese, each symbol is a word, so breaks can occur between any two symbols. In other CJK languages, though, the soft-wrap points may be limited to appear between sequences of symbols that are not space-separated. Again, that’s all by default, and is the way browsers have handled text for years. If you apply the value break-all, then soft wrapping can (and will) occur between any two characters, even if they are in the middle of a word. With this value, no hyphens are shown, even if the soft wrapping occurs at a hyphenation point (see hyphens, earlier). Note that values of the line-break property (described next) can affect the behavior of break-all in CJK text. keep-all, on the other hand, suppresses soft wrapping between characters, even in CJK languages where each symbol is a word. Thus, in Japanese, a sequence of sym‐ bols with no whitespace will not be soft wrapped, even if this means the text line will exceed the length of its element. (This behavior is similar to white-space: pre.) Figure 6-42 shows a few examples of word-break values, and Table 6-2 summarizes the effects of each value. Figure 6-42. Altering word-breaking behavior Table 6-2. Word-breaking behavior Value Non-CJK As usual normal CJK As usual Hyphenation permitted Yes break-all After any character After any character No keep-all 246 | As usual Chapter 6: Text Properties Around sequences Yes If your interests run to CJK text, then in addition to word-break you will also want to get to know line-break. line-break Values auto | loose | normal | strict Initial value auto Applies to Computed value Inherited Animatable All elements As specified Yes Yes As we just saw, word-break can affect how lines of text are soft wrapped in CJK text. The line-break property also affects such soft wrapping, specifically how wrapping is handled around CJK-specific symbols and around non-CJK punctuation (such as exclamation points, hyphens, and ellipses) that appears in text declared to be CJK. In other words, line-break applies to certain CJK characters all the time, regardless of the content’s declared language. If you throw some CJK characters into a paragraph of English text, line-break will still apply to them, but not to anything else in the text. Conversely, if you declare content to be in a CJK language, line-break will con‐ tinue to apply to those CJK characters plus a number of non-CJK characters within the CJK text. These include punctuation marks, currency symbols, and a few other symbols. There is no authoritative list of which characters are affected and which are not, but the specification provides a list of recommended symbols and behaviors around those symbols. The default value auto allows user agents to soft wrap text as they like, and more importantly lets UAs vary the line breaking they do based on the situation. For exam‐ ple, the UA can use looser line-breaking rules for short lines of text and stricter rules for long lines. In effect, auto allows the user agent to switch between the loose, nor mal, and strict values as needed, possibly even on a line-by-line basis within a single element. Wrapping and Hyphenation | 247 Doubtless you can infer that those other values have the following general meanings: loose This value imposes the “least restrictive” rules for wrapping text, and is meant for use when line lengths are short, such as in newspapers. normal This value imposes the “most common” rules for wrapping text. What exactly “most common” means is not precisely defined, though there is the aforemen‐ tioned list of recommended behaviors. strict This value imposes the “most stringent” rules for wrapping text. Again, this is not precisely defined. Wrapping Text After all that information about hyphenation and soft wrapping, what happens when text overflows its container anyway? That’s what overflow-wrap addresses. overflow-wrap (neé word-wrap) Values normal | break-word Initial value normal Applies to Computed value Inherited Animatable All elements As specified Yes Yes This property couldn’t be more straightforward. If the default value of normal is in effect, then wrapping happens as normal; which is to say, between words or as direc‐ ted by the language. If break-word is in effect, then wrapping can happen in the mid‐ dle of words. Figure 6-43 illustrates the difference. Figure 6-43. Overflow wrapping 248 | Chapter 6: Text Properties Note that overflow-wrap can only operate if the value of whitespace allows line wrapping. If it does not (e.g., with the value pre), then overflow-wrap has no effect. Where overflow-wrap gets complicated is in its history and implementation. Once upon a time there was a property called word-wrap that did exactly what overflowwrap does. The two are so identical that the specification specifically states that user agents “must treat word-wrap as an alternate name for the overflow-wrap property, as if it were a shorthand of overflow-wrap.” Sadly, browsers didn’t always do this, and word-wrap was better supported. For this reason, it’s common to use both for backward compatibility: pre {word-wrap: break-word; overflow-wrap: break-word;} As of late 2017, overflow-wrap enjoys very widespread supports, so it’s pretty safe to use. While overflow-wrap: break-word may appear very similar to word-break: breakall, they are not the same thing. To see why, compare the second box in Figure 6-43 to the top middle box in Figure 6-42. As it shows, overflow-wrap only kicks in if content actually overflows; thus, when there is an opportunity to use whitespace in the source to wrap lines, overflow-wrap will take it. By contrast, word-break: break-all will cause wrapping when content reaches the wrapping edge, regardless of any whitespace that comes earlier in the line. Writing Modes If you’re reading this book in English or any number of other mainly Western lan‐ guages, then you’re reading the text left to right and top to bottom, which is the flow direction of English. Not every language runs this way. There are many right-to-left and top-to-bottom languages such as Hebrew and Arabic, and many languages that can be written primarily top-to-bottom. Some of the latter are secondarily left to right, such as Chinese and Japanese, whereas others are right to left, like Mongolian. Setting Writing Modes The property used for specifying one of the three available writing mode is, of all things, writing-mode. Writing Modes | 249 writing-mode Values horizontal-tb | vertical-rl | vertical-lr Initial value horizontal-tb Applies to All elements except table row groups, table column groups, table rows, table columns, ruby base containers, and ruby annotation containers Computed value As specified Inherited Yes Animatable Yes The default value, horizontal-tb, means “a horizontal inline direction, and a top-tobottom block direction.” This covers all Western and some Middle Eastern languages, which may differ in the direction of their horizontal writing. The other two values offer a vertical inline direction, and either a right-to-left or left-to-right block direc‐ tion. All three are illustrated in Figure 6-44. Figure 6-44. Writing modes Notice how the lines are strung together in the two vertical examples. If you tilt your head to the right, the text in vertical-rl is at least readable. The text in verticallr, on the other hand, is difficult to read because it appears to flow from bottom to top, at least when arranging English text. This is not a problem in languages which actually use vertical-lr flow, such as form of Japanese. As of late 2017, vertical flows can only have the inline direction go from top to bottom. It is possible to create bottom-to-top vertical flows of Western-language text by applying vertical-rl to an element and then rotating the element 180 degrees with CSS Transforms (see Chapter 16). This presents a bottom-to-top, left-to-right visual flow. Using vertical-lr and rotating it creates a bottom-to-top, right-to-left flow. Both are illustrated in Figure 6-45: 250 | Chapter 6: Text Properties .flip {transform: rotate(180deg);} #one {writing-mode: vertical-rl;} #two {writing-mode: vertical-lr;} Figure 6-45. Flipping vertical writing modes The challenge of working with text like that is that everything is flipped, which means what we see is at odds with what’s actually happening. The text of vertical-rl (vertical-right-to-left) is visually progressing left to right, for example. The same problem arises when applying inline block-alignment properties such as vertical-align. In vertical writing modes, the block direction is horizontal, which means vertical alignment of inline elements actually causes them to move horizon‐ tally. This is illustrated in Figure 6-46. Figure 6-46. Writing modes and “vertical” alignment All the super- and subscript elements cause horizontal shifts, both of themselves and the placement of the lines they occupy, even through the property used to move them is vertical-align. As described earlier, the vertical displacement is with respect to the line box, where the box’s baseline is defined as horizontal—even when it’s being drawn vertically. Confused? It’s OK. Writing modes are likely to confuse you, because it’s such a differ‐ ent way of thinking and because old assumptions in the CSS specification clash with the new capabilities. If there had been vertical writing modes from the outset, Writing Modes | 251 vertical-align would likely have a different name—inline-align or something like that. (Maybe one day that will happen.) One last note: if you’re already used to CSS Transforms, you might be tempted to think of these vertical writing modes as equivalent to rotating the text 90 degrees. They are not the same, for two reasons. One, this only appears to be the case for vertical-rl; vertical-lr has the look of text that flows “bottom to top.” Two, the cardinal points don’t change when flowing text vertically. The top is still the top, in other words. This is illustrated by the following styles, whose results are depicted in Figure 6-47: .boxed {border-top: 3px solid red; border-left: 3px dashed tan;} #one {writing-mode: vertical-rl;} #two {writing-mode: vertical-lr;} Figure 6-47. Writing modes and the “cardinal” directions of CSS In both cases, the top border is solid red, and the left border is dashed tan. The cardi‐ nal points don’t rotate with the text—because the text isn’t rotated. It’s being flowed in a different way. Now here’s where it gets unusual. While the borders don’t migrate around the element box, margins can, but not due to anything in the CSS specification. This happens because user agents (at least as of late 2017) maintain internal styles that relate to the start and end of the element in the block direction. In languages that flow top to bottom, then the start and end of the element’s block direction are its top and bottom sides. But in vertical writing, the block direction is right to left or left to right. Thus, you can set up a bunch of paragraphs to flow vertically, and if you leave the margins alone, what would normally be top and bottom margins will become left and right margins. You can see this effect in Figure 6-48, which illustrated the result of the following styles: p { margin-top: 1em;} #one {writing-mode: vertical-rl;} #two {writing-mode: vertical-lr;} 252 | Chapter 6: Text Properties Figure 6-48. The placement of UA default margins There are the top margins, as declared, right along the tops of the two paragraphs. The empty space to the side of each paragraph is created by the block-start and blockend margins. If we explicitly set the right and left margins to zero, then the space between the paragraphs would be removed. Remember: this happens because user agents, by default, represent the margins of text elements using properties like block-start-margin (which is not an actual prop‐ erty in CSS, at least not yet). If you explicitly set top, bottom, or side margins using properties like margin-top, then they will be applied to the element box just as bor‐ ders were: top margin on top, right margin to the right, and so on. Changing Text Orientation Once you’ve settled on a writing mode, you may decide you want to change the orien‐ tation of characters within those lines of text. There are many reasons you might want to do this, not least of which are situations where different writing systems are commingled, such as Japanese text with English words or numbers mixed in. In these cases, text-orientation is the answer. text-orientation Values mixed | upright | sideways Initial value mixed Applies to All elements except table row groups, table rows, table column groups, and table columns Computed value As specified Inherited Yes Animatable Yes Writing Modes | 253 The effect of text-orientation is to affect how characters are oriented. What that means is best illustrated by the following styles, rendered in Figure 6-49: .verts {writing-mode: vertical-lr;} #one {text-orientation: mixed;} #two {text-orientation: upright;} #thr {text-orientation: sideways;} Figure 6-49. Text orientation Across the top of Figure 6-49 is a basically unstyled paragraph of mixed Japanese and English text. Below that, three copies of that paragraph, using the writing mode vertical-lr. In the first of the three, text-orientation: mixed, writes the horizontal-script characters (the English) sideways, and the vertical-script characters (the Japanese) upright. In the second, all characters are upright, including the English characters. In the third, all characters are sideways, including the Japanese characters. Declaring Direction Harking back to the days of CSS2, there are a pair of properties that can be used to affect the direction of text by changing the inline baseline direction: direction and unicode-bidi. The CSS specification explicitly warns against using direction and unicode-bidi in CSS when applied to HTML documents. To quote: “Because HTML [user agents] can turn off CSS styling, we recommend…the HTML dir attribute and element to ensure correct bidirectional layout in the absence of a style sheet.” The properties are covered here because they may appear in legacy stylesheets. 254 | Chapter 6: Text Properties direction Values ltr | rtl Initial value ltr Applies to Computed value Inherited Animatable All elements As specified Yes Yes The direction property affects the writing direction of text in a block-level element, the direction of table column layout, the direction in which content horizontally overflows its element box, and the position of the last line of a fully justified element. For inline elements, direction applies only if the property unicode-bidi is set to either embed or bidi-override (See the following description of unicode-bidi). Although ltr is the default, it is expected that if a browser is displaying right-to-left text, the value will be changed to rtl. Thus, a browser might carry an internal rule stating something like the following: *:lang(ar), *:lang(he) {direction: rtl;} The real rule would be longer and encompass all right-to-left languages, not just Ara‐ bic and Hebrew, but it illustrates the point. While CSS attempts to address writing direction, Unicode has a much more robust method for handling directionality. With the property unicode-bidi, CSS authors can take advantage of some of Unicode’s capabilities. unicode-bidi Values normal | embed | bidi-override Initial value normal Applies to Computed value Inherited Animatable All elements As specified No Yes Writing Modes | 255 Here we’ll simply quote the value descriptions from the CSS 2.1 specification, which do a good job of capturing the essence of each value: normal The element does not open an additional level of embedding with respect to the bidirectional algorithm. For inline-level elements, implicit reordering works across element boundaries. embed If the element is inline-level, this value opens an additional level of embedding with respect to the bidirectional algorithm. The direction of this embedding level is given by the direction property. Inside the element, reordering is done implicitly. This corresponds to adding an LRE (U+202A; for direction: ltr) or an RLE (U+202B; for direction: rtl) at the start of the element and a PDF (U +202C) at the end of the element. bidi-override This creates an override for inline-level elements. For block-level elements, this creates an override for inline-level descendants not within another block. This means that, inside the element, reordering is strictly in sequence according to the direction property; the implicit part of the bidirectional algorithm is ignored. This corresponds to adding an LRO (U+202D; for direction: ltr) or RLO (U +202E; for direction: rtl) at the start of the element and a PDF (U+202C) at the end of the element. Summary Even without altering the font face, there are many ways to change the appearance of text. There are classic effects such as underlining, but CSS also enables you to draw lines over text or through it, change the amount of space between words and letters, indent the first line of a paragraph (or other block-level element), align text in various ways, exert influence over the hyphenation and line breaking of text, and much more. You can even alter the amount of space between lines of text. There is also support in CSS for languages other than those that are written left-to-right, top-to-bottom. Given that so much of the web is text, the strength of these properties makes a great deal of sense. Recent developments in improving text legibility and placement are likely only the beginnings of what we will eventually be able to do with text styling. 256 | Chapter 6: Text Properties CHAPTER 7 Basic Visual Formatting This chapter is all about the theoretical side of visual rendering in CSS. Why is that necessary? The answer is that with a model as open and powerful as that contained within CSS, no book could hope to cover every possible way of combining properties and effects. You will undoubtedly go on to discover new ways of using CSS. In explor‐ ing CSS, you may encounter seemingly strange behaviors in user agents. With a thor‐ ough grasp of how the visual rendering model works, you’ll be better able to determine whether a behavior is a correct (if unexpected) consequence of the render‐ ing engine CSS defines. Basic Boxes At its core, CSS assumes that every element generates one or more rectangular boxes, called element boxes. (Future versions of the specification may allow for nonrectangu‐ lar boxes, and indeed there have been proposals to change this, but for now every‐ thing is rectangular.) Each element box has a content area at its center. This content area is surrounded by optional amounts of padding, borders, outlines, and margins. These areas are considered optional because they could all be set to a width of zero, effectively removing them from the element box. An example content area is shown in Figure 7-1, along with the surrounding regions of padding, borders, and margins. Each of the margins, borders, and the padding can be set using various side-specific properties, such as margin-left or border-bottom, as well as shorthand properties such as padding. The outline, if any, does not have side-specific properties. The con‐ tent’s background—a color or tiled image, for example—is applied within the padding by default. The margins are always transparent, allowing the background(s) of any parent element(s) to be visible. Padding cannot have a negative length, but margins can. We’ll explore the effects of negative margins later on. 257 Figure 7-1. The content area and its surroundings Borders are generated using defined styles, such as solid or inset, and their colors are set using the border-color property. If no color is set, then the border takes on the foreground color of the element’s content. For example, if the text of a paragraph is white, then any borders around that paragraph will be white, unless the author explicitly declares a different border color. If a border style has gaps of some type, then the element’s background is visible through those gaps by default. Finally, the width of a border can never be negative. The various components of an element box can be affected via a number of proper‐ ties, such as width or border-right. Many of these properties will be used in this book, even though they aren’t defined here. A Quick Refresher Let’s quickly review the kinds of boxes we’ll be discussing, as well as some important terms that are needed to follow the explanations to come: Normal flow This is the left-to-right, top-to-bottom rendering of text in Western languages and the familiar text layout of traditional HTML documents. Note that the flow direction may be changed in non-Western languages. Most elements are in the normal flow, and the only way for an element to leave the normal flow is to be floated, positioned, or made into a flexible box or grid layout element. Remem‐ ber, the discussions in this chapter cover only elements in the normal flow. Nonreplaced element This is an element whose content is contained within the document. For exam‐ ple, a paragraph (p) is a nonreplaced element because its textual content is found within the element itself. Replaced element This is an element that serves as a placeholder for something else. The classic example of a replaced element is the img element, which simply points to an 258 | Chapter 7: Basic Visual Formatting image file that is inserted into the document’s flow at the point where the img element itself is found. Most form elements are also replaced (e.g., ). Root element This is the element at the top of the document tree. In HTML documents, this is the element html. In XML documents, it can be whatever the language permits; for example, the root element of RSS files is rss. Block box This is a box that an element such as a paragraph, heading, or div generates. These boxes generate “new lines” both before and after their boxes when in the normal flow so that block boxes in the normal flow stack vertically, one after another. Any element can be made to generate a block box by declaring display: block. Inline box This is a box that an element such as strong or span generates. These boxes do not generate “line breaks” before or after themselves. Any element can be made to generate an inline box by declaring display: inline. Inline-block box This is a box that is like a block box internally, but acts like an inline box exter‐ nally. It acts similar to, but not quite the same as, a replaced element. Imagine picking up a div and sticking it into a line of text as if it were an inline image, and you’ve got the idea. There are several other types of boxes, such as table-cell boxes, but they won’t be cov‐ ered in this book for a variety of reasons—not the least of which is that their com‐ plexity demands a book of its own, and very few authors will actually wrestle with them on a regular basis. The Containing Block There is one more kind of box that we need to examine in detail, and in this case enough detail that it merits its own section: the containing block. Every element’s box is laid out with respect to its containing block; in a very real way, the containing block is the “layout context” for a box. CSS defines a series of rules for determining a box’s containing block. We’ll cover only those rules that pertain to the concepts covered in this book in order to keep our focus. For an element in the normal, Western-style flow of text, the containing block forms from the content edge of the nearest ancestor that generated a list item or block box, Basic Boxes | 259 which includes all table-related boxes (e.g., those generated by table cells). Consider the following markup:

This is a paragraph.

In this very simple markup, the containing block for the p element’s block box is the div element’s block box, as that is the closest ancestor element box that is a block or a list item (in this case, it’s a block box). Similarly, the div’s containing block is the body’s box. Thus, the layout of the p is dependent on the layout of the div, which is in turn dependent on the layout of the body element. And above that, the layout of the body element is dependent on the layout of the html element, whose box creates what is called the initial containing block. It’s unique in that the viewport—the browser window in screen media, or the printable area of the page in print media—determines its dimensions, not the size of the content of the root element. It’s a subtle distinction, and usually not a very important one, but it does exist. Altering Element Display You can affect the way a user agent displays by setting a value for the property display. Now that we’ve taken a close look at visual formatting, let’s consider the display property and discuss two more of its values using concepts from earlier in the book. display Values Definitions Initial value Applies to Computed value Inherited Animatable [ ‖ ] | | | | See below inline All elements As specified No No block | inline | run-in 260 | Chapter 7: Basic Visual Formatting  flow | flow-root | table | flex | grid | ruby list-item && ? && [ flow | flow-root ]? table-row-group | table-header-group | table-footer-group | table-row | table-cell | table-column-group | table-column | table-caption | ruby-base | ruby-text | ruby-base-container | ruby-text-container contents | none inline-block | inline-list-item | inline-table | inline-flex | inline-grid We’ll ignore the ruby- and table-related values, since they’re far too complex for this chapter, and we’ll also ignore the value list-item, since it’s very similar to block boxes. We’ve spent quite some time discussing block and inline boxes, but let’s spend a moment talking about how altering an element’s display role can alter layout before we look at inline-block. Changing Roles When it comes to styling a document, it’s handy to be able to change the type of box an element generates. For example, suppose we have a series of links in a nav that we’d like to lay out as a vertical sidebar:

five">