Although most of the concern with site compatibility lies with Internet Explorer most of the concepts we are using can be applied to any browser. Areas of concern include are CSS, HTML5 and JavaScript. We address cross browser compatibility with each of these in Product X using various techniques.

CSS

It’s common practice in web design to include browser specific style sheets for Internet Explorer compatibility. The problem is that style sheet conditional statements only work for Internet Explorer and are not conducive to style sheet aggregation. In Product X we take browser specific style to the next level with class based browser styles. We use a small JavaScript plug-in called CSS Browser Selector to sniff the client’s browser and append a class name to the opening html tag. Using that class name we can target very specific browsers in the main style sheet by simply starting a selector with the browser class name. Here are some examples:

• .ie .example { background-color: yellow }
• .ie7 .example { background-color: orange }
• .gecko .example { background-color: gray }
• .opera .example { background-color: green }
• .webkit .example { background-color: black }

By using the technique we can target other browsers like webkit and Firefox in addition to all versions of IE. We get the added benefit of better browser targeting as well as style sheet aggregation because these browser specific styles can be mixed in with the rest of the base style sheet. The script also has the ability to target operating systems but we have not run into a case yet where a platform specific style was needed.

CSS3 is used extensively throughout Product X but it is limited to visual style. If a situation arises where a shadow, rounded corner or gradient is crucial to the experience or functionality of the site appropriate fallbacks will be put in place. Using CSS3 falls in line with the overall design philosophy of Product X in that we shouldn’t be building a site for the lowest common denominator. Progressive enhancement and graceful degradation should be used whenever possible.

HTML5

The markup of Product X is written in HTML5 but at this point the majority of use has been with the new semantic tags available. Semantic markup of Product X is going to be very important for the future of our sites because it provides greater accessibility and classification of our content. Current browser support for HTML5 semantic tags is mixed so we use a JavaScript plug-in called Modernizr that forces browsers to recognize these tags as native DOM elements. After setting base styles for these tags in CSS they can be treated the same as any other block level element. Product X currently uses the following semantic tags in its markup:

header, section, footer, aside, nav, article, figure, figcaption, hgroup

Careful steps have been taken to remove any CSS dependency on these tags for style. That way if they need to be removed there will be no visual impact to the design. There are a couple of cases where these tags cannot be used. Firefox 2 refuses to recognize these tags as native DOM elements. Currently the approximate usage of Firefox 2 is at 0.6%. As it’s designed right now Product X will not display properly in this browser. The second case where these HTML5 tags cannot be used is when ajaxing in dynamic content with Internet Explorer. In this case we are currently using an HTML4 fallback for dynamically injected content in IE.

Other uses of HTML5 include using the placeholder attribute in form fields. We are using a script called jQuery Placehold to force compatibility of this feature in older browsers. Since we would use JavaScript to accomplish this anyway without a plug-in and HTML5 attribute it should not be a concern that we are taking this new approach. As browsers add placeholder attribute support we will have less need for this plug-in.

HTML5 lays the foundation for using drag and drop, form validation and local storage but these features are not currently being utilized in Product X without JavaScript.

JavaScript

When it comes to front end interaction in Product X all of the functionality has been accomplished with jQuery and jQuery UI. Both of these JavaScript libraries are actively supported and strive for cross browser compatibility. Product X currently uses two additional jQuery plug-ins called CeeBox for thickbox like popups and jQuery Tools for some gallery interactivity. Again, both of these plug-ins are actively supported and are cross browser compliant.

Check out this post on what properly round corners are.

So what was the difference in my project? I took screenshots of before and after and animated a GIF with them so that you can see the difference. Yes it’s very subtle, but the perfectionist in me is much happier with the proper method.

I was rounding both outer and inner elements with a 5px radius. After I learned my lesson I’m rounding the outer elements with a 5px radius and the inner element with a 4px radius. What do you think of the difference?

Here are what the boxes look like in Webkit…

Here are what the boxes look like on the iPad…

I don’t understand why Mobile Safari is treating the shorthand version of the style differently than Webkit. It sucks because I use the shorthand way to change individual corners on elements (some boxes in my project only need the top corners rounded). I would hate to write a style for each individual corner the longhand way like -webkit-border-top-left-radius: 5px;

[Update]

SASS to the rescue:

// Border Radius
@mixin border_radius($tl: 5px, $tr: 5px, $br: 5px, $bl: 5px) {
  -moz-border-radius: $tl $tr $br $bl;
  -webkit-border-top-left-radius: $tl;
  -webkit-border-top-right-radius: $tr;
  -webkit-border-bottom-right-radius: $br;
  -webkit-border-bottom-left-radius: $bl;
  border-radius: $tl $tr $br $bl;
}

By modifying my mixin to include the longhand styles for webkit border radius will now show up on mobile safari. This is another reason why Sass kicks ass because I only had to modify this single mixin and my entire project got updated. Just another reason why if you write CSS for a living you need to be using Sass.

This brings me a decision on what to do with the blog category and the homepage. For now I’m going to to keep the sliding panels but I think it can be done better. I’m thinking that on the homepage I want to try and figure out a way to include only the latest blog post and then start listing out my favorite portfolio projects. I am also going to add a panel at the end that will list out my most recent blog and twitter posts. As for the blog archive I’m going to have to think of a new presentation but I suppose what’s in place now will suffice. Time to start hacking the home page!

(Hours later…)

I’m so excited. So when I made the changes I mentioned above this really screwed up my jQuery default image replace code. I tried to fix it but I’m just not good enough to work around the new way I was inserting the image as an inline style attribute. So I had to venture into the unknown. Instead of testing to see if the image source was empty with jQuery, I tried testing it with PHP. This is big time wilderness for me. My first attempt crashed and burned. A quick look on Google for PHP if/else statements got me pointed in the right direction. My second attempt worked perfectly! I’ve never wrote PHP and to have it work on the second try was awesome. I’m learning so much from customizing this the Viewport WordPress theme.