The goal to make your site look cool, be easy for people to use, and be available for all, is a holy grail trifecta that is rarely achieved. Many times, you have to sacrifice one leg of the tripod in order to achieve your goals.
The advent of Typekit has led to a lot of websites using cool custom fonts in a way that is supposed to solve that age old problem of what happens when you design your site with a font the end-user doesn’t have. For a very long time I couldn’t understand what the big deal was, since I often read these sites from work, and their fonts were all jaggedy and ugly. Then I fired up a site from home and was astounded at the difference.
This is what I normally see when I go to TypeKit:

This is what you’re supposed to see:

I know it doesn’t look too bad, but basically what I don’t get are the nice, smooth, edges on fonts, so when I read a whole page like that, it’s hard on the eyes. TypeKit works by javascript, so arguably, it should work on all browsers with JS enabled (which is to say all modern browsers). I’m using Chrome (latest and greatest) and I get crap.

That’s from Ed Jeavons’ Beyond web-safe fonts with Typekit, which is a great article. But the whole thing is unreadable to me because of that.
So where is the break down here? TypeKit’s goal is to make their fonts work on every site, regardless of if you have the font installed on your server. Jeavons says “Typekit degrades gracefully so that anyone without JavaScript, or with a browser that doesn’t support the necessary features, will simply revert to your standard CSS rules.” If that was the case, shouldn’t I be seeing a better site?
According to TypeKit, the problem is that the sites I’m seeing didn’t make good standard CSS rules. My anecdotal evidence suggests otherwise. After all, every site I go to has the exact same problem. So I turned off javascript and went back to the site:

Now that looks like you’d expect graceful degradation! At this point, my answer is that something TypeKit does is unwelcome on my office computer. Or more likely, my office firewall. That’s a whole new kettle of fish. I can’t reasonably expect everyone to go find an office behind a firewall made of adamantium and test their site. But clearly this is not the fault of the individual site. Is it reasonable to expect TypeKit to look into this? I went on a search and found they have a cool little checker too typecheck which says I’m fine:

There’s nothing in their FAQ or help desk that mentions Firewalls having this issue, so I decided to check out Google Web Fonts. Lo and behold, I get the same problem. Some more digging and I found someone who ‘fixed’ the problem using css. My Twitter friend @cgrymala suggested I also try ClearType, since I’m on Windows XP at work. That actually helped a lot (seriously, I cannot tell you how much nicer things look) but the main problem is still there.
Where’s my problem? My problem is that TypeKit and Google Web Fonts, while they purports to be a one-size-fits-all/degrades-nicely app, are not. If you’re not on the forefront of technology, if you’re behind a firewall, if you’re on a weird setup, these things are not going to work. This is not really TypeKit’s or Google’s fault. They’ve done an amazing job setting things up so it works most of the time. At best, they could have their javascript detect browser and OS (yes, you can do these things) and if it’s IE 6 or Windows XP (for example), revert to the javascriptless version of the site.
It’s nigh impossible to solve the firewall problem. You can’t detect the firewall easily, and part of the point of them is they obfuscate who and what they are. And if the problem is a combination of OS, browser and firewall, then the best you might be able to do is somehow detect if any one of those three are on the known ‘possible’ trouble list, and shunt them off to a non-js version. And now you’ve added a lot more load to your server.
The best you can do is to avoid using these cool systems and features until they’re more supported, which is where the whole concept of sacrifice comes in. If it’s more important for you to have your site look cool than to work for everyone, you have to find a way to degrade better. For a long time I had an alert bar on my site to tell you that if you were using IE 6, you needed to upgrade. Going back further, we used to regularly make sites that said ‘Best viewed in Netscape Navigator.’ Thankfully sanity struck, web standards started to stick, and we began to design sites that looked good in most browsers.
I cannot advocate a return to ‘Best viewed in…’, but I can suggest that if you’re relying heavily on cool, cutting edge, features, you also have a printer-friendly version of your site that runs without any of the bells and whistles.


I’m going to be bold and tell you that the new EU law, that goes into effect in the UK on May 25th, is going to be impossible to track and enforce, it’s being handled backwards, but besides that, it’s actually a pretty good idea.
That’s a pretty hefty thing to get through, but it clearly spells out that third party cookies are when they’re on about. And in that, they’re right. There should be transparency to all this. We should know when we’re being tracked around the internet. But they’re wrong in making this the sole responsibility of the website owners. This is not to say that, as a website owner, I’m not responsible for the cookies my site puts down. And this is not to say that, as a website owner, I’m shouldn’t tell people how cookies and personal information I collect are used on my site. But to say that the ‘solution’ is for me to alert you with “Hi, the EU says I have to tell you about cookies and make sure you’re okay with them on your computer.” or not to use things like Google Ads, Facebook Like buttons, or Twitter integration is unenlightened.

We’ve all been there. One day you’re out enjoying the net, and the next you have a complete and total turd making your online life hell! What do you do? There are a lot of answers to this, but really it boils down to two types of reactions. You have to change your behavior, and you have to change your online accessibility.
This won’t stop everything, of course, and I generally spend a bit of time with my firewall (I use 
Not to be too heavy handed, but with our code, it’s the same thing. We cannot see where too-far in our code, where danger lies, until it hits us in the face. We will destroy our programs over and over, we will crash our servers, and infuriate our customers, but we will pick up the pieces and learn and make it better the next time. This is human nature, this is human spirit and endeavor. We cannot fear failure, even if it brings death. For most of us, the worst it can bring is being fired, but really that’s not that common. I’ve found that if you step up and accept responsibility for your actions, you get chastised, warned, and you keep your job.
