Category Archives: WebDevelopment

Conditional Comments for HTML5 Boilerplate

Posted on by
Reply

I generally have a “fuck you” attitude toward IE, but I have to support them now at my new job. Because I’ve worked so exclusively with mobile for the past few years, I’ve neglected really perfecting my conditional comments until now, but it seems like it’s a good idea to finally get a good handle on it.

The WYSIWYG text editor used by WordPress makes it a little tough to do this, but here is what I’ve settled on for now.

First, we put an empty CC on the very first line. It should go right before the DTD (I’m using the new “latest” HTML DTD supplied through the HML5 standard). This improves page load performance for IE by preventing that browser’s inherent tendency to block downloads. See Conditional comments block downloads for more info.

<!--[if IE]><![endif]-->
<!doctype html>

Then we have a series of CCs for each of the browsers we want to target with HTML5 Boilerplate. In this case, there’s one for IE7 …

<!--[if IE 7]>
<html class="ie7 oldie" lang="en">
<![endif]-->

… another for IE8 …

<!--[if IE 8]>
<html class="ie8 oldie" lang="en">
<![endif]-->

… and also one for IE with a major version number greater than IE8.

<!--[if gt IE 8]>
<html lang="en">
<![endif]-->

Lastly, we want to put in the standard html tag. The difference here is very subtle and it’s usually where I mess up. You kind of have to turn your brain inside out for this one – it’s kind of a double-negative. So, IE sees the opening CC, which tells it to ignore everything until it sees the closing CC. Standard browsers ignore the CC altogether because they themselves are contained within standard HTML comments.

<!--[if !IE]-->
<html class="no-js" lang="en">
<!--[endif]-->

Make sure you look out for the extra dashes (hyphens) when you are using CCs that exclude IE; otherwise standardized browsers won’t seem either!

 

Branching JavaScript for Different Browsers

Posted on by
Reply

I’ve been reading Pro JavaScript Design Patterns and I just got to try out a neat technique for dealing with the lexical differences between different browsers’ (I’m looking at you, IE) JavaScript implementations. The branching pattern allows you to create classes that execute different code based on whatever conditions you choose to examine.

/**
 * @constructor General miscellaneous utilities.
 */
mySingleton.etc = function () {
    /**
     * Branching object to handle both standard and 
     * Microsoft DOM interfaces.
     */
    var standard = {
            /**
             * Use the classList (standard) object.
             */
            getClassCount: function (element) {
                return element.classList.length;
            }
    }, 
    ie = {
            /**
             * Use the className (IE) object.
             */
            getClassCount: function (element) {
                return element.className.length;
            }
    }, 
    testObject, 
    testElement;

    testElement = document.createElement("body");

    try {
        testObject = webkit.getClassCount(testElement);
        return standard;
    } catch (e) {
        testObject = ie.getClassCount(testElement);
        return ie;
    }

};

It’s fairly easy to see what’s transpiring here. We basically have two cases we have to handle: IE and everything else. So we add two respective private members to this class, “standard” and “ie”. Then we check to see which method the class should return. We do this by asking the browsers to execute the code in question. Then we return the private member that can contains the code to be executed.

Simple, right?

Using HTML5 Elements in Tightly-Scoped CSS Selectors

Posted on by
Reply

I’ve been using some of the new HTML5 elements in a new web page template. While working on the CSS for the page, I noticed some interesting behavior in Internet Explorer 7 and 8. I have gotten in to the habit of writing very tightly-scoped CSS selectors; so tight, in fact, you would break the rule with the insertion of a single element into the DOM path.

div.businessProfile > ul.profileTools > li.follow > a.twitterLink {...}

So, when I added some of the new elements in to the selector, it looked like this:

div.businessProfile > header > nav > ul.profileTools > li.follow > a.twitterLink {...
}

This worked fine while I was still developing the page in Chrome. And it looked good in IE 9 as well. But when I checked it in IE 7 and 8, the style rules weren’t getting applied. I realized that the parser for Trident – the IE layout engine – didn’t know what to do with the HTML5 elements, even with the HTML5 DTD.

The quickest solution involves removing the HTML5 elements from the selector (and thus loosening the scope of the definitions’ application).

div.businessProfile ul.profileTools > li.follow > a.twitterLink {...}

Using conditional comments, one could load these definitions selectively for the defective browsers. But, then we’d be left with two separate style sheets to maintain.

Aside from using a CSS framework, or implementing a JavaScript hack, I’d love to find another solution, but I’ve got nothing yet.

Internet’s Down

Posted on by
Reply

Amazon Web Services EC2 cloud volumes for N. Virginia is down and they are having trouble launching new instances.

Here’s the full text direct from the console:

10:38 AM PDT We are currently investigating degraded performance for a small number of EBS volumes in a single Availability Zone in the US-EAST-1 Region.
11:11 AM PDT We can confirm degraded performance for a small number of EBS volumes in a single Availability Zone in the US-EAST-1 Region. Instances using affected EBS volumes will also experience degraded performance.
11:26 AM PDT We are currently experiencing degraded performance for EBS volumes in a single Availability Zone in the US-EAST-1 Region. New launches for EBS backed instances are failing and instances using affected EBS volumes will experience degraded performance.
12:32 PM PDT We are working on recovering the impacted EBS volumes in a single Availability Zone in the US-EAST-1 Region.
1:02 PM PDT We continue to work to resolve the issue affecting EBS volumes in a single availability zone in the US-EAST-1 region. The AWS Management Console for EC2 indicates which availability zone is impaired.

EC2 instances and EBS volumes outside of this availability zone are operating normally. Customers can launch replacement instances in the unaffected availability zones but may experience elevated launch latencies or receive ResourceLimitExceeded errors on their API calls, which are being issued to manage load on the system during recovery. Customers receiving this error can retry failed requests.

UPDATE: As I write this, I’m seeing services coming back up.

Still Using Firebug?

Posted on by
Reply

Chrome Developer Tools

As a web developer, I hadn’t decided to focus on front-end work until another developer told me about Firebug.

When I started targeting mobile, I switched to the Developer Tools suite (DevTools) built in to Google’s Chrome browser.

Two years later and I’m just beginning to realize what I’ve been missing. I was on the /r/javascript forum on Reddit and the top post is a slide deck showing forty pro tools and tips I had no clue about.

http://bit.ly/devtools-tips

 I find DevTools an indispensable utility and yet I’ve only been using 10% of its capabilities.

- @quantumtom