Media feature descriptors

So far we’ve seen a number of media feature descriptors in the examples, but not a complete list of the possible descriptors and their values. Let us fix that now!

Note that none of the following values can be negative, and remember that feature descriptors are always enclosed in parentheses.

Descriptors: width, min-width, max-width

Values: <length>

Refers to the width of the display area of the user agent. In a screen-media web browser, this is the width of the viewport plus any scrollbars. In paged media, this is the width of the page box, which is the area of the page in which content is rendered. Thus, (min-width: 850px) applies when the viewport is greater than or equal to 850 pixels wide.

Descriptors: height, min-height, max-height

Values: <length>

Refers to the height of the display area of the user agent. In a screen-media web browser, this is the height of the viewport plus any scrollbars. In paged media, this is the height of the page box. Thus, (height: 567px) applies when the viewport’s height is precisely 567 pixels tall.

Descriptors: device-width, min-device-width, max-device-width

Values: <length>

Refers to the width of the complete rendering area of the output device. In screen media, this is the width of the screen; i.e., a handheld device screen’s or desktop monitor’s horizontal measurement. In paged media, this is the width of the page itself. Thus, (max-device-width: 1200px) applies when the device’s output area is less or equal to than 1,200 pixels wide.

Descriptors: device-height, min-device-height, max-device-height

Values: <length>

Refers to the height of the complete rendering area of the output device. In screen media, this is the height of the screen; i.e., a handheld device screen’s or desktop monitor’s vertical measurement. In paged media, this is the height of the page itself. Thus, (max-device-height: 400px) applies when the device’s output area is less than or equal to 400 pixels tall.

Descriptors: aspect-ratio, min-aspect-ratio, max-aspect-ratio

Values: <ratio>

Refers to the ratio that results from comparing the width media feature to the height media feature (see the definition of <ratio> in the next section). Thus, (min-aspect-ratio: 2/1) applies to any viewport whose width-to-height ratio is at least 2:1.

Descriptors: device-aspect-ratio, min-device-aspect-ratio, max-device-aspect-ratio

Values: <ratio>

Refers to the ratio that results from comparing the device-width media feature to the device-height media feature (see the definition of <ratio> in the next section). Thus, (device-aspect-ratio: 16/9) applies to any output device whose display area width-to-height is exactly 16:9.

Descriptors: color, min-color, max-color

Values: <integer>

Refers to the presence of color-display capability in the output device, with an optional number value representing the number of bits used in each color components. Thus, (color) applies to any device with any color depth at all, whereas (min-color: 4) means there must be at least four bits used per color component. Any device that does not support color will return 0.

Descriptors: color-index, min-color-index, max-color-index

Values: <integer>

Refers to the total number of colors available in the output device’s color lookup table. Any device that does not use a color lookup table will return 0. Thus, (min-color-index: 256) applies to any device with a minimum of 256 colors available.

Descriptors: monochrome, min-monochrome, max-monochrome

Values: <integer>

Refers to the presence of a monochrome display, with an optional number of bits-per-pixel in the output device’s frame buffer. Any device that is not monochrome will return 0. Thus, (monochrome) applies to any monochrome output device, whereas (min-monochrome: 2) means any monochrome output device with a minimum of 2 bits per pixel in the frame buffer.

Descriptors: resolution, min-resolution, max-resolution

Values: <resolution>

Refers to the resolution of the output device in terms of pixel density, measured in either dots per inch (dpi) or dots per centimeter (dpcm); see the definition of <resolution> in the next section for details. If an output device has pixels that are not square, then the least dense axis is used; for example, if a device is 100 dpcm along one axis and 120 dpcm along the other, then 100 is the value returned. Additionally, in such non-square cases, a bare resolution feature query—that is, one without a value—can never match (though min-resolution and max-resolution can). Note that resolution values must not only be non-negative, but also nonzero.

Descriptors: orientation

Values: portrait | landscape

Refers to the orientation of the user agent’s display area, where portrait is returned if the media feature height is equal to or greater than the media feature width. Otherwise, the result is landscape.

Descriptor: scan

Values: progressive | interlace

Refers to the scanning process used in an output device. interlace is the type generally used in CRT and some plasma displays. progressive is more common, being the type of scanning used in most modern displays.

Descriptor: grid

Values: 0 | 1

Refers to the presence (or absence) of a grid-based output device, such as a TTY terminal. A grid-based device will return 1; otherwise, 0 is returned. This feature descriptor can be used in place of the old tty media descriptor.

New value types

There are two new value types introduced by media queries, and which (as of early 2017) are not used in any other context. These types are used in conjunction with specific media features, which are explained in the previous sections:

<ratio>

A ratio value is two positive <integer> values separated by a solidus (/) and optional whitespace. The first value refers to the width, and the second to the height. Thus, to express a height-to-width ratio of 16:9, you can write 16/9 or 16 / 9. As of this writing, there is no facility to express a ratio as a single real number, nor to use a colon separator instead of a solidus.

<resolution>

A resolution value is a positive <integer> followed by either of the unit identifiers dpi or dpcm. In CSS terms, a “dot” is any display unit, the most familiar of which is the pixel. As usual, whitespace is not permitted between the <integer> and the identifier. Therefore, a display whose display has exactly 150 pixels (dots) per inch is matched with 150dpi.

Responsive styling

Media queries are, at least as of early 2017, the foundation on which the practice of responsive web design is built. By applying different sets of rules depending on the display environment, it’s possible to marry mobile-friendly and desktop-friendly styles into a single style sheet.

Those terms were put in quote because, as you may have seen in your own life, the lines between what’s mobile and what’s desktop are blurred. A laptop with a touch-sensitive screen that folds all the way back can act as both a tablet and a laptop, for example. CSS doesn’t (yet) have a way of detecting whether or not a hinge is open past a certain point, nor whether the device is held in hand or sitting on a flat surface. Instead, inferences are drawn from aspects of the media environment, like display size or display orientation.

A fairly common pattern in responsive design is to define breakpoints for each @media block. This often takes the form of certain pixel widths, like this:

/* …common styles here… */
@media (max-width: 400px) {
    /* …small-screen styles here… */
}
@media (min-width: 401px) and (max-width: 1000px) {
    /* …medium-screen styles here… */
}
@media (min-width: 1001px) {
    /* …big-screen styles here… */
}

This is often sufficient. It does make certain assumptions about what a device can display and how it will report that, however. For example, the iPhone 6 Plus had a resolution of 1,242 × 2,208, which it downsampled to 1,080 × 1,920. Even at the downsampled resolution, that’s enough pixels across to qualify for big-screen styles in the previous example.

But wait! The iPhone 6 Plus also maintained an internal coordinate system of points which measured 414 × 736. If it decided to use those as its definition of pixels, which would be entirely valid, then it would only get the small-screen styles.

The point here isn’t to single out the iPhone 6 Plus as uniquely bad, which it wasn’t, but to illustrate the uncertainties of relying on pixel-based media queries. Browser makers have gone to some effort to make their browsers behave with some semblance of sanity, but never quite as much as we’d like, and you never know when a new device’s assumptions will clash with your own.

There are other methods available, though they come with their own uncertainties. Instead of pixels, you might try em-based measures, something like this:

/* …common styles here… */
@media (max-width: 20em) {
    /* …small-screen styles here… */
}
@media (min-width: 20.01em) and (max-width: 50em) {
    /* …medium-screen styles here… */
}
@media (min-width: 50.01em) {
    /* …big-screen styles here… */
}

This ties the breakpoints to text display size rather than pixels, which is somewhat more robust. This isn’t perfect either, though: it relies on a sensible approach to determining the em width of, say, a smartphone. It also directly relies on the actual font family and size used by the device, which varies from one device to another.

Here’s another seemingly simple query set with potentially surprising results:

/* …common styles here… */
@media (orientation: landscape) {
    /* …wider-than-taller styles here… */
}
@media (orientation: portrait) {
    /* …taller-than-wider styles here… */
}

This feels like a good way to tell if a smartphone is in use: after all, most of them are taller than they are wide, and most people don’t turn them sideways to read. The wrinkle is that the orientation feature refers to the height and width descriptors; that is, orientation is portrait is height is equal to or larger than width. Not device-height and device-width, but height and width, which refer to the display area of the user agent.

That means a desktop browser window whose display area (the part inside the browser Chrome) is taller than it is wide, or even perfectly square, will get the portrait styles. So if you assume “portrait equals smartphone,” some of your desktop users could get a surprise.

The basic point here is: responsive styling is powerful, and like any powerful tool, it requires a fair amount of thought and care in its use. Carefully considering the implications of each combination of feature queries is the minimum requirement for successful responsiveness.

Differences between screen and print

Beyond the obvious physical differences, there are a number of stylistic differences between screen and print design. The most basic involves font choices. Most designers will tell you that sans-serif fonts are best suited for screen design, but serif fonts are more readable in print. Thus, you might set up a print style sheet that uses Times instead of Verdana for the text in your document.

Another major difference involves font sizing. If you’ve spent any time at all doing web design, you’ve probably heard again and again (and again) that points are a horrible choice for font sizing on the web. This is basically true, especially if you want your text to be consistently sized between browsers and operating systems. However, print design is not web design any more than web design is print design. Using points, or even centimeters or picas, is perfectly OK in print design because printing devices know the physical size of their output area. If a printer has been loaded with 8.5 × 11 inch paper, then it knows it has a printing area that will fit within the edges of a piece of paper. It also knows how many dots there are in an inch, since it knows the dpi it’s capable of generating. This means that it can cope with physical-world length units like points.

Many a print style sheet has started with:

body {font: 12pt "Times New Roman", "TimesNR", Times, serif;}

It’s so traditional, it just might bring a tear of joy to the eye of a graphic artist reading over your shoulder. But make sure they understand that points are acceptable only because of the nature of the print medium—they’re still not good for web design.

Alternatively, the lack of backgrounds in most printouts might bring a tear of frustration to that designer’s eye. In order to save users ink, most web browsers are pre-configured not to print background colors and images. If the user wants to see those backgrounds in the printout, they have to change an option somewhere in the preferences.

CSS can’t do anything to force the printing of backgrounds. However, you can use a print style sheet to make backgrounds unnecessary. For example, you might include this rule in your print style sheet:

* {color: black !important; background: transparent !important;}

This will do its utmost to ensure all of your elements print out as black text and remove any backgrounds you might have assigned in an all-medium style sheet. It also makes sure that if you have a web design that puts yellow text on a dark gray background, a user with a color printer won’t get yellow text on a white piece of paper.

One other difference between paged media and continuous media is that multicolumn layouts are even harder to use in paged media. Suppose you have an article where the text has been formatted as two columns. In a printout, the left side of each page will contain the first column, and the right side the second. This would force the user to read the left side of every page, then go back to the beginning of the printout and read the right side of every page. This is annoying enough on the web, but on paper it’s much worse.

One solution is to use CSS for laying out your two columns (by floating them, perhaps) and then writing a print style sheet that restores the content to a single column. Thus, you might write something like this for the screen style sheet:

div#leftcol {float: left; width: 45%;}
div#rightcol {float: right; width: 45%;}

Then in your print style sheet, you would write:

div#leftcol, div#rightcol {float: none; width: auto;}

Alternatively, in user agents that support it, you might define actual multicolumn layout for both screen and print, and trust the user agents to do the right thing.

We could spend an entire chapter on the details of print design, but that really isn’t the purpose of this book. Let’s start exploring the details of paged-media CSS and leave the design discussions for another book.

Defining the page size

In much the same way as it defines the element box, CSS2 defines a page box that describes the components of a page. A page box is composed of basically two regions:

• The page area, which is the portion of the page where the content is laid out. This is roughly analogous to the content area of a normal element box, to the extent that the edges of the page area act as the initial containing block for layout within a page.

• The margin area, which surrounds the page area.

The page box model is illustrated in Figure 20-2.

Figure 20-2. The page box

The @page block is the method by which settings are made, and the size property is used to define the actual dimensions of the page box. Here’s a simple example:

@page {size: 7.5in 10in; margin: 0.5in;}

@page is a block like @media is a block, and within it can contain any set of styles. One of them, size, only makes sense in the context of an @page block.

This property is used to define the size of the page area. The value landscape is meant to cause the layout to be rotated 90 degrees, whereas portrait is the normal orientation for Western-language printing. Thus, an author could cause a document to be printed sideways by declaring the following, with the result shown in Figure 20-3:

@page {size: landscape;}

Figure 20-3. Landscape page sizing

In addition to landscape and portrait, there are a number of predefined page-size keywords available. These are summarized in Table 20-1.

Any one of the keywords can be used to declare a page size. The following defines a page to be JIS B5 size:

@page {size: JIS-B5;}

These keywords can be combined with the landscape and portrait keywords; thus, to define landscape-oriented North American legal pages, the following is used:

@page {size: landscape legal;}

Besides using keywords, it’s also possible to define page sizes using length units. In such cases, the width is given first, and then the height. Therefore, the following defines a page area 8 inches wide by 10 inches tall:

@page {size: 8in 10in;}

The defined area is usually centered within the physical page, with equal amounts of whitespace on each side. If the defined size is larger than the printable area of the page, then the user agent has to decide what to do to resolve the situation. There is no defined behavior here, so it’s really dealer’s choice.

Page margins and padding

Related to size, CSS includes the ability to style the margin area of the page box. If you want to make sure that only a small bit at the center of every 8.5 × 11 inch page is used to print, you could write:

@page {margin: 3.75in;}

This would leave a printing area 1 inch wide by 3.5 inches tall.

It is possible to use the length units em and ex to describe either the margin area or the page area, at least in theory. The size used is taken from the page context’s font, which is to say, the base font size used for the content displayed on the page.

Selecting page types

CSS2 offers the ability to create different page types using named @page rules. Let’s say you have a document on astronomy that is several pages long, and in the middle of it, there is a fairly wide table containing a list of the physical characteristics of all the moons of Saturn. You want to print out the text in portrait mode, but the table needs to be landscape. Here’s how you’d start:

@page normal {size: portrait; margin: 1in;}
@page rotate {size: landscape; margin: 0.5in;}

Now you just need to apply these page types as needed. The table of Saturn’s moons has an id of moon-data, so you write the following rules:

body {page: normal;}
table#moon-data {page: rotate;}

This causes the table to be printed landscape, but the rest of the document to be in portrait orientation. The property page is what makes this possible.

As you can see from looking at the value definition, the whole reason page exists is to let you assign named page types to various elements in your document.

There are more generic page types that you can address through special pseudo-classes. :first lets you apply special styles to the first page in the document. For example, you might want to give the first page a larger top margin than other pages. Here’s how:

@page {margin: 3cm;}
@page :first {margin-top: 6cm;}

This will yield a 3 cm margin on all pages, with the exception of a 6 cm top margin on the first page.

In addition to styling the first page, you can also style left and right pages, emulating the pages to the left and right of a book’s spine. You can style these differently using :left and :right. For example:

@page :left {margin-left: 3cm; margin-right: 5cm;}
@page :right {margin-left: 5cm; margin-right: 3cm;}

These rules will have the effect of putting larger margins between the content of the left and right pages, on the sides where the spine of a book would be. This is a common practice when pages are to be bound together into a book of some type.

Page-breaking

In a paged medium, it’s a good idea to exert some influence over how page breaks are placed. You can affect page breaking using the properties page-break-before and page-break-after, both of which accept the same set of values.

The default value of auto means that a page break is not forced to come before or after an element. This is the same as any normal printout. always causes a page break to be placed before (or after) the styled element.

For example, assume a situation where the page title is an h1 element, and the section titles are all h2 elements. We might want a page break right before the beginning of each section of a document and after the document title. This would result in the following rules, illustrated in Figure 20-4:

h1 {page-break-after: always;}
h2 {page-break-before: always;}

Figure 20-4. Inserting page breaks

If you want the document title to be centered in its page, then we’d add rules to that effect. Since we don’t, we just get a very straightforward rendering of each page.

The values left and right operate in the same manner as always except they further define the type of page on which printing can resume. Consider the following:

h2 {page-break-before: left;}

This will force every h2 element to be preceded by enough page breaks so that the h2 will be printed at the top of a left page—that is, a page surface that would appear to the left of a spine if the output were bound. In double-sided printing, this would mean printing on the back of a piece of paper.

So let’s assume that, in printing, the element just before an h2 is printed on a right page. The previous rule would cause a single page break to be inserted before the h2, thus pushing it to the next page. If the next h2 is preceded by an element on a left page, however, the h2 would be preceded by two page breaks, thus placing it at the top of the next left page. The right page between the two would be intentionally left blank. The value right has the same basic effect, except it forces an element to be printed at the top of a right page preceded by either one or two page breaks.

The companion to always is avoid, which directs the user agent to do its best to avoid placing a page break either before or after an element. To extend the previous example, suppose you have subsections whose titles are h3 elements. You want to keep these titles together with the text that follows them, so you want to avoid a page break following an h3 whenever possible:

h3 {page-break-after: avoid;}

Note, though, that the value is called avoid, not never. There is no way to absolutely guarantee that a page break will never be inserted before or after a given element. Consider the following:

img {height: 9.5in; width: 8in; page-break-before: avoid;}
h4 {page-break-after: avoid;}
h4 + img {height: 10.5in;}

Now, suppose further that you have a situation where an h4 is placed between two images, and its height calculates to be half an inch. Each image will have to be printed on a separate page, but there are only two places the h4 can go: at the bottom of the page holding the first element, or on the page after it. If it’s placed after the first image, then it has to be followed by a page break, since there’s no room for the second image to follow it.

On the other hand, if the h4 is placed on a new page following the first image, then there won’t be room on that same page for the second image. So, again, there will be a page break after the h4. And, in either case, at least one image, if not both, will be preceded by a page break. There’s only so much the user agent can do, given a situation like this one.

Situations such as these are rare, but they can happen—for example, in a case where a document contains nothing but tables preceded by headings. There may be cases where tables print in such a way that they force a heading element to be followed by a page break, even though the author requested such break placement be avoided.

The same sorts of issues can arise with the other page-break property, page-break-inside. Its possible values are more limited than those of its cousins.

With page-break-inside, you pretty much have one option other than the default: you can request that a user agent try to avoid placing page breaks within an element. If you have a series of aside divisions, and you don’t want them broken across two pages, you could declare:

div.aside {page-break-inside: avoid;}

Again, this is a suggestion more than an actual rule. If an aside turns out to be longer than a page, the user agent can’t help but place a page break inside the element.

Orphans and widows

In an effort to provide finer influence over page-breaking, CSS2 defines two properties common to both traditional print typography and desktop publishing: widows and orphans.

These properties have similar aims but approach them from different angles. The value of widows defines the minimum number of line boxes found in an element that can be placed at the top of a page without forcing a page break to come before the element. orphans has the same effect in reverse: it gives the minimum number of line boxes that can appear at the bottom of a page without forcing a page break before the element.

Let’s take widows as an example. Suppose you declare:

p {widows: 4;}

This means that any paragraph can have no fewer than four line boxes appear at the top of a page. If the layout of the document would lead to fewer line boxes, then the entire paragraph is placed at the top of the page. Consider the situation shown in Figure 20-5. Cover up the top part of the figure with your hand so that only the second page is visible. Notice that there are two line boxes there, from the end of a paragraph that started on the previous page. Given the default widows value of 2, this is an acceptable rendering. However, if the value were 3 or higher, the entire paragraph would appear at the top of the second page as a single block. This would require that a page break be inserted before the paragraph in question.

Figure 20-5. Counting the widows and orphans

Refer back to Figure 20-5, and this time cover up the second page with your hand. Notice the four line boxes at the bottom of the page, at the beginning of the last paragraph. This is fine as long as the value of orphans is 4 or less. If it were 5 or higher, then the paragraph would again be preceded by a page break and be laid out as a single block at the top of the second page.

One potential pitfall is that both orphans and widows must be satisfied. If an author declared the following, then most paragraphs would be without an interior page break:

p {widows: 30; orphans: 30;}

It would take a pretty lengthy paragraph to allow an interior page break, given those values. If the intent is to prevent interior breaking, then that intent would be better expressed as:

p {page-break-inside: avoid;}

Page-breaking behavior

Because CSS2 allows for some odd page-breaking styles, it defines a set of behaviors regarding allowed page breaks and “best” page breaks. These behaviors serve to guide user agents in how they should handle page-breaking in various circumstances.

There are really only two generic places where page breaks are permitted. The first of these is between two block-level boxes. If a page break falls between two block boxes, then the margin-bottom value of the element before the page break is reset to 0, as is the margin-top of the element following the page break. However, there are two rules that affect whether a page break can fall between two element boxes:

If the value of page-break-after for the first element—or the value of page-break-before for the second element—is always, left, or right, then a page break will be placed between the elements. This is true regardless of the value for the other element, even if it’s avoid. (This is a forced page break.)

If the value of the first element’s page-break-after value is auto, and the same is true for the second element’s page-break-before value, and they do not share an ancestor element whose page-break-inside value is not avoid, then a page break may be placed between them.

Figure 20-6 illustrates all the possible page-break placements between elements in a hypothetical document. Forced page breaks are represented as a filled square, whereas potential (unforced) page breaks are shown as an open square.

Second, page breaks are allowed between two line boxes inside a block-level box. This, too, is governed by a pair of rules:

• A page break may appear between two line boxes only if the number of line boxes between the start of the element and the line box before the page break would be less than the value of orphans for the element. Similarly, a page break can be placed only where the number of line boxes between the line box after the page break and the end of the element is less than the value of widows.

• A page break can be placed between line boxes if the value of page-break-inside for the element is not avoid.

Figure 20-6. Potential page-break placement between block boxes

In both cases, the second of the two rules controlling page-break placement is ignored if no page-break placement can satisfy all the rules. Thus, given a situation where an element has been given page-break-inside: avoid but the element is longer than a full page, a page break will be permitted inside the element, between two line boxes. In other words, the second rule regarding page-break placement between line boxes is ignored.

If ignoring the second rule in each pair of rules still does not yield good page-break placement, then other rules can also be ignored. In such a situation, the user agent is likely to ignore all page-break property values and proceed as if they were all auto, although this approach is not defined (or required) by the CSS specification.

In addition to the previously explored rules, CSS2 defines a set of best page-breaking behaviors:

• Break as few times as possible.

• Make all pages that don’t end with a forced break appear to have about the same height.

• Avoid breaking inside a block that has a border.

• Avoid breaking inside a table.

• Avoid breaking inside a floated element.

These recommendations aren’t required of user agents, but they offer logical guidance that should lead to ideal page-breaking behaviors.

Repeated elements

A very common desire in paged media is the ability to have a running head. This is an element that appears on every page, such as the document’s title or the author’s name. This is possible in CSS2 by using a fixed-position element:

div#runhead {position: fixed; top: 0; right: 0;}

This will place any div with an id of runhead at the top-right corner of every page box when the document is output to a paged medium. The same rule would place the element in the top-right corner of the viewport in a continuous medium, such as a web browser. Any element positioned in this way will appear on every page. It is not possible to copy an element to become a repeated element. Thus, given the following, the h1 element will appear as a running head on every page including the first one:

h1 {position: fixed; top: 0; width: 100%; text-align: center;
    font-size: 80%; border-bottom: 1px solid gray;}

The drawback is that the h1 element, being positioned on the first page, cannot be printed as anything except the running head.

Elements outside the page

All this talk of positioning elements in a paged medium leads to an interesting question: what happens if an element is positioned outside the page box? You don’t even need positioning to create such a situation. Think about a pre element that contains a line with 411 characters. This is likely to be wider than any standard piece of paper, and so the element will be wider than the page box. What will happen then?

As it turns out, CSS2 doesn’t say exactly what user agents should do, so it’s up to each to come up with a solution. For a very wide pre element, the user agent might clip the element to the page box and throw away the rest of the content. It could also generate extra pages to display the leftover part of the element.

There are a few general recommendations for handling content outside the page box, and two that are really important. First, content should be allowed to protrude slightly from a page box in order to allow bleeding. This implies that no extra page would be generated for the portions of such content that exceed the page box, but do not extend all the way off the page.

Second, user agents are cautioned not to generate large numbers of empty pages for the sole purpose of honoring positioning information. Consider:

h1 {position: absolute; top: 1500in;}

Assuming that the page boxes are 10 inches high, the user agent would have to precede an h1 with 150 page breaks (and thus 150 blank pages) just to honor that rule. Instead, a user agent might choose to skip the blank pages and just output the last one, which actually contains the h1 element.

The other two recommendations state that user agents should not position elements in strange places just to avoid rendering them, and that content placed outside a page box can be rendered in any of a number of ways. (Some of the commentary in CSS is useful and intriguing, but some seems to exist solely to cheerily state the obvious.)