I’ve always been annoyed by browser specific CSS properties. Not necessarily because of the purpose browser specific CSS properties serve, but more so the isolation of each property. For instance, applying opacity across multiple browsers requires something like the following:

#selector {
    filter:alpha(opacity=80); /* Internet Explorer */
    -moz-opacity:0.8; /* Mozilla Firefox (legacy) */
    opacity: 0.8; /* CSS3 Standard */
}

Someday when CSS3 goes completely live, we won’t have to worry about opacity not validating; however, what about other browser specific styles that we need in order to support multiple browsers? If you don’t care about passing W3 CSS Validation, then this article is not for you. But for those of you whom require validation, or have a perfectionist nature, can workaround the validation engine using both JavaScript and CSS.

Although it may not be the best method out there, using JavaScript to implement impossible-to-validate CSS works the best for me.

Why does it work? Well its simple. Most bots/spiders don’t render JavaScript, which I imagine is for a number of reasons. Perhaps rendering JavaScript would slow down the bots’ very purpose of data mining (or with bad bots, the purpose of infiltrating). In fact, there usually isn’t anything valuable to a bot that would come from having to render JavaScript. (As a side note, this doesn’t mean that their aren’t bots that seek out sites that have vulnerabilities in their JavaScript markup, but reading JavaScript and rendering JavaScript are completely different).

So first, its a matter of migrating browser specific code to its own spreadsheet (so our JavaScript can include it). 

/* invalidable.css */
#selector {
  /* random properties */
    zoom: 1;
    -moz-border-radius
  /* opacity properties */
    filter:alpha(opacity=80); /* Internet Explorer */
    -moz-opacity:0.8; /* Mozilla Firefox (legacy) */
    opacity: 0.8; /* CSS3 Standard */
}

Once you have your browser specific properties on its own stylesheet, its just a matter of creating a JavaScript file that will “dynamically” insert the <link type=”text/css” rel=”stylesheet” href=”/assets/styles/invalidable.css” media=”screen”/> into your page (thus keeping with XHTML Strict standards).

// invalidable.js  <-- note the extension
//
// Dynamically Inserts CSS Link Tag
var headTag = document.getElementsByTagName("head")[0];
var linkTag = document.createElement('link');
linkTag.type = 'text/css';
linkTag.rel = 'stylesheet';
linkTag.href = '/assets/styles/invalidable.css';
linkTag.media = 'screen';
headTag.appendChild(linkTag);

Now all you have to do is throw in an JavaScript include tag:

<script type="text/javascript" src="/assets/js/invalidable.js"></script>

Your done! Bots will now only get this: 

<script type="text/javascript" src="/assets/js/invalidable.js"></script>

…while visitors will get this:

<script type="text/javascript" src="/assets/js/invalidable.js"></script>
<link type="text/css" rel="stylesheet" href="/assets/styles/invalidable.css" media="screen"/>

NOTE: It’s important to mention that visitors who have JavaScript DISABLED will NOT have the CSS file included, simply because the JavaScript won’t process; however, I will go on to say that its incredibly rare for you to have visitors that have JavaScript disabled. The only cases you’ll probably run into is visitors who visit your site from a cheap mobile phone (iPhone supports JavaScript), or a visitor who knows what their doing and has a Firefox plugin like “NoScript” installed.

On another subject, its important to mention that Google now penalizes for showing “different” content to search engines than to visitors. Would I classify an extra line in the section as different? Probably not. It’s my opinion that Google’s algorithm would check for differences in content, and not necessarily markup. I also haven’t seen very many cases where practices such as using JavaScript to “show/hide” content, be penalized in anyway. 

Anyone who’s had anything to do with web design, knows what a lightbox is, or at least has clicked on their fair share of them. For any web designer lucky enough to experience a YouTube video or Flash video overlapping their oh-so-beautiful lightbox, or their lovely css/javascript dropdown menu, will know that its one of those… you guessed it, Internet Explorer annoyances (in this case IE7). 

With the move from Internet Explorer 7, we were finally able to use PNG graphics (at least without having to add an IF IE7 condition statement to our head markup); however, when using flash, you’ll notice it renders as the upper most element, overlapping anything that dares try to be on top. The fix? Well its actually quite simple.

Here is an example object/embed element.

<object width="450" height="300" data="http://www.somedomain.com/video.mov">
<param name="movie" value="http://www.somedomain.com/video.mov"></param>
<param name="wmode" value="transparent"></param>
</object>

To prevent Flash from overlapping other elements, we simply need to remove ‘Line 3′.

<param name="wmode" value="transparent"></param>

For those that use sIFR to render standard text as flash, you’ll need to change the “sWmode” from transparent to opaque as is the case in the following line:

sIFR.replaceElement(named({sSelector:"h2#phrase", sFlashSrc:"/assets/typography/walbaum.swf", sColor:"#FFFFFF", sLinkColor:"#FFFFFF", sBgColor:"#000000", sHoverColor:"#CCCCCC", sWmode:"opaque", nPaddingTop:1, nPaddingRight:10, sFlashVars:"textalign=right&offsetTop=0"}));

Once your done changing your markup, Flash elements will FINALLY play nicely with the rest of your site.  

jQuery has long been our favorite javascript library for things such as simple effects, ajax, and other behavior-related tasks. There is one place I’ve always thought jQuery could use improvement, and that is their UI elements. Well I’m pleased to announce that is all about to change.

jQuery UI is growing, and I’m already seeing quite a few sites using it exclusively to support their interface. As a matter of fact, it’s growing so well, that a LA-based open-source company decided to hire a person to exclusively work on jQuery UI full-time.

More

I’d just like to announce the release of DOMAssistant 2.0 by Robert Nyman. For those of you who aren’t DOMAsses, the author describes the library as follows:

The idea of DOMAssistant is to provide a simpler and more consistent way to script against the Document Object Model (DOM) in web browsers. The idea is that everything starts with the element in question, and then performs various methods on it, such as adding/removing classes, finding elements with a certain className, applying events to it, etc.

This new release introduces several cool new features:

• Chainability
• Basic Ajax capabilities
• New DOMReady() method to better identify when the DOM is fully loaded
• XPath support

Now, being a jQuery fanatic, I was skeptical of giving this library a try, but I must say that it is actually pretty fun to work with. The chainability added in this newest version makes common tasks very simple, and the code short and easy to understand. Take a look at the following:

  // add an onclick event to #element and add the class "class-name"
  $("element").addEvent("click", function(){
    alert('Thanks for clicking, pally-o!');
  }).addClass('class-name');

Another very cool thing about this library is that it’s pretty small. The entire source code for it is only 10k (compressed, but not gzipped), where jQuery is 26kb (compressed, but not gzipped). On top if that, the library is modular. If you aren’t going to use any ajax, you don’t need to bloat up your source with the ajax functions. There are several modules in the library and you are free to pick and choose which you want to use.

Head on over to the DOMAssistant project page and take a look… don’t be a DOMAss.

jQuery 1.2 is finally here! If you are a web developer and you have not had the chance to play with jQuery, I highly recommend that you do. This library will change your life. OK, well that may be a little extreme, but I must say that before I found out about jQuery, any time I heard the words “ajax”, “interactivity”, or even just “javascript”, I’d head for the door. jQuery allows you to do what you want with javascript in a standards-friendly, unobtrusive way. It allows you to forget about all the tedious details of DOM scripting and just get down to business. 

The release was announced yesterday on the official jQuery blog. They also posted the official release notes where you’ll find the links to download the source, both compressed and uncompressed, as well as instructions on how to upgrade, and documentation for the new release.

I recently discovered an amazing javascript library called jQuery by John Resig. It is so well written that it makes even those who hate Javascript (like myself) enjoy writing it. It’s philosophy is “Find things, do stuff”, and it couldn’t possibly be more true to that statement. What I love so much about it is that it can do in five lines what would have normally taken twenty.

jQuery uses the dollar sign as a function name, followed by a “query” used to “find things” to “do stuff” to. The problem with this is that other widely used javascript libraries use the dollar sign for their function names as well. One such library is Prototype. Prototype uses the dollar sign as a shortcut to document.getElementById. So, when I need to use both JQuery and Prototype, what do I do? Well, jQuery has provided a handly little method called noConflict() to deal with just such an issue. To remedy an issue where the dollar sign function names conflict, you simply assign Jquery.noConflict() to something such as $j and then use that instead of the dollar sign.
(more…)