Five CSS design browser differences I can live with

Five CSS design browser differences I can live with

Web designs need not look exactly the same in all browsers. I know that’s a topic I have written about and spoken on a fair amount before, but somehow I’m always amazed by the reactions that I get when the subject comes up.

Although this idea isn't new (and just for the record I know I didn't invent it), when I teach my design philosophy at workshops and conferences I'm often surprised to hear that the notion that people using different browsers (even up-to-date ones) might intentionally see differences in visual design sounds new.

The belief that all browsers should see the same design often requires us to resort to presentational markup, forked CSS and JavaScript DOM wizardry. It may come from:

Thinking about alternatives

Please allow me to clear up a common misconception. When I talk about designs not looking exactly the same in all browsers I am not talking about making bad designs for people using older or abandoned software. I would never accept that. Or that a design should look poor or broken. Or that a person could be denied access to content or services if they are using a less capable browser. What I am talking about is creating a visual design that looks best to people who are using modern software and at the same time thinking carefully about what a person using less capable software will see. This approach is simply based around thinking about alternatives. It's little different to the way that I hope we have been taught to think about web accessibility.

You might be thinking that it's strange for me as a visual designer first, that I would promote an approach where some people see a lesser design that others. But I'm also a pragmatist and I know that in my business, I would rather ask my clients to spend their money wisely on things that will improve their business, than to waste it on hours of unnecessary development.

Not everyone will agree with this approach and of course if you do agree, how far you take it will depend on several factors and your own circumstances. I have my limits too. So here are five examples of CSS design differences that I can live with and do live with every day.

Demonstration file

Before reading on, take a look at a Demonstration XHTML/CSS design file from one of my recent projects. I hope you think it looks great. I hope you find that nothing looks broken or out of place. I hope that you think that if you were reading this page, that you would find everything just where you need it to be, no matter what browser you are using. (As this project is not yet live I have removed the client's branding and content. Copyright: This design is not a template and must not be reused.)

CSS pseudo elements

I love to play with typography and CSS pseudo-elements offer far greater control over type without requiring unnecessary, presentational markup. For this design, I want to style the first line of the first paragraph following a heading in the main content areas in small-caps, while at the same time increasing the font-caps and letter-spacing to draw a reader's attention to that area of content.


.content-main h2 + p:first-line { 
font-variant : small-caps; 
font-size : 1.5em; 
letter-spacing : 1px; 
}

CSS :first-line in various browsers Current browsers (left) Internet Explorer 6 (right)

People using Internet Explorer 6 will see a regular first line. I can live with that. Using the first-child, I also sometimes like to add visual emphasis to the first paragraph of text in a given area, for example the first paragraph in the secondary content area of the demonstration file should be bold.


.content-sub p:first-child { 
font-weight : bold; 
}

All major browsers have now implemented first-child and people using Internet Explorer 6 will see a normal paragraph. I can live with that. It's hardly a reason to avoid using first-child.

Adjacent selectors

In the same vein, in my designs I often like to visually emphasize and separate the first, often most important, paragraphs of text that follow a heading. It's a simple device, but I find it improves readability and scalability enormously. Using the + combinator in an adjacent selector, I style specific paragraphs without needing unnecessary class or id attributes. Of course people using Internet Explorer 6 will again see a normal paragraph, but guess what? I can live with that.


.content-main h2 + p { 
margin-bottom : 20px; 
padding-bottom : 20px; 
border-bottom : 1px solid #bfbfbf; 
}

Adjacent selectors Current browsers (left) Internet Explorer 6 (right)

Border-radius

Unless rounded corners are an integral part of a design and not simply a visual flourish, it makes sense to avoid unnecessary markup (directly in the document or inserted by DOM scripting) and to use border-radius instead. Opera and Internet Explorer will see square corners instead of round ones, but I can live with that.


#nav-sub { 
border-radius : 10px; 
-moz-border-radius : 10px; /* Mozilla */
-webkit-border-radius : 10px; /* Webkit */
}

Border-radius Firefox & Webkit (left) Internet Explorer 7 & Opera (right)

Attribute selectors

If you love to add those tiny icons to links, perhaps an external link icon, a PDF icon or possibly an RSS icon for feeds, why add additional class attributes such a class="alternate" when you can just as easily use the more meaningful rel attribute?


a[rel="alternate"] { 
padding-left : 20px; 
background : url(a-rss.png) no-repeat 0 50%; 
}

People using browsers that did not implement CSS attribute selectors will simply not notice what they are missing, so they can live with that too.

Shadows

Drop shadows come in and out of vogue more often than Madonna. CSS offers an easy way to add a subtle shadow to text that can be particularly effective if you place white text over a darker background. I wish all browsers would implement text-shadow, but until they do I'll have to live with that.


#nav-main a { 
text-shadow : #000 1px 1px 1px; 
}

Text-shadow Opera & Webkit (left) Internet Explorer 7 (right)

I often also opt for utilizing the box-shadow property instead of making a compound of additional elements, attributes and images. Not every browser will see these browser generated shadows, but unless they are an integral part of a design, I can live with that too.


#nav-sub { box-shadow : 0 0 5px #888; 
-webkit-box-shadow : 0 0 5px #888; 
}

Box-shadow Webkit (left) Internet Explorer 7 (right)

Exactly what modern CSS was designed to do

I know that it is highly unlikely that every browser will ever support every CSS property. You should learn to live with that.

I would never accept a design that looks poor or broken or that a person would be denied access to content or services if they are using a less capable browser. But each of these CSS properties helps me to reduce unwanted markup and make my designs less reliant on presentational elements or attributes; exactly what modern CSS was designed to do.

I can and do live with these differences. Could you?

Places on our Visual Web Design Master Class in London on 1st December are selling fast. Don't miss out, book your place.

There have been 37 replies

  1. #1

    Ludwig Wendzich

    I could, but could my clients? They are less forgiving and they nitpick the small things.

    (PS: Why do I need to type twitter.com if you are asking for my twitter URL?)

    24th Sep 2008
  2. #2

    Oliver Ker

    I concur!

    I feel like there is a slight snobbishness starting to form around making everything look the same in all browsers. “But does it look the same in IE6, my website does!” - “NO, because IE6 is pants” while spending far too much time to achieve it.

    24th Sep 2008
  3. #3

    Chris Mills

    Great article Andy - I think this kind of thinking is important for “design sanity” on the Web. The side by side comparisons are also useful for justifying browser differences to clients perhaps? “It’s not broken - it just looks slightly different!”

    24th Sep 2008
  4. #4

    Sean Johnson

    I like this attitude. As Nate Koechley said at @media2008, “cross browser support doesn’t mean identical” and I totally agree. I used to be really anal about pixel perfection, but now I’ve seen the light!

    24th Sep 2008
  5. #5

    Ollie Kavanagh

    Great post and something I feel very strongly about.

    It is something I have been pushing more and more in my personal projects and my full time work, even to the point that the beta site we are working on I have been given the go ahead to use as many advanced selectors as I want as long as the experience in older browsers is not broken or disjointed.

    I am more than happy to get a slight different viewing experience in different browsers, I guess it is all about educating clients and management that the benefits to this greatly outweigh the negatives from a coding/design/experience standpoint.

    24th Sep 2008
  6. #6

    Andrzej Kala

    I like what you’ve written and on most part - I do agree. But just as Ludwig said - there are clients that can’t get along with thought that someone won’t have the full visual experience.

    Still - In my own projects I tend to be able to live without worrying about IE6 (as long as the site is readable and accessible).

    Great post btw.

    24th Sep 2008
  7. #7

    Ross Bruniges

    Good stuff - as a developer rounded corners and drop shadows make my blood boil. I hope that the people who should read this article actually do so - I guess it’s all about the promotion.

    Two points - :first-line actually does work in IE6 so you could still use that (if you really wanted) in designs fairly easily (one extra class is not all that bad is it not?!)

    The icons next to links in some cases might be considered a accessibility/usability feature and not a design feature - guess it depends on the context. (and can be added FAIRLY easily with a class and CSS - assuming they don’t wrap two lines in which case IE6 will go crazy)

    24th Sep 2008
  8. #8

    Andy Clarke

    @Ross Bruniges: “one extra class is not all that bad is it not?”
    When you use an extra class, you give a teenager a fresh pimple. I have a sixteen year old, I know how bad that can be.

    @Ludwig Wendzich: “...my clients? They are less forgiving and they nitpick the small things.”
    Do your clients actually compare browsers or do they compare what they see in a browser to what you showed them in a static Photoshop visual?

    @everyone: I’m a little concerned about a few negative comments about the readability of this site. I made some small changes to the blog pages the other day. Do you think the y helped?

    24th Sep 2008
  9. #9

    Ross Bruniges

    @Andy - I can live with pimples :>

    In regard to readability the text does seem a little bit blurred still (might be my dirty glasses and morning eyes though). Maybe a little bit extra letter spacing?

    24th Sep 2008
  10. #10

    Dan Donald

    Great post Andy!  I think it’s clients which are the issue as (in my experience) they often get hung up on minor details such as drop-shadows or everything looking just like a mock-up/PSD.  I think for most developers or designers it won’t be hard to persuade them this is the way to go but client education will be a way beyond that.

    24th Sep 2008
  11. #11

    Dave Bowker

    Great article.

    I never knew about using the ‘+’ as an adjacent selector before. Cheers. :)

    24th Sep 2008
  12. #12

    Dan Donald

    Meant to add…  It seems that by far too many clients are still on IE6 and so will compare this to the PSDs and certainly if we were to demo a site in FF or even IE7, they would often pick-up on the differences.

    A lot of it comes down to context of use; we should maybe think of older browsers in a similar way to mobile browsers insofar as they aren’t treated in the same way.  The context being, if you’re using a crappy old browser, upgrade or see minor differences!

    24th Sep 2008
  13. #13

    Andy Clarke

    @Dan Donald: “...and so will compare this to the PSDs…”

    So my answer has to be, Stop showing clients static design visuals

    24th Sep 2008
  14. #14

    Sam

    Great post, I’ve been noticing this trend a fair bit recently, and i think you’ve articulated the main idea pretty well. Coming from print, I have had to lose some of my ideas about perfection, but now my focus is more on the overall experience that the user has with a site, how they interact with it, which often isn’t so much to do with how it looks, but how it works(although aesthetics can be a part of that).

    Concerning legibility of text, I’m using a Mac with a widescreen and the text is definitely still hard to read. I think it’s because the main body text is bold, at least on my system.

    24th Sep 2008
  15. #15

    Drew Shapter

    I completely agree with you.  The main issue I come across is that when a client sets down a list of browsers that a site should be compliant with there is some unwritten rule that this means the site will look the same in all those browsers.

    Having been frustrated by the pixel-perfect gang I tried to reason with them that the usability and impact of a site won’t change if the submit button is two pixels more to the left on IE6 than in Firefox. This has often been meet with disregard and claims that “oh well it’s your code that’s wrong, the client doesn’t like it so you’ll have to change it”
    They seem to miss the point that what they have designed is a tool not a work of art.

    Education is what we need and the ability for clients to trust our decisions, why don’t they trust us, why do they always know best? I wouldn’t tell an architect that the windows in his blueprints are in the wrong place and I’m not paying till he moves them to where I think they should be.

    24th Sep 2008
  16. #16

    Martin Bean

    “But I can live with that…” Awesome quote.

    24th Sep 2008
  17. #17

    Kelvin J

    Re: Site readability. Echoing Sam’s comment, changing the font-weight to normal using Firebug definitely makes it easier to read. Also on a Mac.

    24th Sep 2008
  18. #18

    Richard

    Have to agree with this: as long as the design is close, it’s fine in my eyes: it’s not (usually) an effective use of a client’s budget to have us sitting there adding (for example) drop shadows by adding unneeded divs. Obviously, small details (such as rounded corners, drop shadows) can make or break a design, but, in my cases, it’s not the end of the world if those using IE6 don’t see a rounded corner.

    To add what others have said, I’m using Opera, and the font-weight appears bold too, which isn’t so easy on the eyes!

    24th Sep 2008
  19. #19

    Kelvin J

    Oooh, much better.

    24th Sep 2008
  20. #20

    Vladimir Carrer

    Great post! I use the same tricks. I think if your design looks good in IE you can use additional make up in other browsers. I don’t think that you can base your design on these tricks. Let just say if you need extra make up use them.

    24th Sep 2008
  21. #21

    Adam Thody

    I love the concept and I definitely agree with the principles…it’s just a matter of how to position this to clients so they will see the light. I think playing up the advantages from an ongoing maintenance standpoint will help.

    24th Sep 2008
  22. #22

    Derek Balmer

    Great post and I learned a few things as well. Thanks for this!

    24th Sep 2008
  23. #23

    rb3m

    I can live with all that. And clients can as well once you find a way to explain it. I use this: imagine a 10 year old car. It rattles, shakes and has awful fuel economy. You could spend money on it to make it a little more like a new car, but it will never be a new car.

    Most people understand that.

    24th Sep 2008
  24. #24

    Kyle Weems

    I think this is a great follow-up to the last post, helping provide concrete examples for designers that want to change gears but weren’t hadn’t grasped areas in their designs where an acceptable style loss could occur.

    And on the plus side, I’d never ran across font-variant before. Nifty.

    Regarding readability: I’m not having any difficulties reading the comments, even the darker text, so the changes you made seem to be effective.

    Also, Ludwig’s postscript asks a good question. If you’re only accepting Twitter URLs, wouldn’t it make more sense to only ask for the Twitter username, since the rest of the URL is always the same and easily inserted? Not that it’s an excessive burden the other way. It just struck me as odd.

    24th Sep 2008
  25. #25

    Lindsey

    “cross browser support doesn’t mean identical”

    I like that quote and I’m going to be using that extensively in the future.

    I agree - I can live with the small differences that aren’t supported in other browsers.

    I think the most important issue that needs to be evaluated is that the people who are the target audience (ie: which is the most popular browser) see what’s important about the site. If their missing little embellishments it won’t hurt anyone!

    24th Sep 2008
  26. #26

    Kyle Weems

    “weren’t hadn’t” - I hate it when I edit a thought mid-sentence but fail to fix what I wrote so that it makes sense when I’m done.

    Remove the “weren’t” from that in your minds.

    24th Sep 2008
  27. #27

    Andy Clarke

    @everyone: Cripes, I go out for a day, now so much to catch up on.

    @Kyle Weems: “...you’re only accepting Twitter URLs, wouldn’t it make more sense to only ask for the Twitter username?”

    You’re right, but it’s an ExpressionEngine thing in the way and I haven’t got around to solving it yet.

    24th Sep 2008
  28. #28

    Jinson Joseph

    Informative article

    25th Sep 2008
  29. #29

    Matthew Babbs

    A great set of examples to go with the previous post - thanks!
    By the way, the draft box-shadow spec has also been implemented by Firefox, so you can add -moz-box-shadow to go with -webkit-box-shadow.

    25th Sep 2008
  30. #30

    sacha harmsworth

    Great post and a great sugestion when working with people who understand web design or deal with designers, I think though for the lay person and most clients they will just go, “but it looks different in the other browser is it broken?” So I think we are someway off people outside the industry getting this and would have pick carefully when you worked in this way

    Also the rendering of rounded corners in firefox, I can’t live with that…

    25th Sep 2008
  31. #31

    patrick h. lauke

    as ever, on commercial projects, it probably comes down to whether or not the client can live with those browser differences as well (i’m thinking particularly the opera+webkit vs all other browsers ones)

    25th Sep 2008
  32. #32

    lup4lz

    @Andy: About the readability of this site, as you asked. I think I have good vision but white text on dark background gives me a headache (literally) and blurred vision after a few minutes. I always read this blog (and similar sites) with all text selected to avoid this, which is not good. I would call it an accessibility issue and it is frustrating- I know I can add my own css file to Safari and tinker with it but should I really have to do that? Love your articles by the way.

    25th Sep 2008
  33. #33

    Stephen Hay

    Clients only think differences are a bad thing when those differences make the design *worse* compared to their expectations. I’m not sure I’d go so far as to stop showing clients PSD mockups, but I’d be careful about making mockups too pretty. Keep them realistic. A sound method is to approach client presentations in the same way we approach progressive enhancement vs. backward compatibility: “This is what the site will look like for most people. Looks great, doesn’t it? And for those who’ve got browsers which support newer/better/compliant technologies, we’re throwing in some visual benefits for them at no extra charge to you.” Of course, *never* say it just like that, for risk of sounding like a cheesy car salesman. But the point is, this approach helps clients realize that they’re GETTING something extra, not LOSING something essential.

    25th Sep 2008
  34. #34

    Zeke

    Your discussion of browser differences you can live with makes sense - making sure that the content gets delivered while not sweating the small presentational differences is the cornerstone of modern development with standards and progressive enhancement.

    But why on this blog do you use hey-it’s-1998-again! browser-sniffing nonsense to send different CSS to different browsers?  To the uninitiated, it could suggest double-standards although I’m sure there’s a good reason for it.

    26th Sep 2008
  35. #35

    Andy Clarke

    @Zeke: “...not sweating the small presentational differences is the cornerstone of modern development with standards…”

    I agree, but many people still find this tricky to ask clients and managers to accept.

    “why on this blog do you use hey-it’s-1998-again! browser-sniffing nonsense”

    Conditional-CSS is a new and very interesting solution and I was keen to play with it on this site. Although I’m sure that it could be abused, as I’m only serving different background images to different browsers, here it’s a playful rather than a serious exercise.

    26th Sep 2008
  36. #36

    Zeke

    Yes, it is quite playful. But in your article you imply that it’s a serious, robust solution: “Conditional-CSS works. In-fact, it is as bomb-proof as wearing a steel hat in an concrete bunker.”

    It’s browser sniffing, and as such is about as fire proof as a chocolate fireguard. I feel that you have a responsibillity to emphasise that this is a regressive plaything rather than a serious developer tool or strategy. I don’t see it as a “new solution” - it just abstracts the actual browser sniffing away from the developer so the knowledgeable feel less grubby and the unsuspecting don’t really understand how retrograde this actually is.

    (Andy adds: I don’t want to derail the subject of this post. Perhaps we can pick up this discussion in another post in the future?)

    27th Sep 2008
  37. #37

    Zeke

    Sure. No malice involved, but I do think you should be practising what you preach here

    27th Sep 2008
Commenting is not available in this weblog entry.

Blog categories

Search blog archives