Using CSS to Replace Content for JavaScript Disabled Browsers

Dave Winter — Thu, 23 Jun 2011 17:41:07 +0000

If you’re like me, you love embellishing your projects with fancy JavaScript to give them pizzaz. But, chances are, you’ve also had some trouble finding a comfortable solution for replacing that JavaScript content for users who have (for one reason or another) disabled JS in their browser. After playing around with many possible fixes, I’ve come up with a standards-compliant, low bandwidth and easy to implement solution. And it’s probably something you weren’t expecting… CSS!

That’s right… by making use of the display:none CSS property we can serve alternate content to our non-JavaScript users without sending them to alternate pages on our site (a common, but outdated and clunky solution). So, get ready to turn off that JS in your browser (did I really just say that?) and start developing for true compatibility.

OK, this fix doesn’t rely 100% on CSS (so sue me). As a matter of fact, in order to get it working we have to add a little bit of… well… JavaScript. You may be thinking to yourself, “Wait… we have to add JavaScript to provide compatibility for users that disable JavaScript? That’s just crazy!” And you would be sorely wrong in your logic. It’s actually the least crazy fix I can think of for this problem.

Let me explain. Since JavaScript only gets run by browsers with JavaScript enabled, we can provide an extra CSS class (or id) through that script that allows us to show the JavaScript content on the page. But when the same page is loaded with JavaScript disabled, that extra CSS class doesn’t get loaded. So, by tweaking (read: “hacking”) our CSS by setting that extra class to display:none, we are essentially able to display different content for each type of visitor. Let’s take a look at the code before we go any further.

The JavaScript

/*  and <meta> tags */

<script type="text/javascript">
    document.documentElement.className += " js"
</script>

/* everything else before <body> tag */
</pre>
<h4>The CSS</h4>
<pre class="brush: css; title: ; notranslate">
/* Hide this by default, show this if JS is enabled */
#needsJS { display: none  }
.js #needsJS { display: block }

/* Show this by default, hide this if JS is enabled */
.js #fallback { display: none }
</pre>
<p>Seems straight forward enough, right?  Now all we have to do is figure out where to put our class (or id) in our page so the JavaScript content really does get hidden for visitors with JS disabled.  Here’s an example of how I have used it in the header of this page.</p>
<pre class="brush: php; title: ; notranslate">
/* this will display when JavaScript is disabled */
<div id="fallback">
<?php
wp_nav_menu( array('menu' => 'topnavie' ));	
?>
</div>

/* and this shows up when JavaScript is turned on */
<div id="needsJS">
<?php
wp_nav_menu( array('menu' => 'topnav' ));	
?>
</div>
</pre>
<p>A brief explanation of my usage: Since I’m using WordPress as my platform, I am targeting two alternate, but similar WP menus created with WP 3.x through PHP.  The second, topnav, relies on JavaScript to give the menu a Flash-like rollover effect (see top of this page with JavaScript on).  The first, topnavie, provides a JavaScript-free version with pure CSS styling that displays just fine when JS is off.  So, depending on the state of JavaScript functionality in the browser, one of these menus is always hidden, while the other is displayed in its place.</p>
<p>Of course, this is a fairly simple implementation of our fix.  It can be far more complex, with as many “fallback” attributes as the page needs.  Just remember that, in order for this to provide a consistent user experience, there should be two versions of the same content.</p>
<p>NOTE: As I have discovered throughout some implementations of this, a “needsJS” class is not always needed.  Obviously, this depends on usage and should be carefully examined before deployment on a live page.  But, when the JavaScript content to be displayed relies 100% on JavaScript to display at all, it doesn’t really need a “needsJS” class.  If this just made you even more confused, I recommend always using both classes to identify each state of functionality.</p>
<p>As always, let me know your thoughts.  And, yes, I’m ready to take some heat for saying this is a simple fix.  Bring it on!</p>

</article>
<article>
<h1>Simple Server-Side Browser Detection with PHP</h1>
<p>Dave Winter — Mon, 20 Dec 2010 20:14:27 +0000</p>
<p></p>
<p><span class="dropcap">E</span><em>ver wish you could make a webpage behave according to the browser it is being viewed with?  In many cases this can be done with some well-placed CSS code.  But, how about those situations when CSS can’t help us out?   CSS hacks and tricks won’t let you target Firefox, Chrome or mobile devices.  So, do you just stay away from using custom content in those browsers?  </p>
<p>Enter PHP browser detection!  With just a little bit of code, your site can reach its maximum potential in every browser, and even in mobile devices.</em>  </p>
<p>Some common uses for browser detection include:</p>
<ul style="margin: 0 0 0 40px;">
<li>- avoiding choppy JavaScript transitions by serving different versions of the script according to browser or device performance</li>
<li>- serving alternate content to iPhone browsers where Flash would otherwise be used</li>
<li>- getting rid of elements that cause rendering problems in some browsers but aren’t essential</li>
<li>- automatically populating a form with the current browser and version for simple debugging purposes</li>
</ul>
<p></p>
<p style="text-align: left;">To get an idea of usage, load this page in Chrome or Safari and take a look at the header.  Now load it in Internet Explorer.  Those subtle differences you see in the header allow the code to run more smoothly in mobile devices and IE.  And though it doesn’t look exactly the same, I’ve had no problems with branding the recognizable animation as my handle.  Enough talk — let’s get to it, then.</p>
<h4 style="color: #0099cc;" >The Basic Example Code</h4>
<p>Here is an implementation of this code as it appears in the header.php of this site:</p>
<pre class="brush: php; highlight: [7,10,14]; html-script: true; title: ; notranslate">
<!-- Top Menu -->
    <div id="logo"><a href="<?php bloginfo('url'); ?>">/images/logo.png" /></a></div>

        <?php 
	    $user_agent = $_SERVER['HTTP_USER_AGENT'];

		if (preg_match('/iphone/i', $user_agent))
		    wp_nav_menu( array('menu' => 'topnavie' ));		

		elseif (preg_match('/MSIE/i',$u_agent) && !preg_match('/Opera/i',$u_agent)) 			
		    wp_nav_menu( array('menu' => 'topnavie' ));
		} 							
			
		else {
		    wp_nav_menu( array('menu' => 'topnav' ));
			print
			'<a href="http://twitter.com/dauidus" target="_blank"><div id="bird"></div></a>';	
		};
	?>   
<!-- -->
</pre>
<p>As you can see here, I’m using a single line of code that tells the server to check the user agent.  Then we just employ normal PHP <em>if</em> statements to define what should be displayed in each browser.  First, I check for both the iPhone and IE and serve a stripped-down version of my site menu.  Then, I serve everything else a more beefed-up version of that same menu.  Of course, this is all pretty basic so far.</p>
<h4 style="color: #0099cc;" >Going a Bit Deeper</h4>
<p>But what if you need to target other browsers?  Here’s the code to target some other common browsers without any additional formatting:</p>
<pre class="brush: php; highlight: [7,12,18,23,28]; html-script: true; title: ; notranslate">
<?php

// check what browser the visitor is using
  $user_agent = $_SERVER['HTTP_USER_AGENT'];

// This bit differentiates IE from Opera
if(preg_match('/MSIE/i',$u_agent) && !preg_match('/Opera/i',$u_agent)) 
    { 
      print
        'This is Internet Explorer. (Insert joke here)';        
    } 
    elseif(preg_match('/mozilla/i',$u_agent) && !preg_match('/compatible/', $userAgent)) 
    { 
      print
        'This is FireFox.';
    } 
// let Chrome be recognized as Safari
    elseif(preg_match('/webkit/i',$u_agent)) 
    { 
      print
        'This is either Chrome or Safari.';
    } 
    elseif(preg_match('/Opera/i',$u_agent)) 
    { 
      print
        'This is Opera. Like to live on the edge, huh?';
    } 
    elseif(preg_match('/Netscape/i',$u_agent)) 
    { 
      print
        'This is Netscape, and you really need to upgrade.';
    } 

?>
</pre>
<p>Now, there are a few things to be explained here, even before we really get into the code.  The opera browser has had many problems in the past regarding <em>user agent spoofing</em>.  This spoofing was necessary because the MSN and IE browsers allowed developers to only serve content for their software (which was, at the time, considered to be top-notch).  Pretty much, this was IE’s attempt at sabotaging the web into using their browser out of necessity, not choice (tisk, tisk, IE).  In order for that content to be visible in Opera, their developers found it necessary to spoof their user agent to look and act like IE.  Now, this really hasn’t been too much of a problem since 2005, when Opera 8.02 was released with the option to use its own user agent string (and finally grew up as a big-boy browser… sort-of)  But as developers, we must remember that content needs to be served to the widest possible audience (as some companies won’t allow their employees to upgrade software).  </p>
<p>So, why did I make you sit through that winded explanation?  Take a look again at that first line of code above.  Notice that we not only detect the IE browser, but also conditionally detect for “if not opera.”  This should protect against all that nasty user agent spoofing for those who run versions of Opera younger than 8.02.  But, that’s not all.  Notice that we also later detect for the opera user agent with no other conditionals.  This should take care of all those later versions of Opera which don’t run into the spoofing stuff.</p>
<p>Still with me?  Good, because we’re not quite done with the explanations.  It’s not really spoofing, but Chrome and Safari both use the ‘webkit’ user agent (very familiar to anyone whose written CSS3).  So, using our script, Chrome will always be recognized as Safari (the default webkit browser).  This really shouldn’t be a problem if you are just wanting your content to be served identically across browsers.  But, if you’re looking to provide different content for those two browsers, this solution will not work for you.  </p>
<h4 style="color: #0099cc;" >Detecting Browser Versions</h4>
<p>So, what about those instances when you really need to serve alternate content to specific versions of browsers (can you say IE6)?  </p>
<pre class="brush: php; highlight: [7,12]; html-script: true; title: ; notranslate">
<?php

// check what browser the visitor is using
  $user_agent = $_SERVER['HTTP_USER_AGENT'];

// This bit differentiates IE from Opera
if(preg_match('/(?i)MSIE [1-6]/',$u_agent) && !preg_match('/Opera/i',$u_agent) && ) {
    // if IE<=6
        print
        'This is IE6 or less (the browsers of infamous dooooom!)';
}
else {
    // if IE>6
        print
        'This is IE7 or greater.';
}

?>
</pre>
<p>So, what we’ve done here is added the major versions to our ‘preg_match’ detection string.  In this case, we will check for IE versions 1-6 and serve some content for those.  If that doesn’t match the version, we can assume the user is on IE7 or above and serve them alternate content for those browser versions.  </p>
<p>So there you have it… simple browser detection using nothing but a few lines of PHP.  In a small number of cases, this script can produce false positives (for example, if IE is being run in compatibility mode).  In those cases, it may be best to run your site through a CMS and use a pre-packaged plugin.  I know there are a few for WordPress, but most have far more code than is necessary for most uses.  If you have found one of these plugins, let me know about it in the comments.</p>
<p>Caio!</p>

</article>
</main></body></html>

Dauidus Design » Browser Detection

Using CSS to Replace Content for JavaScript Disabled Browsers

The JavaScript