This chapter is from the book
This chapter is from the book
This chapter is from the book
Background images
The folks over at Yet Another Sports Site are pretty happy with the site, but they’d like to see a visual indication in the header that helps visitors identify which section of the site they’re in.
After 30 seconds of exhausting Photoshop work, we provide them with two silhouettes of footballs as shown in Figure 4.4.
)
Figure 4.4. The header sporting its spiffy new background image.
They’re happy with the way this looks on the large screen, but on anything smaller than the 53.75em breakpoint, where the logo starts to overlap, they’d like the background image to go away.
This is another area where building mobile up is helpful. Let’s consider what would happen if we built the site desktop down using media queries.
Your base styles would be the place to include the background image and you would have to override it in a later media query. It would looked something like this:
1./* base styles */2.header[role="banner"] .inner{3.background: url('../images/football_bg.png') bottom right no-repeat;4.}5.....6.@media all and (max-width: 53.75em) {7.header[role="banner"] .inner {8.background-image: none;9.}10.}
On paper, this seems fine. But in reality, for many browsers, this would result in downloading the image even on a small screen device where it wouldn’t be used. Most notable among these is the default browser on Android 2.x. Remember, while version 4 is current at the time of this writing, about 95 percent of Android devices are running an earlier version. This means that almost all Android traffic on mobile devices would be downloading the image without needing it.
To avoid this penalty, a better method would be to declare the background image within a media query like so:
1./* base styles */2.@media all and (min-width: 53.75em) {3.header[role="banner"] .inner{4.background: url('../images/football_bg.png') bottom right no-repeat;5.}6.}7.....8.@media all and (max-width: 53.75em) {9.header[role="banner"] .inner {10.background-image: none;11.}12.}
Doing that would be enough to get Android to play along nicely.
Since we built the page mobile up, the whole process is much simpler. The base experience doesn’t need the background image, so we can introduce it in a media query later on:
1./* base styles */2.@media all and (min-width: 53.75em) {3.header[role=banner] .inner{4.background: url('../images/football_bg.png') bottom right no-repeat;5.}6.}
Using this approach means that only browsers that need to display the background image will request it—performance problem solved!
Of course, once again, building mobile up means that Internet Explorer 8 and below won’t see this background image by default. However, we already have an IE-specific stylesheet in place thanks to conditional comments. We can just add this declaration in there and we’re good to go.
While we’re at it
Currently, we’re using web fonts to load the ChunkFive font that is being used in the header elements. The style declaration looks like this:
1.@font-face {2.font-family: 'ChunkFiveRegular';3.src: url('Chunkfive-webfont.eot');4.src: url('Chunkfive-webfont.eot?#iefix') format ('embedded-opentype'),5.url('Chunkfive-webfont.woff') format('woff'),6.url('Chunkfive-webfont.ttf') format('truetype'),7.url('Chunkfive-webfont.svg#ChunkFiveRegular') format('svg');8.font-weight: normal;9.font-style: normal;10.}
That declaration works nicely. The browser grabs the file it needs and renders the font. The sizes of the files aren’t even that bad. There’s a downside though. Currently, WebKit-based browsers won’t display text styled with a web font until that web font has been downloaded. This means that if a user comes along on an Android, BlackBerry, or iPhone over a slow connection (or uses a laptop through a tethered connection for that matter), the header elements will take some time to actually display. This is a confusing experience for users and should be avoided.
We can’t determine bandwidth (yet—check out Chapter 9, “Responsive Experiences,” for a preview of what’s to come), but we know the likelihood of a slow network is highest with a mobile device. It would be nice to save the user the trouble and load the fonts for larger screens only.
The approach we used to conditionally load background images works for fonts as well. So, let’s move the @font-face declaration inside of a media query. Doing so ensures that devices below that breakpoint will not attempt to grab the fonts:
1.@media all and (min-width: 37.5em) {2....3.@font-face {4.font-family: 'ChunkFiveRegular';5.src: url('Chunkfive-webfont.eot');6.src: url('Chunkfive-webfont.eot?#iefix') format('embedded-opentype'),7.url('Chunkfive-webfont.woff') format('woff'),8.url('Chunkfive-webfont.ttf') format('truetype'),9.url('Chunkfive-webfont.svg#ChunkFiveRegular') format('svg');10.font-weight: normal;11.font-style: normal;12.}13.}
With that small tweak in place, the web font will load only on screens larger than 37.5em (~600px). While it’s still possible for a user with a slow connection to get stuck with the WebKit delayed loading bug, by removing the fonts from small-screen displays we’ve also removed the most likely victim: people using mobile devices (Figure 4.5).
)
Figure 4.5. Web fonts will no longer be loaded on small screens to improve performance.