Let's Push Things Forward
January 26th, 2010 by Rob Larsen
Here are the numbers for DrunkenFist.com in the year 2009. There were 614,333 visits to that domain last year and the top browsers broke down like this:
| Browser | # of Visits | % of Visits |
|---|---|---|
| Firefox | 342429 | 55% |
| Internet Explorer | 162977 | 26% |
| Chrome | 35801 | 5.8% |
| Safari | 33545 | 5.4% |
| Opera | 22826 | 3.7% |
January 23rd, 2010 by Rob Larsen
Owing to the contrast on the A/V system, my last slide was illegible, so here are all the links that folks couldn't see.
The presentation itself:
HTML5 + WordPress
And the resource links:
The working group
http://www.whatwg.org/
Mark Pilgrim's HTML5 book
Dive into HTML5
The Modernizr library
Modernizr
The outliner
http://gsnedders.html5.org/outliner/
The post talking about Kubrick
I’m Messing Around With an HTML5 Version of the Default WordPress Theme
My other sites:
DrunkenFist.com (art portfolio)
@robreact
I'll have video of the presentation up shortly (I hope!)
January 22nd, 2010 by Rob Larsen
Yes, I'm still helping out with screening candidates. I haven't yet interviewed someone to replace me, but there's still a week to go.
Anyway, we've had a couple of technical questions that candidates universally failed to answer. Why share them here? For starters I just want to know if we're crazy to expect people to know these. I also like the idea of a kind of "easter egg" for candidates. If someone does enough research to find my blog and read this post, they've shown me something, even if it's not the answer to one of the questions posed below.
The two that have surprisingly turned into stumpers (at least for the last five or six folks I've interviewed)
hasLayout?body text to .625em?And the bonus question that I want to ask, but don't, because it's kind of goofy to say out loud
Answers after the jump.
Read the rest of this entry »
January 20th, 2010 by Rob Larsen
Interesting reading. Here's the salient bit:
Or, more simply: If we use Google’s JavaScript Library CDN, we are asking the majority of our website visitors (who don’t have jQuery already cached) to take a 1/3 of a second penalty (the time to connection to Google’s CDN) to potentially save a minority of our website visitors (those who do have a cached copy of jQuery) 1/3 of a second (the length of time to download jQuery 1.3.2 over a 768kps connection).
That does not make sense. It makes even less sense as the download speed of your visitors increases. Try to avoid serving 20 or 30 kilobytes of content at the cost of using a 3rd party just doesn’t make sense.
We've used the Google CDN to serve jQuery at Cramer with no obvious complaints and I heartily recommend using the configurator/CDN option that Yahoo offers (for the unitiated, it builds a "just what you need" package to grab from their CDN, so you don't have to serve every YUI Module just to do x), but Billy Hoffman's article definitely makes me rethink the former.
If you didn't live through it (and I didn't live through the whole thing), now you can revisit the strange history of the user-agent string in just a few, well-written, minutes.
I hate me some browser hacks. But that's a mighty fine list.
We spent about 45 minutes running variations of the one-liners above in the console during a code-review last week. Fun times.
It sounded like this a couple of times:
"Wait, what?"
…
And finally… are you enjoying the jQuery advent calendar? I'm interested in running jQuery 1.4 against the demo code I build for my library presentation. I expect to be bowled over.
January 14th, 2010 by Rob Larsen
This is my old pattern:
<!DOCTYPE html>
<html lang="en-US">
<title>Internet Exploder</title>
<link rel="stylesheet" href="/_assets/styles/styles.css" />
<!--[if gte IE 5.5]>
<![if lt IE 7]>
<link rel="stylesheet" href="/_assets/styles/ie6.css" />
<![endif]>
<![if IE 7]>
<link rel="stylesheet" href="/_assets/styles/ie7.css" />
<![endif]>
<![if gt IE 7]>
<link rel="stylesheet" href="/_assets/styles/ie8.css" />
<![endif]>
<![endif]-->
</head>
<body id="home">
Simple. It serves a new style sheet to various versions of IE as needed. The bad thing is the extra HTTP request added onto the Microsoft browsers. I'm not even there yet, but during one of my interviews for the new gig an alternative was suggested- using conditional comments to append a different class to the html element and letting the cascade sort it out.
I liked that idea.
Read the rest of this entry »
December 10th, 2009 by Rob Larsen
The answer is no 
While some of the functionality of MS's CSS filters is actually pretty useful (sue me, I need to use them from time to time), the implementation is ugly as hell. Ryan, one of the smart guys here that helps me fool people into thinking I know what I'm doing, had to implement the Microsoft gradient filter as a (brilliant) hack for a performance issue on a small subset of IE browsers. We were discussing the solution and then he called up the code.
Read the rest of this entry »
December 9th, 2009 by Rob Larsen
These are the posts that have kept me engaged during my quiet moments this week.
Demystifying jQuery .live() and why it’s generally faster than .bind()
A short article looking at jQuery's .live().
Just what it says it is- a big-ass list of algorithms. I wish more had source code.
Using a VPN Clobbers IE 8 Performance
The folks at HttpWatch detail the ins and outs of the way that IE8 handles their enhanced connection rules. The browser is set to use 6 open connections, but only when a broadband connection is in use, so there are situations where it can fall back to using just 2.
(down)Loading JavaScript as strings
Steve Souders is a font of performance wisdom. I wish I'd been able to check out the Velocity Online Conference today.
Technically speaking, what makes Google Chrome fast?
Front end engineers can learn much from the people who make browsers. That's the case here. The video content is excellent.
Computer science in JavaScript: Base64 encoding
This is a great series, moving the discussion of JS beyond the browser and the DOM and into a more primary, and therefore really interesting, realm.
November 30th, 2009 by Rob Larsen
Once thing that's vital to testing the accessibility of a web app or site is running through it without using a mouse. If you can successfully work a site or app without touching the mouse, you've gone a long way towards ensuring that your site is available to a wide range of people and devices.
One thing that's difficult about that process is most of us rely far too much on the mouse when browsing. Which is where these lists of keyboard shortcuts for Firefox, and Internet Explorer come in handy.
Read the rest of this entry »
November 4th, 2009 by Rob Larsen
Conditional Compilation is a handy, Internet Explorer specific method for forking bits of JavaScript. The nice thing about it is that real browsers don't notice it at all. It just looks like a comment block to any non-IE browser. Which saves the rest of the world from even having to if (IE) { } else { } . I like that.
Anyway, we use it to fix some of IE's shortcomings. One standard pattern is using it to fake the :hover pseudo-class on inputs in IE6. Something like this:
//IE6 HOVERS simplified//
//this would be a bit different in protection
//but you can see the idea
/*@cc_on @*/
/*@if (@_win32)
var inputElements = document.getElementsByTagName("input");
var test = inputElements.length;
for (var i=0; i<test; i++) {
if (inputElements[i].getAttribute("type") == "submit"){
inputElements[i].onmouseover = inputElements[i].onfocus = function(){
addClass(this, "hover");
}
inputElements[i].onmouseout = inputElements[i].onblur = function(){
removeClass(this, "hover");
}
};
};
/*@end @*/
//END IE6 HOVERS//
September 29th, 2009 by Rob Larsen
I did some testing today with Google Chrome Frame. I wanted to see if it would mesh with my normal methods for serving IE specific code and, as far as I can tell, it behaves exactly as desired.
Here's the code I used to test
Read the rest of this entry »