- The Base Page
- What are Media Queries?
- Changing the Layout for Large Screens
This chapter is from the book
This chapter is from the book
This chapter is from the book
Changing the Layout for Large Screens
We'll start with the styles for large screens. Download the exercise files for this chapter at www.stunningcss3.com, and open media-queries_start.html in your code editor. Its CSS is contained in a style element in the head of the page.
The design of this example page starts looking a bit stretched out at around 1200 pixels wide, so let's add a media query that will apply only when the window is 1200 or more pixels wide. Add the following CSS after all the existing styles in the style element in the head:
@media screen and (min-width: 1200px) {
}
This media query has to be at the end of the styles so that it will override the earlier styles, using the cascade of CSS. It tells the browser that we want the styles within this media query to apply to screen media types, but only if the user's viewport width is 1200 pixels at a minimum. Of course, right now there are no styles in the media query, just empty brackets waiting to be filled. Since we have so much extra space in viewports over 1200 pixels wide, how about we fill those brackets with styles to change the layout from two columns to three?
To do this, we'll change the positioning of the navigation div, as well as the widths and margins of the two content divs. Here are the current styles of these three divs, outside the media query:
#nav-main {
float: right;
margin: 40px 0 0 0;
}
#content-main {
overflow: hidden;
float: left;
width: 70%;
margin-bottom: 40px;
}
#content-secondary {
float: right;
width: 25%;
margin-bottom: 40px;
}
Modify these styles for viewports over 1200 pixels wide by adding new rules within the media query you just created:
@media screen and (min-width: 1200px) {
#nav-main {
position: fixed;
top: 136px;
width: 13%;
margin: 0;
}
#content-main {
width: 58%;
margin-left: 18%;
}
#content-secondary { width: 20%; }
}
This positions the navigation div under the logo, creating a third column. To make room for it, it was necessary to decrease the width of the content-secondary div from 25 percent to 20 percent, decrease the width of the content-main div from 70 percent to 58 percent, and add a left margin to content-main.
Let's also change the widths of the about and credits divs in the footer to match the widths of the columns above them. Add their IDs onto the #content-main and #content-secondary rules in the media query:
#content-main,#about{ width: 58%; margin-left: 18%; } #content-secondary,#credits{ width: 20%; }
Now all the page elements are better positioned to work well in the width available (Figure 6.3). Save your page, and view it in an up-to-date browser. Resize your window to see how the layout automatically changes when you get past 1200 pixels wide.
)
Figure 6.3 The elements of the page now make better use of the space in wide windows.
Table 6.1. Media queries browser support
|
IE |
Firefox |
Opera |
Safari |
Chrome |
|
Partial, 9+ |
Partial, 3.5+ |
Partial |
Partial |
Partial |
I've listed all of these browsers as having partial support because they don't support all the available media features. The details for each browser are too long and, well, detailed to cover here; however, all listed browsers support most of the media features, including the ones you are most likely to use regularly.
From Horizontal Nav Bar to Vertical Menu
Although everything is now in the place we want it, some of the page elements could use further cosmetic updates. For instance, the li elements in the nav-main div are floated and have left margins in order to align them all horizontally and space them out from each other, but this keeps them from stacking on top of each other, only one to a line, as we want in a vertical menu. They also have slightly rounded top corners, which looks good when they're horizontal, but not when they're sitting right on top of each other. We no longer need these styles now that we're styling the links as a vertical menu, so we'll override them with new styles within the media query:
#nav-main li {
float: none;
margin: 0;
}
#nav-main a {
-moz-border-radius: 0;
-webkit-border-radius: 0;
border-radius: 0;
}
Now each link is on its own line and takes up the full width of the menu (Figure 6.4).
)
Figure 6.4 Each link now takes up the full width of the menu.
Next, let's apply some styling to the menu as a whole to make it look more similar to the email newsletter box on the other side of the page, which has a semitransparent background, slightly rounded corners, and a soft drop shadow:
#nav-main {
position: fixed;
top: 136px;
width: 13%;
margin: 0;
-moz-box-shadow: 0 0 8px hsla(0,0%,0%,.1);
-webkit-box-shadow: 0 0 8px hsla(0,0%,0%,.1);
box-shadow: 0 0 8px hsla(0,0%,0%,.1);
-moz-border-radius: 3px;
-webkit-border-radius: 3px;
border-radius: 3px;
background: hsla(0,0%,100%,.3);
text-align: right;
}
Since the menu has its own background color now, tone down the semitransparent gradients on the links within it, so that the two colors layered over each other don't get too opaque:
#nav-main a {
-moz-border-radius: 0;
-webkit-border-radius: 0;
border-radius: 0;
background: -moz-linear-gradient(hsla(0,0%,100%,.3), hsla(0,0%,100%,0) 15px);
background: -webkit-gradient(linear, 0 0, 0 15, from(hsla(0,0%,100%,.3)), to(hsla(0,0%,100%,0)));
}
#nav-main a:hover {
background: -moz-linear-gradient(hsla(0,0%,100%,.6), hsla(0,0%,100%,.2) 15px);
background: -webkit-gradient(linear, 0 0, 0 15, from(hsla(0,0%,100%,.6)), to(hsla(0,0%,100%,.2)));
}
These changes complete the navigation's transformation from horizontal bar to vertical menu (Figure 6.5).
)
Figure 6.5 The menu in the left column has been restyled to resemble the newsletter subscription box in the right column.
Multi-column Text
One of the main complaints people have with layouts that adjust to viewport width is that the length of lines of text can become either too short or too long to be read comfortably or look attractive. Some of this fear of "non-standard" line lengths is based on assumption and myth. In reality, there is no magic line length that is ideal for everyone; a person's age, reading level, native language, disability, and other factors all influence which line length he finds easiest to read.
However, it's true that line lengths on the extreme ends of the range don't work well for the majority of readers and don't always look very attractive. One way that we can now control line lengths is with the new multi-column properties in CSS3. These properties allow you to flow the content of a single HTML element into multiple columns, similar to a newspaper layout.
You create the columns using either the column-count or column-width properties; in the latter case, the browser will decide how many columns to make based on the available space. (You can also use both properties together, though you may get unexpected results; see "The lowdown on multi-columns" for more information.)
Let's break the introductory paragraph into two columns in both the regular layout and the wide layout. Find the existing h1 + p rule in the styles outside of the media query; it should be on line 102, about a third of the way down the style element. Add the column-count property, plus the three browser-specific versions, to the rule:
h1 + p {
-moz-column-count: 2;
-o-column-count: 2;
-webkit-column-count: 2;
column-count: 2;
color: #7F4627;
text-shadow: -1px -1px 0 hsla(0,0%,100%,.6);
font-size: 120%;
}
Right now, no browser supports the non-prefixed column-count property, and Opera doesn't do anything with the -o-column-count property since it doesn't yet support multi-columns, but it's wise to include both for future compatibility.
The property tells supporting Mozilla- and Webkit-based browsers that you want to break the paragraph into two column-boxes. These column boxes are not actual elements in the document tree of the HTML, rather just virtual boxes that the browser creates to flow the content of the paragraph into. The paragraph is now what the W3C calls a multicol element—it's a container for a multiple-column layout.
You can control the space between the columns using the column-gap property. Set it to 1.5 ems in the h1 + p rule:
h1 + p {
-moz-column-count: 2;
-moz-column-gap: 1.5em;
-o-column-count: 2;
-o-column-gap: 1.5em;
-webkit-column-count: 2;
-webkit-column-gap: 1.5em;
column-count: 2;
column-gap: 1.5em;
color: #7F4627;
text-shadow: -1px -1px 0 hsla(0,0%,100%,.6);
font-size: 120%;
}
If you don't set a column-gap value, each individual browser decides how much space to add by default, so it's best to standardize it by explicitly setting the value you want. Here, we've used a value in ems so that the gap will grow larger as the text grows larger, keeping the text more readable.
Now the introductory paragraph is broken into two columns in both the regular layout and the wide layout created with the media query (Figure 6.6). This completes all the styling for the wide version of the bakery page (Figure 6.7).
)
Figure 6.6 The text of the introductory paragraph flows into two columns in Firefox, Safari, and Chrome.
)
Figure 6.7 The completed design for wide viewports
Problems with multi-columns
Although CSS3 multi-columns work well for the introductory paragraph in our bakery page, there are a number of problems with them that limit their usefulness, which you should be aware of before you use the feature. Some of these problems are technical in nature, so as the W3C refines the specification and browsers fix bugs and improve support, they should disappear or at least lessen. These problems include:
- Balancing column heights. If there's not enough content to fill each column equally, the browser has to decide which column gets the extra height. Different browsers choose differently, with sometimes unexpected results.
- Flowing margin, padding, and borders across columns. Webkit-based browsers allow margin, padding, and borders to be split across columns, creating a very strange appearance.
- Breaking content across columns. Being able to control where content breaks across columns is important, as you want to be able to ensure that a heading stays with its associated text, for instance. The column-break properties control this, but no browser supports them now.
- Overflowing columns or content. Browsers are currently inconsistent about how to handle overflow when not all of the content or columns can fit in the container (the multicol element); it may overflow to the right or below, or just be truncated. An individual piece of content that is too large to fit in a column box, such as an image that is wider than the column width, is supposed to be cut off in the middle of the column gap, but Firefox lets it overflow and Webkit cuts it off at the edge of the column, not within the gutter as the spec dictates.
- Floating content within columns. Floats within a multicol element are supposed to be positioned relative to the column box in which they appear. Firefox does this; Webkit, strangely, puts the float outside of the multicol element entirely.
- Pagination when printed. When a multicol element has to break across two or more pages when printed, the columns are not supposed to break across the pages. The content should run through the columns on the first page, then run through the columns on the second page, and so on. Older versions of Webkit-based browsers didn't follow this; current versions simply make the content go back to a single column when printed, avoiding the issue entirely.
But some problems with multi-columns are more inherent to the idea of columns on the web to begin with. Having to scroll down to read a column and then back up to read the next column, over and over again, is just plain annoying and tiresome. This isn't a technical problem—it's a usability problem with breaking up content that's taller than a constrained screen. Treating the web like print often doesn't work well. For more on the usability and design problems inherent to CSS3 multi-columns, see "Multicolumn layout considered harmful" by Roger Johanssen (www.456bereastreet.com/archive/200509/css3_multicolumn_layout_considered_harmful), "More on multi-column layouts" by Richard Rutter (www.clagnut.com/blog/1590), and "CSS3 Multi-Column Thriller" by Andy Clarke (www.stuffandnonsense.co.uk/archives/css3_multi-column_thriller.html).
Because of all of these problems, I strongly recommend only using multiple columns in a limited manner. I think they're fine for a couple paragraphs or a list, for instance. I don't think they work very well for long blocks of body copy or content that is complex, with several paragraphs, types of elements, or images within it. Just keep this in mind, and use multi-columns wisely.
Workarounds for Non-supporting Browsers
Multi-columns are a quintessential progressive enhancement technique, since browsers that don't support the multi-column properties simply see the text as it started out—in one column.
If you must provide a workaround for non-supporting browsers, there are several scripts that can flow content into multiple columns. The CSS3 Multi Column script by Cédric Savarese (www.csscripting.com/css-multi-column) is a nice one because it reads the multi-column properties already in your CSS and makes them work in non-supporting browsers. You may also want to check out:
- Columnizer jQuery plugin, by Adam Wulf (http://welcome.totheinter.net/columnizer-jquery-plugin)
- MooColumns MooTools class, by Jason J. Jaeger (http://greengeckodesign.com/moocolumns)
- Multi-column script, by Randy Simons (http://randysimons.nl/125,english/129,multi-column-text)
- Column script, by Michael van Ouwerkerk (http://13thparallel.com/archive/column-script)
Table 6.2. Multi-columns browser support
|
IE |
Firefox |
Opera |
Safari |
Chrome |
|
No |
Partial |
No |
Partial |
Partial |