Persistence Will Set You Apart

I mentioned a couple posts back how difficult web development has become. When I started, you had to learn HTML, and a handful of key attributes to style elements (CSS wasn’t yet a thing). Since then we’ve seen a Cambrian Explosion in the industry. Out of nowhere was birthed an immense amount of complexity.

You’ve probably heard about Imposter Syndrome, or the idea that you are not deserving of your professional position and/or accolades. I don’t recall this being a thing in the past, but it quickly became one in the 2000’s. Many of the biggest names in our industry have expressed these types of feelings on occasion, and who can blame them?

As you progress in your career, you will inevitably be faced with complicated technical barriers. It’s part of growing, and it’s part of existing within a field that is itself growing. How you react to these barriers will determine your long-term success or failure.

My son loves video games. He’s been playing them since he was about 2.5 years old. And since he began, I have been working hard to instill within him the idea that he can do hard things.

On multiple occasions he has encountered a boss battle or an obstacle that he simply couldn’t surmount. He would come to me, shoulders shrunken in defeat, asking that I take the controller from his downtrodden grip, and advance him one stage further. Rather than do so, I would straighten his posture, and tell him “you can do hard things!”

I cannot express in words how much joy I feel to see him return to the game, try 2 or 3 more times, and then erupt in excitement when he succeeds. He is internalizing the belief that he is capable of great things.

I have to coach myself in a similar manner. Just a couple of days ago I was looking for a new hosting provider. First, I went to Azure. Within 10 minutes, I was ready to give up. I couldn’t make heads or tails of the dashboard.

Next, I went to Digital Ocean. They wanted me to learn about “Droplets”, or something. They had a “one-click install” for WordPress, but it left me only with a gateway to a UNIX console. It’s been a while since I rolled around in one of those. I was tempted to just give up.

What kind of example would I be setting for my son if I gave up? Am I not capable of hard things too? Certainly I am! I have spent a decade telling clients that Nothing is hard; but some things take more time. It’s time for that ideology to be more than a sales pitch; it’s time for it to be the foundation upon which my efforts are established.

There are generally two types of people in this industry: those who can do hard things, and those who shy away from hard things. I want to strive to be the former. I want  you to do the same. After all, we’re in this together.

Persistence will set you apart.

Learn Together

Learning is one of the most essential keys to succeeding in web development these days; you have to continue to evolve with the ever-changing topography of the industry.

In the 90’s, when I started learning to build websites, there weren’t a lot of resources online. I WebMonkey and HTMLGoodies for the most part. I spent hours on these sites, learning all that I could. And for everything else, there was View Source.

The great thing about View Source was that it gave you a look into the mind of another developer. While I’d pick up the primitives from WebMonkey and HTMLGoodies, I learned creative approaches and applications in View Source.

I had very few friends that showed in interest in web development back then. I was raised in a small town set off a river in Southern Illinois. We were mostly interested in sports and video games. Today that isn’t the case; I have a large network of friends who are obsessed with building for the web.

Learning in a group is powerful. It lightens the load on each individual. And nowhere in history has it been more necessary than it is today. Web Development isn’t about hacking together some HTML and tossing it up on Geocities, like it was in the 90’s.  Today you have to figure out pre-compilers, deployment strategies, version-control software, and more; and we haven’t even gotten to the actual development process yet.

Years ago I used to meet regularly with some friends to catch up on life, and find out what they were learning. We’d walk each other through code we had written during the week, and explain new ideas. This was how I would become introduced to many JavaScript frameworks, Node.js, and more. We’d even revert to studying Math we had long forgotten to solve certain problems together.

Learning requires hours of slugging through lengthy documentation, manuals, and more (assuming good documentation even exists; it often doesn’t). There is often a frustrating process of trial-and-error that leaves you aggravated, before it leaves you enlightened. But when you come out on the other end, you’re able to save others the heartache by leading them along the path of least resistance.

It’s often said that a 2 horses don’t pull twice as much as 1 horse, they pull 3 times as much. There’s power in the unity of mind and effort. This is shown in group-learning, as well as in pair programming. So find a few friends, and meet regularly.

Learn together.

Mentor Somebody

Just a couple brief thoughts about mentoring.

Whether you’ve been a hobbyist for 6 months, or a professional for 6 years, you have something to offer. It may be as basic as explaining what HTML is, or something a bit more advanced like explaining how prototypes work in JavaScript. The bottom line is, though, that you have something to offer.

Back in the 90’s, when I got my first computer, I began to show an interest in web development. I didn’t know anything about programming, computers, or the Internet. I had just gotten a Hotmail account not too longer before that, and spent at least a few months thinking HTML was pronounced “Hotmail”.

A buddy of mine started learning web-development a little before me, and would mention it from time to time. It didn’t take long for me to get interested, and offer him $20 to build a website for me (big money, I know). He politely refused, and told me to “learn the code yourself”.

The code? What was the code? I suspected it was a series of numbers and letters that I type into the scary black part of the computer (cmd.exe). “Can you tell me the code?” I asked. He chuckled, and began to open up my understanding.

That particular friend invested maybe 20 minutes into my life. From that 20 minutes came 20 years of industry experience. I’m thankful for his willingness to be inconvenienced for a few moments. It changed my life.

Get out there, and change somebody’s life.

Browsers – Broken By Design

I set out a few hours ago to write about a problem I had experienced in Safari, Chrome, Firefox, and Internet Explorer. Opera worked as I expected, which had me convinced the other vendors merely dropped the ball, and shipped partial implementations for the :visited and :link pseudo-classes.

My CSS was very simple:

:link {
    color: white;
    background: red;

:link::before {
    content: "Pseudo: ";

A color set for unvisited links, followed by some content in the ::before pseudo element on all unvisited links. So when I dropped in two links (one visited, one not) I expected to see the following:

image00 copy

Instead, what I saw was a litter of inconsistent results between Chrome, Safari, Internet Explorer, Firefox, and Opera. The above image came from Opera. It performed exactly as I suspected. The others, not so much.

Chrome and Firefox gave similar results; both set “Pseudo” as a virtual first-child of both anchors (though I only asked to have it on unvisited links), and leaked the background color from :link into :visited.

Internet Explorer did better than Chrome and Firefox; it preserved the “pseudo” text, but left the background of the visited link untouched. I was still very perplexed as to why it was spilling values from :link over into :visited.

You can observe something interesting in Internet Explorer – :visited links start visually identical to :link links, but are transitioned into their :visited state immediately thereafter. Setting a transition on all links reveals the change when the document loads:

a {
    transition: background 10s;

You’ll see the :link links remain unchanged but :visited links slowly adopt their end style. This is not the case for Chrome, Firefox, Opera, or Safari.

Safari appeared to be the most broken of them all. It duplicated everything. Further, I attempted to set additional styles to :visited, and it completely ignored them.

Discovering History

I found it incredible that all of these browsers, with the exception of Opera, would get this so wrong. So like any good developer I took to the web to see who else might be complaining about this, which is when I came across a Stack Overflow post suggesting this was somehow related to security concerns.

This offered another search vector; security issues. That was the needed catalyst for opening up a fascinating story about yet another creative attempt by developers to put their nose where it may not belong – in the client browser’s history.

Browsers typically style links with a default color to indicate whether it is a visited link or not. We’ve all seen those blue and purple links before – they’ve become quite at home on the web. Somebody got the (seriously) brilliant idea to create anchors ad hoc, and use getComputedStyle to see if the links represented visited or unvisited locations.

Mozilla reports that you could test more than 200,000 urls every minute with this approach. As such, you could – with a great deal of accuracy – fingerprint the user visiting your site based on the other urls they have visited; and browser history runs deep.

Scorched Earth Solution

The solution implemented by Firefox (and apparently others) was to greatly reduce the presence of visited links. They started by instructing functions like getComputedStyle and querySelectorAll to lie (their words, not mine) about their results. Sure enough, a simple check confirms that though my :visited links have a different font color than :link links, getComputedStyle says they’re the same rgb value.

Mozilla’s Christopher Blizzard continues with a very key point (emphasis added):

You will still be able to visually style visited links, but you’re severely limited in what you can use. We’re limiting the CSS properties that can be used to style visited links to color, background-color, border-*-color, and outline-color and the color parts of the fill and stroke properties. For any other parts of the style for visited links, the style for unvisited links is used instead. In addition, for the list of properties you can change above, you won’t be able to set rgba() or hsla() colors or transparent on them.

And there it was, the explanation that tied all of the seemingly broken pieces together. The browser would instruct :visited to share property values with :link. The browsers aren’t broken; they were designed to fail.

Test Confirmations

I wanted to explore the now-understood implementation a bit further, so I tried a few things. Querying the DOM for :visited links (expecting 1 of 2) was my first decision. I also queried the DOM for :link as well – expecting 2 due to the new security:

Browser Number of :visited Number of :link
Chrome 0 2
Firefox 0 2
Internet Explorer 0 2
Safari 0 2
Opera 1 2

Nearly all of the browsers report no :visited link, with the exception of Opera. All browsers report a total of 2 links when querying :link.

So it seems like you can still get a list of visited sites in Opera. Internet Explorer, Firefox, Chrome, and Safari all prevented the exploit from being carried out. But one thing about Internet Explorer intrigued me; remember the transitioning I spoke of earlier?

Internet Explorer Still Vulnerable?

I noticed that if I set transition: background 10s on anchors in Internet Explorer you would slowly see all visited links slowly tween into their end state. Transitions fire the transitionend event when they complete, so could we still get the user’s visited links in Internet Explorer?

The CSS to test this is very simple:

a { transition: background .01s }
:link { background: red }

And the following JavaScript:

/* Anchor var, fragment, and array of guesses */
var anchor;
var fragment = document.createDocumentFragment();
var websites = [

/* Listen for completed transitions */
document.addEventListener("transitionend", function (event){
}, false);

/* Create a link for each url */
    anchor = document.createElement("a");
    anchor.setAttribute("href", url);
    anchor.innerHTML = url;
    fragment.appendChild( anchor );

/* Add our document fragment to our DOM */

Immediately upon being added to the DOM our :visited anchors will start to transition away from looking like a :link anchor. Once that transition is complete, we learn what the URL is, and confirm that the user has visited that site.

Closing Thoughts

I was reminded today just how exciting our industry is. People are constantly experimenting, learning new things, and sharing that knowledge. Industry experts, developers, designers, and browser vendors are always working to shift and adjust in light of the ever-evolving web.

Although the CSS2.1 Specification says something, that doesn’t make it so – even if the feature is 15 years old. If the ends justify the means, browser vendors will (and did) fire-bomb their own code-base to protect the end user.

Finally, we’re all in this together; we ought to work together. Microsoft launched the @IEDevChat twitter account not too long ago to assist developer’s who are attempting to follow web-standards. Then even organized a group of developers who wanted to volunteer and help build a better web; you can find (and join) it online at

I’m sure there’s more history here that I’ve yet to discover, but what I have seen is enough to pique my interest. If you have anything else to share, or can contribute to the vulnerability test approach above, please leave a comment below. I may swing back around and check out the other browsers later on.

Designing with Pseudo Elements in IE10

Pseudo Elements in IE10

When Internet Explorer 10 came onto the scene as one of the first desktop browsers engineered for touch, it brought with it a few upgrades to many form elements. Input fields began, overnight, to render with their own clear buttons, causing some anguish among designers who had already provided similar functionality on their own.


It wasn’t long until Stack Overflow, and other communities, began hearing the groans of web designers wanting to know how they can turn off these new progressive enhancements. But what initially appeared to be a nuisance is actually a great opportunity. These new pseudo elements give us more control than ever before.

Quick Brushup

Pseudo elements are parts of the document that are not declared in our markup, but are provided by the browser when rendering certain elements. For instance, pseudo-elements exist that represent the ::first-line of text in a paragraph. This requires no additional markup to function, but gives us great control over how things look.


I would like to cover nearly 20 pseudo elements in the remainder of this article, demonstrating with each what type of effect(s) we can achieve in our presentation.

Here’s a list of what we’re going to cover:

::after ::before
::first-letter ::first-line
::-ms-browse ::-ms-value
::-ms-check ::-ms-clear
::-ms-expand ::-ms-fill
::-ms-fill-lower ::-ms-fill-upper
::-ms-reveal ::-ms-thumb
::-ms-ticks-after ::-ms-ticks-before
::-ms-tooltip ::-ms-track

Before and After Pseudo Elements

The ::before and ::after pseudo elements create virtual children within the container (like an invisible <span> element). These appear before all other children, and after all other children, respectively. You can use these to achieve many great effects, such as fading an image out and adding text over the top of it.


The HTML for the above is very simple. It’s nothing more than an image within a figure element.

    <img src=”jonathan-sampson.jpg">

In the CSS we’re using ::after (::before is used the same way) to add a positioned element over the top of our image, give it a gradient background, and some text content.

figure {
    position: relative;

figure::after {
    /* Text and Color */
    color: white;
    font: 1em "Segoe UI";
    content: "@jonathansampson";
    text-shadow: 0 .1em .2em #004D71;
    /* Size and Placement */
    left: 0; bottom: 0;
    width: 100%; padding: 2em 0;
    display: block; position: absolute; 
    /* Background */
    background: linear-gradient(to top, white 1em, transparent);

First Line and Letter Pseudo Elements

By using the ::first-line and ::first-letter pseudo elements we can target the first line of text in a text block, as well as the first letter in that line, and modify their styles independently of their surroundings. By combining both of these, we can achieve an effect like the following:


The above consists of nothing more than a simple paragraph, as far as markup is concerned.

<p>When Internet Explorer 10 came onto the scene...</p>

The styles too are very concise and easy to understand.

p {
    font: 1em "Segoe UI";

p::first-line {
    font-weight: bold;

p::first-letter {
    font: 5em "Script";
    float: left;
    line-height: .5em;
    padding: .15em .15em 0;

Browse and Value Pseudo Elements

File uploads have always been a pain to style; in the past we didn’t have much access to the button itself. Today with the ::-ms-browse and ::-ms-value pseudo elements we can target individual parts of the file upload control and create a far better presentation than was ever possible before.


The markup here is familiar and short; it’s just a single file input.

<input type="file">

The CSS, on the other hand, is slightly more verbose since we’re targeting the input element, the browse and value pseudo elements collectively, as well as individually.

input {
    background: transparent;

::-ms-browse, ::-ms-value {
    border: 0;
    padding: 1em;
    color: rgb(71,194,254);
    background-color: rgb(1,132,195);
        linear-gradient(to bottom, transparent 1px, rgb(71, 194, 254) 1px, transparent 1em),
        linear-gradient(to top, transparent 1px, rgba(0,0,0,.2) 1px, transparent 2em);

::-ms-browse {
    font-weight: bold;
    background-color: rgb(1, 107, 157);
    border-radius: 0 .5em .5em 0;

::-ms-value {
    border-radius: .5em 0 0 .5em;

Check Pseudo Element

With ::-ms-check we now have access to the inner-part of a radio or checkbox. This means we can now modify its presentation just as easily as we could the rest of the element itself. In the example below we’ve increased padding, changed the background color of the checked-portion, updated the foreground color, and even added a subtle inner glow.


The CSS is very straightforward.

::-ms-check {
    border: 0;
    color: white;
    padding: .25em;
    background-color: rgb(1,132,195);
    box-shadow: inset 0 0 .5em rgb(71, 194, 254),

Clear and Reveal Pseudo Elements

This article opened with an example of the new ::-ms-clear pseudo element, and a short description of the frustration it has caused many designers who have already had long-standing functionality in place to clear fields. Often times designers just want it to go away.

::-ms-clear {
    display: none;

Easy enough.

Similar to the ::-ms-clear pseudo element is the ::-ms-reveal pseudo element. This is represented as a button in password fields. When pressed, and held, it reveals the password in the text box to which it is associated.

You can also set its display to none if you wish to get rid of it.

Expand Pseudo Element

The ::-ms-expand pseudo element grants you power over the button typically displayed with select menus. By leveraging this pseudo element we can round corners, set gradient backgrounds, and so much more.


I cheated here just a bit and added styles to both the select element, and the ::-ms-expand pseudo element.

select {
    color: #333;
    padding: .25em;
    border-radius: .5em;
    background-color: #f1f1f1;
        linear-gradient(to bottom, white, transparent);
    border: 1px solid rgb(71, 194, 254);

::-ms-expand {
    padding: .25em;
    margin-left: .25em;
    border-radius: 50%;
    color: rgba(0, 0, 0, .25);
    background-color: rgb(71, 194, 254);
        linear-gradient(to bottom, rgba(255, 255, 255, .8), transparent 1em);
    border: 1px solid rgba(71, 194, 254, .5);

Fill Pseudo Element

The ::-ms-fill pseudo element works with the <progress> element, which shows an advancement in a set of sequences or length of time. The “filled” portion of the progress bar is exposed to us for additional styling on top of those styles applied directly to the main element itself.

While this element, visually, isn’t as complex as others we can still have some fun with it.


progress {
    border: 0;
    height: 1.5em;
    border-radius: .25em;
    background-color: #f1f1f1;

::-ms-fill {
    border: 0;
        linear-gradient(to top, transparent 1px, rgba(255,255,255,.5) 1px, transparent 1em),
        linear-gradient(to left, rgba(0,0,0,.3) 3px, transparent 3px),
        linear-gradient(to right, rgba(0, 0, 0, .3), transparent);

Fill Upper/Lower, Ticks Before/After, Thumb, Tooltip, and Track Pseudo Elements

The range control is full of pseudo elements. The right side of the range, the left, the (optionally visible) ticks above or beside the control, the track itself, the popup tooltip, and the handle to change the value. In the following image you can see nearly every pseudo element adjusted in some way, shape, or form (tooltip not visible).


The upper fill was given a slight glimmer while the lower fill was left solid. The ticks before (above the slider) and after (below) were made lighter. The thumb was rounded, given a slight gradient for depth, and a hollow-looking center. Lastly the track pseudo element was given white, semi-opaque, markers.

::-ms-tooltip {
    display: none;

::-ms-ticks-before, ::-ms-ticks-after {
    color: #999;
    display: block;

::-ms-ticks-before {
    background: linear-gradient(to top, #CCC, transparent 30%);

::-ms-ticks-after {
    background: linear-gradient(to top, transparent 70%, #CCC);

::-ms-fill-upper {
    background-color: rgb(1, 107, 157);
        linear-gradient(to bottom, transparent 1px, rgba(255,255,255,.25) 1px, transparent 70%);

::-ms-fill-lower {
    background-color: rgb(1,132,195);

::-ms-thumb {
    background-color: white;
        radial-gradient(circle, rgb(1, 107, 157) 20%, transparent 20%),
        linear-gradient(to top, #CCC, white);
    border-radius: 50%;
    border: 0;

::-ms-track {
    color: rgba(255, 255, 255, .5);

Selection Pseudo Element

The last pseudo element we’re going to look at is the ::selection pseudo element. This represents any selection of text in the document. The control you have over this is extended to the foreground color, and background color of the selection.


By default selected text is white with a blue background. In the example above we have changed the text to black, and the background to hot pink (in true Irish fashion).

::selection {
    color: black;
    background: pink;


We’ve looked at nearly every pseudo element available in Internet Explorer 10, as well as a few types of modifications we can make to the UI by leveraging their presence in the document. It’s important to note that different browsers may have different pseudo elements you’ll have to target in order to modify the same (or similar) document elements. This post was merely an exploration of those that presently exist in Internet Explorer.

If you have any questions about the above examples, please feel free to reach out to myself, or any of my fellow IE User Agents. You can do so by leaving a comment below on this post, or tagging your tweet with the #IEUserAgents hashtag (we’re listening). If you have questions about general development and Internet Explorer, follow and interact with @IEDevChat on twitter.

If you would like access to Internet Explorer from your Mac to test these features, you can use BrowserStack, or download a free Virtual Machine from I use both methods regularly – I would encourage the virtual machine route if you have the space/memory.

That’s it. Go change the web.

IE10 Gotcha: Animating Pseudo-Elements on Hover

I came across a question on Stack Overflow today asking about animating pseudo-elements. This is something I have lamented over in the past since it’s been a supported feature in Internet Explorer 10 for a while, but only recently implemented in Chrome version 26. As it turns out, there was a small edge-case surrounding this feature that I had yet to encounter in Internet Explorer 10.

The following code does two things; first it sets the content and transition properties of the ::after pseudo-element for all paragraphs (there’s only one in this demo). Next, in the :hover state (or pseudo-class), it changes the font-size property to 2em. This change will be transitioned over 1 second, per the instruction in the first block.

p::after {
    content: ", World.";
    transition: font-size 1s;

p:hover::after {
    font-size: 2em;

Although simple and straight forward, this demo (as-is) doesn’t work in Internet Explorer 10. Although IE10 supports :hover on any element, and IE10 supports pseudo-elements, and IE10 supports animating pseudo-elements, it does not support all three, together, out of the box.

If you change your markup from using a paragraph to using an anchor element, the code begins to work. This seems to suggest some type of regression has taken place, causing Internet Explorer 10 behave similar to Internet Explorer 6 where only anchors could be “hovered” — support for :hover on any element was added in version 7.

Upon playing with this a bit, there does appear to be a few work-arounds:

  1. Change your markup
  2. Use sibling combinators in your selector
  3. Buffer a :hover selector on everything

Let’s look at these one at a time.

Change Your Markup

Rather than having a paragraph tag, you could nest a span within the paragraph, or wrap the paragraph in a div. Either way, you’ll be able to modify your selector in such a way so as to break up the :hover and ::after portions. When the user hovers over the outer element, the content of the inner-element’s pseudo-element is changed.

I don’t like this option; it’s far too invasive and demanding.

Use Sibling Combinators in Your Selector

This was an interesting discovery. I found that if you further modify your selector to include consideration for sibling elements, everything is magically repaired. For instance, the following targets our paragraph based on some other sibling paragraph:

p~p:hover::after {
    font-size: 2em;

This is interesting; it doesn’t break the connection between :hover and ::after, but it does modify the root of the selector, which somehow causes things to repair themselves.

What I don’t like about this approach is that it requires you to explicitly declare the sibling selector, as well as the element you’re wishing to target. Of course, we could fix this a bit by targeting a class or id, as well as going with a different sibling combinator:

*~.el:hover::after {}

This targets any element with the .el class that is a sibling of any other element. This gets us a little closer, but still, a bit messy. It requires us to modify every single selector that is part of a pseudo-element animation.

Buffering the :hover Selector

Provided with the question on Stack Overflow was one solution to the problem. As it turns out, if you provide an empty set of rules for the hover state, this fixes all subsequent attempts to animate pseudo-element properties. What this looks like follows:

p:hover {}

p::after {
    content: ", World.";
    transition: font-size 1s;

p:hover::after {
    font-size: 2em;

Oddly enough, this small addition does indeed resolve the issue. Given the nature of CSS, you can even drop the p portion, and just go with the following fixing it for all elements:


This too results in a functioning Internet Explorer 10 when it comes to animating pseudo-element properties.


Creating a (autofocus) Polyfill

In the ever-changing world of browser topography, every so often there exists an expectation in the community that some feature or API will be available in a browser, and it’s not.

We have an approach to mitigating these types of issues though, and we call it polyfilling. To quote Remy Sharp, “A polyfill, or polyfiller, is a piece of code (or plugin) that provides the technology that you, the developer, expect the browser to provide natively. Flattening the API landscape if you will.”

A question was recently asked on Stack Overflow about automatically applying focus to an input element when the page loads. The first responses suggested using a tool like jQuery to target the element, and invoke its focus method. While this works, it adds additional overhead in environments where it’s not needed.

My initial solution to the question was to use the autofocus boolean attribute on the input element of choice. Shortly after suggesting this, I realized this attribute was only introduced in Internet Explorer at version 10, meaning users of 6, 7, 8, and 9 wouldn’t get the behavior the developer expected – perfect opportunity to author a polyfill.

Our goal in building a solid polyfill is to not make its presence known; we want the web developer to author their markup as they would normally, while we quietly teach the browser to make sense of the unknown autofocus attribute.

So we start with basic HTML:

<input name="name" placeholder="John Doe" autofocus />

In browsers like Internet Explorer 10, Chrome 26, or Firefox 20, focus will be immediately given to this element upon page load. But for Internet Explorer 6-9 and versions of Firefox prior to 4.0, we’ll have to add a bit of assistance.

We start by first performing a feature-detect for the autofocus property in a freshly-created input element. In browsers that support this property, the default value is false:

// Proceed only if new inputs don't have the autofocus property
if ( document.createElement("input").autofocus === undefined ) {


This condition will only evaluate to true in browsers that don’t natively understand the autofocus attribute, and as such, this will be our sandbox to play in while constructing our polyfill. We’ll need to go through a few steps for this polyfill, so let’s have a look at what they are:

  1. Cycle over all forms
  2. Cycle over all elements in each form
  3. Check attributes of each element for autofocus
  4. If found, trigger focus, and break out of all loops (only one instance of autofocus should exist on in a document, otherwise you’ll get inconsistent cross-browser results)

Our first step in the above list is to cycle over all the forms. We can use the document.forms collection to find all of the forms on the document. We’ll also create a variable to track our index in the collection of forms. Lastly, we’ll add a label to this loop so that we can break from it later:

// Get a reference to all forms, and an index variable
var forms = document.forms, fIndex = -1;

// Begin cycling over all forms in the document
formloop: while ( ++fIndex < forms.length ) {


Next, within our formloop, we need to get a collection of the current form’s elements. Additionally, we will be creating another index variable to help us navigate this new collection:

// Get a reference to all elements in form, and an index variable
var elements = forms[ fIndex ].elements, eIndex = -1;

// Begin cycling over all elements in collection
while ( ++eIndex < elements.length ) {


The third step in our process is to check for the autofocus attribute in each element. There are various ways you can do this, and I explored several of them. For instance, you could use the hasAttribute method, but this is only supported in Internet Explorer from version 8 (meaning you’d have to polyfill it in earlier versions).

In the end I wound up checking for the attribute as a key in the element.attributes collection. If not present, the result will be falsey, and the loop will skip to the next element in the nodeList:

// Check for the autofocus attribute
if ( elements[ eIndex ].attributes["autofocus"] ) {


Finally, we arrive at our last step. We have found an element that has the attribute we’re looking for, and it’s time to focus on it, break out of the loops, and call it quits.

// If found, trigger focus
elements[ eIndex ].focus();

// And break out of outer loop
break formloop;

This is where the formloop label comes in handy; a simple break would have broken the element loop, but not the forms loop, meaning subsequent form elements (and their children) would be evaluated. Since only one instance of autofocus should appear in a document, this is not the behavior we want.

The final result is wrapped in an IIFE (Immediately Invoking Function Expression) which runs our code immediately, as well as prevents our variables from appearing in the global namespace, potentially causing harm to the rest of the document or application.

(function () {

    // Proceed only if new inputs don't have the autofocus property
    if ( document.createElement("input").autofocus === undefined ) {

        // Get a reference to all forms, and an index variable
        var forms = document.forms, fIndex = -1;

        // Begin cycling over all forms in the document
        formloop: while ( ++fIndex < forms.length ) {

            // Reference all elements in form, and an index variable
            var elements = forms[ fIndex ].elements, eIndex = -1;

            // Begin cycling over all elements in collection
            while ( ++eIndex < elements.length ) {

                // Check for the autofocus attribute
                if ( elements[ eIndex ].attributes["autofocus"] ) {

                    // If found, trigger focus
                    elements[ eIndex ].focus();

                    // And break out of outer loop
                    break formloop;






There you have it, a polyfill that gives autofocus behavior to browsers that don’t natively support it. By dropping this in to your website, you can now carry on your merry way using great features of HTML like this, without worrying what negative effect it might have on your Internet Explorer 6, 7, 8, or even 9 visitors.

Taking the Internet Explorer Challenge

I’m going to use Internet Explorer 10 as my primary browser for one week. That’s one week without browsing, tweeting, or listening to turntable in Chrome (current “Browser of Choice”). That’s one week deep inside the bowels of the browser that burned me, and so many of my peers, so badly over the last decade. One week in the heart of the beast.

Why? Isn’t Internet Explorer supposed to be a thing of the past? A bad phase in the history of the web that we’re slowly recovering from? The faint image of the broken internet from yesterday, replaced by far more standards-compliant browsers like Firefox and Chrome? Well, yes, and no.

If I’m honest with myself, and everybody else, it’s not the browser that burned me. Internet Explorer dominated the market back in the day when I got excited to see 3kb/sec downloads. It was installed along side Netscape Navigator, but won me over pretty quickly.

The browser won a lot of people over, including corporations who went on to develop internal applications that depended on its implementation of HTML, CSS, and J(ava)Script. And then the world changed around them; around all of us.

Dial-up was becoming a thing of the past, and new browsers were creeping into the scene. Firefox rose like a phoenix from the ashes of Netscape, and then Google got into the game with Chrome. These later browsers took advantage of faster and more consistent connections and offered streamlined updates that happened silently in the background.

Internet Explorer was still dominating in the global market, but these antiquated versions from yesteryear were still in circulation, and still being actively used. While they were once the apple of our eye, we quickly jumped from them to the new breed of browsers. It wasn’t that Internet Explorer 3-8 were bad – they weren’t. It was the fact that the world around them changed, and changed quickly.

Fast forward to Internet Explorer 10; it is new, and has great support for standards. Most importantly though, it hints at having the capacity to auto-upgrade like its competition. So I was curious, do I have any reason to dislike Internet Explorer any longer? Is it just as good as Google Chrome, Mozilla Firefox, or Opera? What better way to find out than to use it as my primary Browser of Choice for one week.

Sunday, Bloody Sunday

It’s really tough retraining my mind to click my Internet Explorer icon instead of my Chrome icon. The icon that was once relegated to testing and debugging my code in yesterday’s browser is now my go-to destination for all casual browsing, tweeting, and more.

So far I’ve been using Internet Explorer for Bootstrap work, blogging from WordPress, Tweeting with TweetDeck, Facebook, and casual browsing online. While I didn’t spend much time in the browser today, I did do some tweeting from @tweetdeck’s web-application, and noticed that the scrollbars are pretty horrible looking – so I fixed them. Left and right for before and after.


Unfortunately it appears Twitter has neglected Internet Explorer when they developed their dark-theme. While they fixed up the styles for the scrollbar in WebKit, they failed to do anything remotely similar in Internet Explorer. I’ve notified them (and might have gotten their attention), so let’s hope they get word and make these changes. You can make similar changes in your applications using scrollbar-face-color and related properties (See the “see also” section on the previous link).

I must admit, it would be awesome if we could control the properties of the scrollbar by setting properties on a pseudo-element instead of on any element that scrolls. It’s worth noting that in this territory, there currently is no w3c-accepted standard.

IE uses a proprietary extension in the form of prefixed-properties, and WebKit uses a proprietary extension in the form of prefixed-pseudo-elements. One can only hope there will be a consensus and convergence in implementation.

No Case of the Mundays

Today was my first actual day of work in Internet Explorer. I mean, I’ve opened it up here and there during work in the past, but today I spent all of my time in Internet Explorer – and it went well. Nothing broke (that I noticed), nothing was complicated, all was well.

I did work on a CSS example for somebody today only to have them say “the antialiasing sucks,” but as it turned out they were viewing in Chrome, and I was viewing in Internet Explorer. Sure enough, if you create a hard-edge on an angled CSS gradient, it looks better in Internet Explorer than it does in Chrome. Here’s a quick comparison between Chrome 25 and Internet Explorer 10.


This particular gradient is 25deg – oddly enough, Chrome draws a beautifully-smooth line when the gradient is changed to 45deg rather than 25deg. Don’t ask me why – I haven’t the slightest clue.

OMG, Tuesday!

Wow, so today was a big day. When I started this blog post I was a little bummed that the only people able to take the IE Challenge would be those who have purchased Windows 8, or a machine that came loaded with Windows 8. This morning at 6am PST, the IEBlog announced Internet Explorer 10 for Windows 7!

On to my day though – today was spent largely in Google Docs. I noticed there were some small layout differences between Chrome and IE. For instance, the number of characters you can fit on one line before a wrap occurs differs in Chrome than it does in IE. This was particularly bothersome since one of my templates features right-aligned text left-padded with enough spaces to complete a full line of characters. All of these characters are then set with a dark background color.

I wound up taking an alternative route, replacing this approach with a single-cell single-row table, and setting the background color of the cell instead of the background color of the text. This was far better and gave far more consistent results between IE and Chrome. No clue who is to blame, or what was the means by which both browsers diverged from one another, but Chrome appeared to hold itself together better overall when it came to Google Docs.

Wednesday, Thursday, and Friday

So at this point it’s just difficult to find things to blog about. I instinctively click on the Internet Explorer 10 and go straight to my browsing. I don’t experience any issues with my favorite sites. I tweet using TweetDeck, check in with Mom on facebook, drop images into imgur, broadcast using Google Hangouts, manage a channel on YouTube, help out where possible on StackOverflow, and blog about all of it here in WordPress – no issues. Everything just works.

I don’t mean to give the impression that there isn’t any work to be done – there is, a lot. Sadly, while the Internet Explorer developers have been doing an amazing job with their product, we (the community) need to step up our game as well. We’ve got to start writing better code, and paying attention to language specifications and APIs, as well as the ways in which they’re implemented in various browsers.

I came across another “my site doesn’t work in IE” thread today. The website popped up in Quirks mode. Changing it to Standards didn’t magically fix it (as it does from time to time). Instead, pushing it to Standards mode resulted in an even more damaged experience.

The problem here was written all over the Source: apathy, carelessness, and so much more. We aren’t teaching passion for our craft today as well as we should. We teach people how to hammer out some markup, and then encourage them to feed off of the visual presentation, rather than the compliance to the specification (too). New developers code, and refresh, code, and refresh. Rarely, if ever, making a trip to

In early 2012 I came across a rather iconic website that was rendering well in Chrome and Firefox, but the side-bar navigation (made up of lists within lists) was severely broken in Internet Explorer 9. The problem wound up being an unclosed list item; I modified the response in Fiddler, issued a new request in IE9, and the page magically worked. This designer tested their markup in a browser that deviated from what the code explicitly requested (nasty nesting), and instead did what it thought the designer intended. While this resulted in the proper formatting, it breaks the web.

This was something I grew to appreciate in Internet Explorer 9 – it was brutally honest. You got what you asked for (generally speaking), and when your document was looking ugly, it was because your code was telling it to. Other browsers would implement a dose of speculation into its rendering process, which adds far too much variability to the web.

Not Perfect, But Better

A week of using Internet Explorer as your primary browser convinces me of at least two things: 1) Microsoft has come a long way with their product, and it deserves a second look. And 2) There’s still work to be done. While surfing the web on Internet Explorer 10 doesn’t feel like sucking on broken glass, it still leaves some areas for improvement.

I try to be a little less critical about massive software, given the enormous complexity to create, develop, and maintain it, but there are areas where Internet Explorer 10 can be improved. I come across these items from time to time, and try to create simplified reproducible examples when possible to share with others (and with whomever I have access to within Microsoft). One such issue is the :hover bug related to table-rows. You can see this online at (Tested in Internet Explorer 10 on Windows 8 only).

Even with its flaws, Internet Explorer is still leading the way in other areas. It’s currently one of the only browsers to support pseudo-element animation, the Pointer model (though you can get ‘Pointium‘), and some CSS level 4 text properties.

My biggest concern lately is not with the browser itself, Microsoft has convinced me that their product is reliable. What concerns me lately is with the release cycles. Can they keep this new browser breathing, or are they going to continue resuscitating it on a bi-annual cycle? If so, we’ll quickly find the web moving out ahead of it again, and history will repeat itself. I find a glimmer of hope in the newest “About Internet Explorer” dialog.

Install New Versions Automatically

In my sincere opinion, Internet Explorer (in just a few years) went from being the bane of my existence (#somuchdrama), to being a bright luminary, back competing in the pack of modern browsers. Will it stay among the pack? Time will tell. Until then, welcome back Internet Explorer.

Download Internet Explorer 10, give it a week, and post your results below.

Flexible Browsers

I overheard a comment a few days ago that a friend made regarding the default layout of Internet Explorer; namely its placing of the address bar inline with tabs. This results in reduced space for tabs, thus reduced title lengths, thus reduced efficiency managing multiple tasks in parallel.

Chrome, on the other hand, places the tabs above the address bar, giving the impression the address bar is part of the tab currently-opened tab. Firefox, and Opera both also place the tabs above the address bar. Every browser appears to write in stone their tab-placement – though Internet Explorer appears to show the most flexibility.

Upon exploring Internet Explorer following my friends comments, I soon found that I could resize the address bar, re-arrange the stop/refresh buttons, drop tabs down onto their own line (or leave them inline), reduce certain toolbars down into command buttons to minimize space-used. Needless to say, I was pretty impressed with just how much flexibility I found in Internet Explorer.

Here are a few arrangements I went through:

Exploring Varation in Internet Explorer's Layout
Exploring various customizations of the address bar, tabs, and more in Internet Explorer.

As previously mentioned, the above shows the resizing of the address bar, shifting of the stop/refresh buttons from the right over to the left (easier to avoid accidentally clicking the Compatibility View button), dropping tabs onto their own line (you can leave them inline, if that floats your boat), collapsing toolbars like the LastPass one into the command region, and making it inline with the favorites.

Of the four browsers I checked, Chrome appears to be the most rigid. As for customization, you can change the theme, but this is really not much more than swapping out a background image on browser itself. You can’t change the address bar width (well, you can resize the add-on bar, which results in a longer/shorter address bar), the placement of the tabs, the locality of the buttons or anything. You can, however, toggle the “Home” button on and off.


Both Firefox and Opera have really impressive options for customizing your toolbars, but that might be a degree of control that few people enjoy. I personally explored it, but didn’t find it too appealing. Also in Firefox you can disable tabs until you explicitly request to open a link in a second tab. This too reduces used-space around the “chrome” of the browser.

Opera sports an even more advanced set of options for Tab Bar Placement. While tabs at are traditionally at the top of the content (following their real-world exemplar of manila folders), you can place them on any side of the viewport in Opera. The changes of the layout are pretty drastic, so I apologize for the disorienting effect of the following gif:

Tab Bar Placement in Opera.
Tab Bar Placement in Opera.

My take-away is that Chrome is nice on the eyes, but far too rigid with the layout options. Opera and Firefox go to the other extreme, and drop enough tools in your lap that you’d need an engineer’s manual to truly understand the power you’ve been given. Internet Explorer hits closest to the sweet spot in my sincere opinion. While I wish Internet Explorer had a few features we’ve come to love in its competition, I am happy with the degree (and limits) of flexibility Microsoft has chosen to provide.

Use Vendor Prefixes Carefully

Vendor-prefixed properties and values in CSS are a beautiful thing; they allow you to do some really awesome stuff that would otherwise require a copy of Photoshop on your machine. In mere seconds you can whip up gradients, reflections, and even animations.

All of this is so appealing that people forget the fact that these are prefixed for a reason – they’re experiments, and should be viewed as such. That doesn’t mean you can’t use them, it just means you need to do so cautiously.

Don’t use these features in such a way that your page is severely broken without them – that’s not cool. Don’t use them in an unbalanced way either, providing prefixes for one browser but not for the others. And don’t use them in an anachronistic way, giving higher priority to prefixed experimental implementations over un-prefixed standardized implementations.

Often times I come across CSS that looks like this:

.gradientBox {
  background-image: linear-gradient(0deg, red, green);
  background-image: -moz-linear-gradient(0deg, red, green);
  background-image: -webkit-linear-gradient(0deg, red, green);

There are a few problems with this. For starters, only Firefox and Chrome/Safari are accounted for in the prefixes. It may very well be that Internet Explorer and Opera have provided an implementation under their own prefixes, -ms- and -o- respectively. You should provide for those as well.

Additionally, the unprefixed (which would be the standardized implementation) property is at the top, meaning it will be evaluated first, followed by the others. This means if you visit the page in a browser that supports both a -moz- prefix, and it’s unprefixed alternative, the un-prefixed implementation will be tossed out in favor of the experimental prefixed version – this isn’t cool.

So how should it look?

.gradientBox {
  background-image: -webkit-linear-gradient(0deg, red, green);
  background-image: -moz-linear-gradient(0deg, red, green);
  background-image: -ms-linear-gradient(0deg, red, green);
  background-image: -o-linear-gradient(0deg, red, green);
  background-image: linear-gradient(0deg, red, green);

The browser evaluates the rules from top to bottom. Internet Explorer will ignore any -webkit- properties, as well as any -moz- or -o- properties. If it supports the -ms- prefix, it will implement this rule. When it comes to the un-prefixed version, it will determine whether that value is supported or not. If it is not, it will be ignored, and the -ms- implementation will remain. Otherwise, the un-prefixed version will take precedence over the prefixed version. The same flow exists for the other major browsers.

But that’s a lot of writing, right? Fortunately we have a lot of great tools today that can reduce the effort on your page. From pre-processors like SASS and Compass to entire editors like Microsoft’s Visual Web Developer 2012, many options exist that will fill-out these values for you. We even have a great JavaScript option in -prefix-free which lets you write only the un-prefixed version – it will determine the appropriate prefix (if necessary) and insert it when the page is loaded.

Bottom line is this, we can enjoy these experimental features without breaking the web for people. If you’re going to use prefixed properties and values in CSS, do so wisely.