News, insights and inspiration about customer engagement.

Posts by Steve Schrab

Using Asynchronous Typekit and LESS for Great Justice

by Steve Schrab on March 27, 2014

Using Typekit and LESS togetherLately we’ve been messing around with a tool called It analyzes your website’s speed and performance based on performance best practices and metrics. It collects data from multiple pages on your website and analyzes the pages using its rules. Trying to reduce file sizes, http requests, and other problems almost becomes a game in an effort to get the overall score higher. But it’s no game, as the speed of your website can have a great effect on your user’s experience.

One of the things that comes up on a number of sites is JavaScripts that synchronously load in the head. Synchronously loaded code stops the browser from loading and displaying anything else until it’s finished loading that code. Typically we like to avoid synchronous code in the sites we write, but sometimes we use third-party code that isn’t written to be asynchronous. One of the big ones we use on a number of sites is Typekit.


Mom! Dad! It’S FOUT! Don’t touch it!

Typekit likes to synchronously load so that you avoid FOUT. FOUT stands for “Flash Of Un-styled Text.” It’s when your text loads into the page using the browser’s default fonts but then suddenly swaps to your web font when it finishes loading. So Typekit synchronously loads to avoid showing anything before the font is downloaded. Which, most of the time, avoids FOUT. But synchronous loading slows things down. The browser stops everything before loading other assets.


Asynchronous Typekit

Typekit does have the option to asynchronously load. When you get the embed code, you have the option of getting the “advanced” embed code, which is asynchronous. If we asynchronously load Typekit, the browser can start multiple download threads to get all of the page’s assets at the same time. That speeds up the site and also doesn’t stop the rendering of the page while you wait for stuff to load.

The downside is that you bring back the possibility of FOUT. Now Typekit also offers CSS callbacks, which will tell you when the fonts are loaded and available. Their suggestion is to hide the elements that include their fonts when the “wf-loading” class is present on the HTML tag.

This is a good solution, as it won’t display your fonts until they have downloaded from Typekit. However, writing all of that extra CSS to hide elements that use the fonts seems like a pain. Luckily, LESS makes it easier to include if you set things up right.


Setting Up LESS Functions For Your Font Stack

When using LESS, I’ve taken to the idea of setting up Typekit fonts as a function. For example:

.facit-bold-italic (@size: 16px, @height: 1em) {
	font: italic 700 @size/@height 'jaf-facitweb',sans-serif;

This means that instead of writing out a long font property in CSS every time you want to use a font, you can just call it out by name in the CSS. Like so:

.cool-box {
	border-radius: 4px
	background: #ccc;

Because the arguments in the function have defaults of 16px size and 1em line height, it’s optional to set them when declaring the font. So if you want your font to be 16px with a 16px line height, you can just put this:

.cool-box {

Or even just supply the font size if you want the line height to be the same as the size:

.cool-box {

It’s neat! Yes, this is my idea of fun.


LESS and Typekit

I like making these functions, as it creates a nice list of the fonts I have selected in Typekit that are usable by the site I’m working in. Plus it allows me to just refer to the font by name. Which I personally find easier (your mileage may vary). But how does this help with asynchronously loading Typekit and avoiding FOUT? Because it’s LESS, we can easily add rules into these fonts that adhere to Typekit’s callbacks.

.facit-bold-italic (@size: 16px, @height: 1em) {
	font: italic 700 @size/@height 'jaf-facitweb',sans-serif;
	.wf-loading & {
	    visibility: hidden;

Now whenever we call this LESS function in our CSS, it’ll not only have all of the correct font stuff, it’ll bring this hook along that hides the font while we’re loading Typekit.

So we’ll have a speedier site, no FOUT problems, and our code is still easy to manage.


Are Art Directed Web Articles Out of Style?

by Steve Schrab on December 23, 2013

Art Directed Articles Before and AfterGood ol’ Chris Coyier revisits his thoughts on the subject of “Art Directed” articles – one-off article designs that give individual styling to one particular article. All the rage a few years ago but has seemingly fallen out of style these days.

There are some good pros and cons on both sides, but some small amount of research in the article shows that many of the “art directed” articles made in the 2009 era have either been brought into a template, gone missing, or stopped working. Meaning the amount of work to keep these articles maintained through various redesigns (probably to make a site responsive) just became too much work for site maintainers. There’s a good chance that the articles that have survived have done so because their site has been left mostly unchanged since its introduction.

It’s a good idea, especially as your site gets larger, to keep your content data independent of your design structure. This way as your site’s design evolves, its content can flow freely and easily between designs.

Does this restrict the design process? Not necessarily. It just means there will need to be even greater collaboration between designers and devs moving forward. Design and development problem-solving becomes a team effort.


Google to Encrypt ALL Keyword Searches

by Steve Schrab on October 31, 2013

Google logo

This is a fun article for me:

It talks about Google’s decision to encrypt all keyword searches for users who are logged in or not (apparently logged-in users already had their searches encrypted). The reason? Privacy. There’s a lot of talk about the NSA looking into everything that’s happening on the Internet, so this is Google’s attempt to make its users feel a little more secure.

Google’s doing more to protect its users? That’s great, right? Who wouldn’t like that?

Well, the article above is written from a marketing perspective. Particularly those of the SEO (Search Engine Optimization) and SEM (Search Engine Marketing) persuasion. Encrypted searches means no more keyword data. Which essentially means SEO/SEM business is about to get a lot tougher. And many seem none too pleased about it.

I say “Huzzah.”

With less emphasis on SEO/SEM, I think we all could just concentrate on making better websites. Websites with better content that aren’t just meant to pimp out a few keywords here and there to move up a position or two in the rankings. Even though a majority of the article seems to be written like the sky is falling, there’s a gem of a quote in there:

“Great SEO today is great content with powerful digital endorsements from relevant and authoritative websites, which results in business results that transcend the keyword conversation.”

Plus if it means the death of SEO Snake Oil Salesmen, all the better.


Should Designers Write Code?

by Steve Schrab on August 28, 2013

There are some interesting articles on the debate of designers doing their own code (by code, they mean HTML + CSS + JavaScript).

The position held by a lot of bigwigs in the field is, yes, designers should code. So this article stirred up a lot of attention by essentially saying, no, they shouldn’t.

The crux of the argument is that you’ll spend too much time sweating the details of code instead of honing your design skills.

Then there was a counterpoint to the article.

This article points out that having designers in control of the presentation layer results in a presentation that more closely conforms to the designer’s intent.

In the updates, he does go on to say,

“Some commenters are coming to the conclusion that I believe designers must code. I think that’s nonsense too. The world of digital design is big and varied. (And yes, many of us work beyond the web–gasp!) The skill sets required on any one project are too big to live in one body. So … multi-skilled people? Yes. Designers must code? Nope.”

I think that’s a great takeaway. Designers who can write their own code can certainly get their designs as intended in the web browser. Designers who don’t worry about code are free to think outside of the box a bit. They can come up with new ideas, which a Front-end Developer, like me, can accept as a challenge to figure out how to make a design work within a system (RE: box). You can get great design either way, but having an understanding of code and how a page is assembled is what separates a web designer from a graphic designer.


Typographical Orphans Begone!

by Steve Schrab on November 1, 2012

Not long ago, I wrote my first jQuery plug-in called deOrphan. It's a plug-in for removing typographical orphans in text elements you specify. What are orphans? An orphan is a single word that appears by itself at the end of a paragraph. There’s more info on Wikipedia if you're interested.

This script goes through a list of elements, looks through their text, and finds the last two words of the elements and joins them together with a non-breaking space. The result can be seen below.

deOrphan - before and after example

There are other options for server-side plug-ins that can do this, but I'm not aware of too many client-side scripts that do this. This can helpful when you don't have control over the server envorinment you're building on.

It's an extremely small detail, but since it doesn't take much effort to implement it, why not do it? I'm not even asking you to go the extra mile, I'm just asking for a few steps.



Nerd Superbowl (aka 2012 Apple WWDC)

by Steve Schrab on June 21, 2012

Apple WWDC 2012Last week Apple had its Worldwide Developers Conference (WWDC). As some of our regular readers may have guessed, there are quite a few Apple fans at GS. Apple no longer live-streams these events, but that doesn’t stop a few of us from watching the play-by-play action from live bloggers. It’s literally a text feed from attendees of the event that’s updated more than once a minute. That way we can get our fix of what awesome things Tim Cook and the gang are talking about as they happen. Could we wait for the video to be posted a few hours later? Sure. But what fun is that? There’s an excitement at an Apple event that just isn’t matched by any others in the industry. There’s a mystery around the event due to Apple being so tight-lipped about any unannounced products. Being so secretive creates a rumor-mill feeding frenzy, which gets many fans even more excited about what will happen. There’s this sense that Apple could really announce anything, and the world could suddenly change from underneath us. That would probably come off as a fan-boyish statement if it hadn’t happened before ... multiple times.

Love them or hate them, Apple is the company to watch. They’re a leader in the industry and always looking for ways to re-invent how we use technology. Even when Apple announces technology that follows the industry, that product is such an improvement over what was previously available that they’re able to “own” it. They’re envied and emulated by just about everyone in and out of their industry.

Back in the mid-90s they were nearly dead. Stock value was in the toilet, product line was stagnant, and some analyst said Apple should just start making Windows clones. Can you imagine? When Steve Jobs took over he made some bold decisions that moved the company forward and made them innovate again. From there they’ve risen to one of the most valuable companies in the world. Perhaps it’s this “come-back kid” feeling that has us all cheering for them. Maybe that’s why so many people download what’s basically a 2-hour commercial of them unveiling their latest offerings.

But don’t take my word for it. Watch the 2012 Apple WWDC Keynote yourself and tell me you wouldn’t want to be sportin’ one of those new Retina Display MacBook Pros.


New iPad: the Human Eye Meets its Match

by Steve Schrab on March 22, 2012

The New iPadFor those of you not watching Apple’s product announcements like a hawk, just recently they unveiled the new iPad. One of the big, new features is the Retina Display. For iPhone folks, this is nothing new. We’ve had Retina Displays in our phones for a couple of years now. However, we’ve never seen a retina-quality display at this size. It squashes more pixels into a 9.7-inch space than your 1080i HD TV.

Daring Fireball has a pretty thorough review of the The New iPad (3). What jumped out at me was this:

“All of Apple’s software has been updated to retina-caliber graphics. (If they missed anything, I didn’t spot it.) Most third-party apps, of course, have not yet been updated. Just like with the iPhone 4, these up-scaled graphics are passable, but annoying. They stick out like sore thumbs after using true retina-display-optimized apps. Websites, too – most graphics and images on the web are behind the curve, as of today. Text looks great in Safari, but non-retina images look slightly blurry. The iPad display is so good that it shows, like no device before it, just how crummy most images on the web are.”

Web imagery takes a leap with this device. So what’s the best way to take advantage of it? GS has already been moving toward this space of high-res displays in a couple of areas. For example, we’re big proponents of using HTML Text and Web Fonts. New iPad users of sites using web fonts (for example, this one) will be treated to crisp, sharp text! We’ve dabbled with SVG graphics. Again, sites with these elements (for example, this one) will remain sharp and glorious. Another technique to take advantage of is to use more CSS-created elements vs. graphics. For example, using CSS-created rounded corners on elements instead of creating this effect using graphical files. So sites using a lot of CSS-created “chrome” (for example, this one) should scale up nicely on the new iPad. The great thing about these three techniques is that they’re actually more efficient than their graphical variants. They use less bandwidth to deliver and, therefore, download faster and speed up the user’s experience. But where does this leave photographs?

Photographs really have only one way to be properly delivered on the Web. That’s the JPEG format. While this format has done a noble job of compressing large photographs without losing a ton of quality, we’re starting to hit a bit of a bandwidth wall. The obvious solution is just increase the resolution on photos used on the Web. Maybe even do a little client-side sniffing and only deliver those images to users of high-density displays. Problem is, are we really going to ask mobile users who have limited speed or limited bandwidth (or, in most cases, both) to download an image that could be four times the file size? I want my photos to look great, too, but I also don’t want to go over my bandwidth limit each month.

So what’s the solution? I’m afraid there isn’t an easy answer at the moment. While there are solutions, it’s hard to know what the user will want and when. Someone without a high-res display has no use for high-res images. Users of high-res displays may appreciate those slick graphics when they’re on their personal WiFi connection, but they may hate you when they’re on a 3G network waiting forever for images to download and watching their bandwidth get chewed up.

It’s an interesting problem to solve. I, for one, can’t wait to see what it looks like when we strike that balance.

“The Retina Display’s overall effect is like that of high-end glossy magazine print — except that it updates live. It’s living breathing print.” —John Gruber on a Retina Display iPad

Update: July 23, 2012

Want more? Check out this article I wrote for the BizTimes on improving your website to accommodate retina displays.


Practical SVG Usage

by Steve Schrab on December 21, 2011

Scalable Vector Graphic (SVG) files are nothing new; they’ve been around for years. Despite this, we still haven’t seen them used as broadly as they could be. Given that the goal today is to build increasingly responsive and adaptive sites that look great not only on high-res desktop displays but also in the palm of your hand on mobile devices, bypassing SVG is a huge oversight. SVG files shine in this area as they’re completely resolution independent and (typically) have a smaller file size than their bitmapped brethren. If you’re targeting an iPhone with a Retina display, do you really want to make 3G users download a bigger file just to take advantage of that screen? Why not scale a single SVG file without wasting additional bandwidth?

Comparison of PNG scaling versus SVG scaling

Comparison of PNG scaling versus SVG scaling.

Of course, SVG files aren’t appropriate for every image type. Photography is still in the realm of the JPEG, and many sites use photography as their main graphic elements. Where you don’t need photography, CSS3 is able to fill in a lot of gaps as far as design elements are concerned. So, then, where is SVG appropriate? How about one of the first elements to generally appear on a web page – the logo.

The logo

Many logos are already created in vector drawing programs, like Adobe Illustrator. Yet they’re often rasterized and placed on the page as a PNG or GIF file. Why not preserve their original precision?

Consider the following:

  • A brand logo is an ever-present element on your site and one that is found on every page. Spending time optimizing global elements is always time well spent.
  • A logo isn’t simply some random bit of chrome or graphical glitz. To some extent, it can be considered “content.”
  • If you’re into print style sheets, an SVG file’s resolution independence can make your site’s printouts look as good as your company stationary.
  • A logo is a key part of your website. It’s your brand. Your identity. Certainly it’s worth a little extra time and effort.

How do I do it?

In Adobe Illustrator you can save SVG files out directly. In the dialog box, choose the profile SVG Tiny 1.2., which is meant for devices with reduced computational and display capabilities. Sounds perfect for mobile devices, doesn’t it? Uncheck the "Include XMP" box (You have to click “More Options” first). Including the XMP data will add a lot of unnecessary metadata making your file size much bigger. Since this data is irrelevant on the web and we really just want the vector info, we can get rid of it.

Once you have your SVG file, you can link to it using image tags or CSS background images. Previously you needed to link them via object tags, but since we’re not looking to add any scripting or interactivity to our SVG files, linking them via a static image method should be appropriate. However, be sure to tell your server admin to set up a mime type for ‘image/svg+xml’ for your SVG files. It may not be set by default.

In your image tags, you can even set a width as a percentage to make your logo perfectly scalable with your responsive layout. You’ll find your logo looks great at all resolutions, with no multiple image swapping and still just a tiny file. Many of the logo files I've used in SVG format have ended up being as small as 2KB with gzipping. For example, the GS logo on the corner of this site.

What about browser support?

All modern browsers have good SVG support. Many have had it for quite some time. Internet Explorer has support as of version 9. Using a JavaScript library called Modernizr, we can easily test for SVG support and swap a vector file for a well-supported bitmap file. Just put Modernizr on your site, and it takes care of most of the work for you. You'll need to create a fallback PNG file, but by using these methods you can avoid the browser downloading both files.

For example, in CSS just use .no-inlinesvg and .inlinesvg before the selector with your background image.

.no-inlinesvg #logo {
	background: url('logo.png');

.inlinesvg #logo {
	background: url('logo.svg');

For image tags, you can use JavaScript to swap your files.

$(document).ready(function() {
	if (Modernizr.inlinesvg) {
		$('#logo').html('<img src="logo.svg" alt="Your Company" />');

	} else {
		//No SVG.
		$('#logo').html('<img src="logo.png" alt="Your Company" />');

<a href="/" id="#">Your Company</a>

While many browsers support SVG files, they don’t all support SVG use in IMG tags or in CSS backgrounds. For example, using SVG inline has only been supported in Firefox since version 4.0. So the venerable Firefox 3.6 would receive the PNG fallback in this case.

What is the payoff?

The mobile space continues to grow. Android and iOS both have devices with scalable high-res displays. Instead of making bigger high-res bitmaps that will inevitably have a larger file size, simply use a single small SVG file that will look great regardless of how large or small displays become.

On the desktop when you use browser zoom, your SVG files will scale just as flawlessly as your HTML text. What’s more, the latest version of Safari allows you to double tap with two fingers (assuming a laptop trackpad or Magic Trackpad) and zoom your viewport much like you do on the iPhone. Again, your SVG files will scale beautifully.

Speaking of Mac OS X Lion, there’s evidence that future versions of OS X will take advantage of high-res displays. You can scale the display up without changing your resolution. There's similar development within Windows 8 as well. While display resolutions are still not high enough to really justify this, you can see a day where we’ll have a Retina caliber display for our desktop machine.

With a combination of web fonts (for greater use of HTML-rendered text), CSS-rendered graphics (rounded corners, gradients, drop shadows, etc.), and SVG files, we can future-proof (or at least future-friendly) our websites by making them more resolution independent. Sure there are a number of steps beyond just linking to a file, but we can start with one of the single most important graphical elements on our site. The logo. It’s an element that will help you dip your toe into the manner in which we may be making websites in the future.


FED Stuff - November Edition

by Steve Schrab on November 30, 2011

FED Stuff is a collection of the little CSS and Front-End Developer tricks that I’ve learned each month. There is a lot to learn. Some may be new to you. Some may be what you assumed is common knowledge. But we can't know for sure unless we share. This is my attempt to share them. Little tricks add up to big things.

Rich Snippets Testing Tool

This is a great tool by Google for testing rich snippets of microdata, microformats, or RDFa information. This type of information is being used a lot more in search services. Include rich snippets for shopping, recipes, reviews, video, and events, and music. By using this testing tool, you can make sure your rich snippet data is formatted correctly.


Media Queries and Meta Viewport tags

I've been messing doing a lot of work with mobile web apps this past month and found a lot of pain points. For example, setting the viewport to the same size as the device width...

<meta name="viewport" content="width=device-width">

...doesn't necessarily give you the exact pixel resolution width of your device. Many devices give a pixel display much smaller than their screen resolution. The iPhone 4 has a resolution of 960 x 640. Yet if you query it's width, it returns 320px. The manufacturer mostly likely found this the best way to display a web site that wasn't specifically designed for mobile (which most are not). Either way, it can make fitting your design to different sized screens a real pain. Using a combination meta viewport tag and width media queries are the best way to insure your site looks as intended at the target resolution. Though it can require a bit of tinkering to get it right. Read this article at for the full scoop.


Portrait and Landscape Media Queries

Speaking of media queries, detecting Portrait versus Landscape is nothing new. What I didn’t know is that media query isn’t set by the hardware telling the browser what orientation the device is being held at. What it’s doing is testing whether the browser window is taller than it is wide. So if you make your browser window skinny, it’ll swap to portrait mode.

/* Portrait */
@media screen and (orientation:portrait) {
    /* Portrait styles */
/* Landscape */
@media screen and (orientation:landscape) {
    /* Landscape styles */

This is not only cool for detecting the orientation of a device, but you could even re-layout the page for desktop browser windows that are longer than wide. It’s also a great way to do some quick testing.

One more note, older versions of Internet Explorer (8 and less) will not recognize the media query tags within your CSS documents and just render the styles within. So make sure you put the default styles after the changed values so they get overwritten properly. If landscape is your default style, set the portrait styles first, then override them with the landscape ones. Which leads to our next topic …

“Mobile First” CSS and working with legacy Internet Explorer

Nicolas Gallagher wrote great article on some techniques of writing your CSS Mobile First (building your styles up from mobile to desktop) and still working around IE 6/7/8 (which don’t understand Media Queries). He also talks about using Sass (A CSS Pre-processor) can help, but you can still use these techniques without it. Definitely worth a read.


Handy Tools -

A tool that helps you work with the easing functions of CSS3 transitions and animations. It’s pretty pimp.


jQuery 1.7 Released

Probably old news by now as this happened early in the month, but there's a new version of jQuery. This new version features new event APIs of .on() and .off(). From the examples on the press release, it looks like these are unified way of attaching events.



Refresh Your Cache Yo!

by Steve Schrab on November 10, 2011

refresh buttonHow many times have your heard that? You ask a developer to make a change to your website, they tell you it’s done, you go to check it out, and it appears nothing has been done. They speak the phrase they’ve probably said so many times in their life, “It must be cached. Just force refresh.”

For those who don’t know, your cache is temporarily stored files on your computer so future requests for those files can be served faster, rather than re-downloading, say, an image file that likely doesn’t change. Cache can get in your way when it’s caching assets on your computer that have been updated on the server. Most of the time, this isn’t an issue.

While I’m guessing the majority of readers are already familar with cache issues, you may not be aware of quick keyboard commands for your browser to bypass your cache. As a developer, I use these so often that I often bypass my cache every time I hit the refresh button, whether I need to or not.

So without further ado, here’s a handy-dandy list of keyboard commands for bypassing and refreshing your cache:

  • Internet Explorer
    Hold the Ctrl key and press the F5 key.
    Hold the Ctrl key while clicking the refresh button in the toolbar.
  • Firefox
    Hold down both the Ctrl and Shift keys and then press R. (Alternatively, hold down the Ctrl key and then press F5.) On a Mac, use the Cmd key instead of Ctrl.
    Hold down the Shift key and click the Reload button on the navigation toolbar.
  • Safari
    Hold down the Shift key and click the Reload toolbar button.
  • Chrome
    Hold the Ctrl key and press F5.
    Hold the Shift key and press F5.
    Hold the Ctrl key and click Reload button.

Check out this Wikipedia entry for an exhaustive list of ways to refresh your cache in just about any web browser:


FED Stuff - October Edition

by Steve Schrab on October 31, 2011

FED Stuff is a collection of the little CSS and Front-End Developer tricks that I’ve learned each month. There is a lot to learn. Some may be new to you. Some may be what you assumed is common knowledge. But we can't know for sure unless we share. This is my attempt to share them. Little tricks add up to big things.

Using ems

Want to use em units instead of px for a more flexible layout? There’s a little math to it, but it’s pretty simple. Most browsers have a default font size of 16px. The em unit is based on the size of the relative font. So if the page’s font is 16px, that would equal a size of 1em. Simple enough. What if you want a font size of 12px though? That's where this handy formula comes in. This is from Ethan Marcotte's Responsive Web Design. A book I think all Front-End Developers should read (link below).

target / context = result

In this case, 12 divided by 16 = 0.75. So a font size of 0.75em is equivalent to a font size of 12px. You can use this for font sizes, but also any other measurement. Padding, widths, margins, etc. This really helps a layout maintain it’s integrity when a user increases or decreases their font size.



The gist of this JavaScript is that it allows you to write standards based CSS and not worry about vendor prefixes. The script itself runs through your CSS and adds the vendor prefixes that your users’ browser needs. So instead of writing:

-webkit-transition: all 0.5s ease;
-moz-transition: all 0.5s ease;
-ms-transition: all 0.5s ease;
-o-transition: all 0.5s ease;
transition: all 0.5s ease;

You could just write:

transition: all 0.5s ease;

And prefix-free will take care of everything for you. The only issue I've come across is where you need to target older versions of webkit that make use of the “old style” of creating CSS gradients. Other than that, it’s brilliant.



FED Stuff - September Edition

by Steve Schrab on September 30, 2011

FED Stuff is a collection of the little CSS and Front-End Developer tricks that I’ve learned each month. There is a lot to learn. Some may be new to you. Some may be what you assumed is common knowledge. But we can't know for sure unless we share. This is my attempt to share them. Little tricks add up to big things.


Get a little fine tuning on fonts in webkit browsers. Using ‘antialiased’ seems to clean up fonts that are looking a little heavy. I used this on the GS site when the Museo font was looking thicker than it did in Photoshop.

	-webkit-font-smoothing: none;
	-webkit-font-smoothing: subpixel-antialiased;
	-webkit-font-smoothing: antialiased;


:target pseudo class

You can style in-page anchor targets depending on the whether the target was used in the URL or not. For example:

	#supercool {
		font-size: 1em;
	#supercool:target {
		font-size: 1.5em;

<div id="supercool">This is sweet!</div>

So, if you go to the URL of, you’ll see the div with a regular font size. If you go to, it’ll have a larger font size. Or you could use some kind of CSS animation to bring attention to the section you just anchor linked too. Kinda sexy in my opinion.

Changing the “Tap” Color on Mobile WebKit

Allows you to change color of the tap highlight that occurs in mobile WebKit browsers. The default is an opaque black.

html {
	-webkit-tap-highlight-color: rgba(201, 224, 253, 0.8);


Border-radius and IE9

The CSS3 property border-radius is fully supported in IE9. You can even use it without a vendor prefix. However, you need to specify the radius of all four corners of the box even if all those values are the same. While the spec allows you to use something like border-radius: 8px and have all four corners be the same, IE9 requires you to list those values separately. So you need to use border-radius: 8px 8px 8px 8px to get it working.

Thanks a lot IE9.

Rules about styling headings within Section tags

While this is an interesting article about styling heading tags with Section tags, what interested me most was further definition of the often misunderstood section tag.



What’s your favicon strategy?

by Steve Schrab on September 29, 2011

faviconI’ve always joked with my team that the favicon is the most important part of a website. When we start creating a website, the first thing I do is create the favicon. Then I send the dev address around to the rest of the team and proclaim “we’re half done already!” But seriously, I love favicons. They’re just one part of a ton of little details you can add to a site to make it that much cooler. And I really dig putting little fit and finish details on a website.

ICO Favicon

I always start by making a favicon ICO file using Dynamic Drive’s FavIcon Generator. Not sure if there are better tools out there, but it’s worked so far without any issues. This is the file I place in the root of the directory. Some browsers will actually delivery a 404 error if they don’t find it. That could add a lot unnecessary crap to your server log files. So it's a good idea to put it in there and not just for style sake.

PNG Favicon

Next make a 16 x 16 PNG version of the icon. I like to use PNGs because I can take advantage of a full 8-bit alpha channel (it’s still a really small file). The full transparency looks great on tabs in browsers like Firefox where the backgrounds can change. Then, we link to this icon in the head of our HTML document. This link overrides the favicon in the root for browsers that know how to read the PNG file as a favicon. Others will default back to ICO file.

Base64 Favicon

Lately I’ve taken to converting these files into base64 data and putting that into the LINK tag. Google recommends that you avoid making tons of http requests in order to speed up your page. Converting images to base64 converts the image into a text string that you can just include on your document without linking to an image file. The browser then interprets the text string into an image. For example:

<link rel="icon" type="image/png" href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAAcxJREFUeNp80t8r3XEcx/Hv8SM/IhdL6UzRUGTHj3NWqBEJR201NwvHBeUPsNoFN1smkhtKWhQXxG4ou9glSrK2aaE1P7O7JS5YGykcnu96fXV241OPvp/v9/P5vj/vz+f98QQCgZDjOL2IwzZmMYm/zv8tBk1ohg9RGIz2er1zdB4hCb+QgHb9tKlnEEN4iBuUIBl+i3qtSUd4jjNkoxvlOMQTvMU3zd1AAS4tjVV9tMge9ffRahPwBq8ifnb03dpPC/BBL6koVt+LNSyiE8so05htN6D+jJ2B7btCA3/wFSs41TaWEIt0ZZuhDBbw3kMVHB3KR63WhjzkKOC9LUrPL6hGnbKxrPwqbbxWTZOMiLO6C2CtBo22LzzDjipklRrQHTnAGPLdIG6AQvTjXOU6xm9c4R+mkKLvE5jHCzeARytYunMq4Wu80+FZa9B5BLWNLPTYpbP0KlHrlkXPRa1iZ/NAF6weWwjjQtt4aRmE9NNJxGX5jlyUYlyLfNbYns7CWosFeKoXN7J7qfqQiRF0KW13Xlh9n20hUS+W6jR28Rif0KExq86wVk/SuLUEu4l2q4pUATvQdVViKaLEP3TR7A5UqbQ2f/RWgAEA6xlnphy+IP4AAAAASUVORK5CYII=" />

To convert files to base64 data, I use the online base64 encoder/decoder at

iOS touch icon

Finally I make a iOS touch icon. I make a 129 x 129 PNG for this. Might seem like a weird size, but that’s what Apple uses so I figure it must be good. You could just name your file “apple-touch-icon.png” and stick it in the root of your site just like a favicon.ico file and iOS will find it. Now you can make multiple sizes and point to each of them depending on whether you're using an iPhone, an iPhone with a retina display, an iPad, or even an Android device. But I think creating one larger icon and allowing it to scale is the most efficient approach.

I don’t know about you, but I like keeping my directories as clean as possible. Especially the root. So I link to them in head:

<link rel="apple-touch-icon" href="/_images/common/favicon-mobile.png" />

You can also use the rel attribute of “apple-touch-icon-precomposed” if you don't want iOS to add “teh glossy” to your icon.

Is this a lot to process? Granted it might seem like small flourish, but this is just that added touch of branding to your site. This is what makes your site jump out in that long list of bookmarks you keep. It’s just one of the many details we put into our site that is probably under-appreciated.

So, what’s your favicon strategy?


20 Things I Learned about Browsers and the Web

by Steve Schrab on November 19, 2010

The Google Chrome Team has authored an online book addressing some common topics on the Internet. It not only offers awesome examples of what you can do with HTML5/CSS3/JS, but is also a good book about the Internet in general. As a developer, I particularly like the section on how older browsers are slowing down innovation on the Internet. Take a look and let us know what you think in the comments.


iPad Adoption Rate

by Steve Schrab on October 7, 2010

CNBC is running an article about Apple's iPad adoption rate. To summarize, it's pretty hot.

“iPad sold three million units in the first 80 days after its April release and its current sales rate is about 4.5 million units per quarter, according to Bernstein Research.”

“At this current rate, the iPad will pass gaming hardware and the cellular phone to become the 4th biggest consumer electronics category with estimated sales of more than $9 billion in the U.S. next year, according to Bernstein. TVs, smart phones and notebook PCs are the current three largest categories.”

Whether you think the iPad is revolutionary or an expensive toy, it would be best to pay attention to these numbers. Read the article for more information.


Customer Service via Twitter

by Steve Schrab on December 8, 2009

Hello My Name Is TwitterI’ve always looked at Twitter as just a form of micro-blogging: You follow people who talk about things that interest you or perhaps you have something interesting you want to talk about. Unlike blogs, you’re limited to 140 characters, so your message must be to the point. But what really opened my eyes to how powerful Twitter could be was when I was having trouble with a web site’s application.

I follow a number of different web comics on the Internet. I also follow the writers and artists of these comics on Twitter. They post things like funny quips, when they have new comics up, and a few them even post when they are broadcasting themselves drawing the strip live. Now this is just good general use of Twitter for people who have this kind of fan base.

On one occasion one of these artists tweeted that they were drawing the strip for the day on UStream (a service that allows pretty much anyone to start live broadcasting). I clicked the link in the tweet and went off to UStream to watch them draw on screen. Now computers are finicky sometimes and, for whatever reason, my browser decided it was going to crash when I went to UStream’s web site. I’d restart it and try again, but to no avail. Despite that I had used UStream with the same browser on the same computer in the past, today it wasn’t happening. Like any good tweeter who shares the minutia of everyday monotony, I had to tell the Internet of my frustration.

“Damn it! UStream keeps crashing my browser, and I want to watch Gabe draw!”

I hit send and knew that my handful of followers would know my angst. A minute or so later, I got a tweet from UStream saying, “I’m from UStream Customer Support. I can help you with your problem.” What? I didn’t send a message to them. How did they know I was having trouble? Well - and this is nothing new to you Twitter gurus out there - you can search for tweets. When you search for tweets, not only can you find the tweets with the keyword(s) you’re looking for, but as people make new tweets that contain the keywords you use, they show up in your results, as well. Essentially giving you a live feed of tweets containing the keywords you specified. So after a little back and forth with UStream, I was able to get things running again and watch the last half of the show.

Amazing right? Well, if you’re already familiar with Twitter, then maybe not. If you’re not, maybe I just blew your mind. What’s cool here is that UStream’s Customer Support set up a Twitter search for any tweets that contained the keyword “UStream.” Not only could they monitor what people were saying about their product, they could respond to people who needed help. Monitoring Twitter for what your customers are saying and using it for marketing is great, but getting customer loyalty by actually responding to their complaints and questions quickly is really something. I was impressed they felt it was important enough to have someone on their staff be responsible for monitoring and responding to tweets about their product.

For any business, it would be good idea to watch Twitter feeds that pertain to your brand and products. But don’t watch and absorb all the goodness just for your marketing research. Find ways to help and interact with the customer directly at the exact moment they’re having trouble or have questions.  You may end up with a fan for life.