Recent Reading (JavaScript Library CDNs, User-Agent Strings, Hacks, Hacks and Hacks)

Posted on by Rob Larsen

Should You Use JavaScript Library CDNs?

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.

History of the user-agent string

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.

Comprehensive List of Browser-Specific CSS Hacks

I hate me some browser hacks. But that’s a mighty fine list.

Detecting browsers javascript hacks

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.

I’m Messing Around With an HTML5 Version of the Default WordPress Theme

Posted on by Rob Larsen

WordCamp Boston is less than a week away, and as part of my presentation I wanted to show the new elements in an environment that basically everyone that works on WordPress sites will recognize- the default theme. To that end, I mocked up a functioning HTML5ized version of the home page to use as an example. That was both easy and fun.
Continue reading “I’m Messing Around With an HTML5 Version of the Default WordPress Theme” →

Rethinking the “How To Serve IE-Specific CSS” Question

Posted on 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.
Continue reading “Rethinking the “How To Serve IE-Specific CSS” Question” →

Recent Reading (30 Style Tags?, YUI 3, GodMode, Git, Jira)

Posted on by Rob Larsen

Once again rounding up some of the articles I’ve read over the past couple of weeks.

All style tags after the first 30 style tags on an HTML page are not applied in Internet Explorer
I wasn’t surprised to see this came up as an issue in the Drupal community. During my short time working with Drupal, I was horrified by the number of style sheets/JavaScript files included in the page. I don’t think we ever got to 30, but 10-15 was scary enough. Apparently, there’s a “performance” mode which clears that up, but I never made it that far…

Inheritance Patterns in YUI 3
I’m really interested in getting to know YUI3 and inheritance patterns in JavaScript are interesting to me in any form, so this article by Stoyan Stefanov was a must read.
Continue reading “Recent Reading (30 Style Tags?, YUI 3, GodMode, Git, Jira)” →

In Case You Missed It…

Posted on by Rob Larsen

Mark Pilgrim published his chapter on the new HTML5 form input types:

A Form of Madness

Everybody knows about web forms, right? Make a <form>, a few <input type=”text”> elements, maybe an <input type=”password”>, finish it off with an <input type=”submit”> button, and you’re done.

You don’t know the half of it. HTML5 defines over a dozen new input types that you can use in your forms. And when I say “use,” I mean you can use them right now — without any shims, hacks, or workarounds. Now don’t get too excited; I don’t mean to say that all of these exciting new features are actually supported in every browser. Oh goodness no, I don’t mean that at all. In modern browsers, yes, your forms will kick all kinds of ass. But in legacy browsers, your forms will still work, albeit with less ass kicking. Which is to say, all of these features degrade gracefully in every browser. Even IE 6.

We used the basic ones on the AWiderNet redesign. Quick review: I like them (by basic I mean email, url, etc) as they parallel the things I’ve been doing all along. Beyond the possible user agent enhancements, I’m happy to be able to target CSS using attribute selectors instead of meaningless* classes.

I’m really excited for support for the “fancier” new types. There’s a lot of code overhead out there in the wild for things like sliders and date pickers. Having native controls for very common elements is a big deal.

*Meaningless in that User Agents can’t infer anything from class="email". Clearly humans editing the code can guess what class="email" is all about…