- The Answer I'm Sticking to
- Rewarding vs. "This Is Broken"
- Decision Makers Who Get It
From the book
Decision Makers Who Get It
Accepting that a design might look slightly different depending on the browser isn’t going to sit well with everyone. And if the decision maker of the group isn’t on board, it makes the idea of progressive enrichment a tough sell. But that doesn’t mean we shouldn’t talk about it.
For example, convincing decision makers that it’s far more flexible and efficient to implement rounded corners with CSS3 might be a tough road, depending on the team involved.
Take for instance, Twitter (http://twitter.com), a popular social messaging application that allows people to send short status updates via the Web or text messages.
If you compare my own Twitter homepage in two recent browsers, you’ll notice the top navigation and main content container are rounded in Safari (Figure 4.4), while those same page elements are square boxes in IE8 (Figure 4.5).
)
Figure 4.4 Twitter viewed in Safari, where -webkit-border-radius rounds the corners of various page elements.
)
Figure 4.5 Twitter viewed in IE8, where the absence of rounded corners degrades perfectly fine to square boxes around the top navigation and main content area.
Twitter is using the border-radius properties we discussed in Chapter 2 to handle the rounding here, and the decision makers are okay with things looking slightly different between browsers.
It makes good sense to use CSS3 to handle the rounded corners in Twitter’s case, as the background color and the image (a screenshot of the classic video game Pitfall, in my case) as well as the background color of the sidebar are all customizable by the user. Using CSS3 to round the corners made this flexibility possible without the use of extra markup or scripting. Speed and bandwidth are of the essence for Twitter, and the rounded corners in Mozilla- and WebKit-based browsers are visual rewards rather than necessary requirements.
All of this is okay since the absence of rounded corners doesn’t hinder the layout, readability, and functionality of the site.
Easier when You are the Decision Maker
All of these forward-thinking solutions are far easier when it’s you who is the decision maker. In other words, for your own projects, or if you happen to be lucky enough to be the one calling the shots when it comes to design implementation, the concept of progressive enrichment becomes more and more like an attractive path. And addictive.
For example, I created a ridiculously useless site called Foamee (http://foamee.com), which suggested syntax for sending beer and coffee IOUs via Twitter (Figure 4.6). The title of each page has decorative ornaments that sit flush against the text on the left and right of the text.
)
Now, I could’ve added extraneous markup, and used some CSS trickery to center align the text, yet keep the ornaments snug against either side of the text no matter its length (something that really should be simple to implement yet isn’t cross-browser)—but instead I chose to use generated content with CSS to simplify things drastically while maintaining flexibility.
I could keep the markup extra simple, using just an <h1> element:
<h1>simplebits</h1>
And I could use the :before and :after pseudo-elements to insert the ornament images just to the left and just to the right of the text:
h1:before {
content: url(../img/ornament-left.gif);
}
h1:after {
content: url(../img/ornament-right.gif);
}
Figure 4.7 shows how this will look in browsers that support the :before and :after pseudo-elements, with the ornament images properly sitting snugly around the <h1>. IE6 and 7 don’t support generated content, however, and thus ignore those declarations entirely. This is likely why we haven’t seen widespread use of these handy CSS solutions.
)
Figure 4.8 shows how they would display the title, where the ornaments don’t appear (as in IE6 or IE7). This is okay! And since I was the decision maker here, it was an easy trade-off. The title is still there, it’s readable and styled the same, and the absence of the ornaments is the only differing issue. And I’ve managed to keep the markup and styles simple, flexible, and bulletproof.
)
Golf clap for Internet Explorer 8
The additional good news here, is that IE8 does support the :before and :after pseudo-elements, further supporting the use of these CSS solutions going forward. If you can live with IE6 and IE7 looking slightly different, then it might be time to reevaluate the use of these previously unsupported selectors from here on.
This is part of the “reevaluating of past methods” I referred to in the Introduction. We’ve grown accustomed to avoiding certain CSS selectors and properties because they weren’t supported in whatever the current crop of browsers was at the time. It’s always a good idea to check now and again if that support has changed.
For example, :before and :after pseudo-selectors have long been unsupported in Internet Explorer, but since that’s no longer true with IE8, we can take that into consideration when choosing solutions. Is your current problem better handled with a few simple CSS rules for the latest browsers, letting older versions of IE show less ornamentation? Most of the time, I’d likely answer, “yes.”
Not only accepting, but embracing browser deficiencies
Designer and author Andy Clarke takes a drastic and somewhat humorous approach in visually distinguishing IE6 from other browsers. Figure 4.9 shows his beautiful website viewed in both Safari (on the left) and IE6 (on the right). Andy is serving an alternate black-and-white version of his website to IE6 users, encouraging them to upgrade in order to get the full-color experience.
)
This not only answers the question “Do websites need to look exactly the same in every browser?” but it also embraces that difference intentionally. Would this work for every situation? No. But there is something that can help you decide how far to take things: statistics.