Code Like the Big Boys: Flickr

March 30, 2008

Warning

This article is old and may contain information that is outdated, irrelevant, or—dare I say it—no longer accurate. Read with care!

Code like the Big Boys is a series of posts about code solutions used by major websites. What can we learn from these professional websites to use in our own code?

JavaScript

Looking at the source code of the Flickr home page is actually pretty strange. For one, there is only one JavaScript source code file (other than the advertising scripts), a solution for PNG Alpha Transparency in Internet Explorer, included as an HTML Component. The source for the PNG Behavior script (credit to Erik Arvidsson) is unchanged, with the exception of the removal of some extraneous comments, but curiously enough no whitespace removed (a suggestion to save them a few bucks in bandwidth). Looking at their HTML source, they seem to emphasize whitespace and readability over bandwidth savings, which seems fine to me. At least their visitors (you and I) can more easily learn something from their code.

CSS They’ve taken the same route as one of the tips from Jonathan Snook, and declared all styles for an element on a single line. They use your standard css to reset to a base starting point, much like YUI’s Reset CSS we’re all familiar with. One interesting declaration I noticed prominently inside of their CSS was the .Butt css class, declared on their primary Search form button. I’m curious to know the semantic meaning behind that one.

They use the tan hack as well to isolate a CSS declaration for IE browsers:

* html #featured-image cite {bottom: -1px;}

This is to workaround for an IE limitation to absolutely positioning content at the bottom of a relatively positioned div, in this case the black box containing the credits (or citation, hence the cite tag) inside of the feature image.

Another interesting CSS Hack they’ve employed involves the line-height for tags containing Unicode characters to select different languages. It starts out like Dustin Diaz’s min-height hack, but throws a loop.

height: 0px !important; height /**/:13px;

I’m not familiar with the /**/ syntax, and would really appreciate any information someone has on what platform this is targeting. A comment would be nice!

Editors Note (2013): The /**/ syntax is to target everything but IE6.

HTML

Standard here, and they have some nice meta tags for the I-phone:

All in all, it’s short and sweet code for a home page. It’s nice to see such clean code with an eye towards standards on a commercially successful site, many props to their programmers. I’m scared to do my next in the series, because I’m 100% sure it won’t be as nice of a read as Flickr was.

548 Views

Zach Leatherman is a builder for the web at Font Awesome and the creator/maintainer of Eleventy (11ty), an award-winning open source site generator. At one point he became entirely too fixated on web fonts. He has given 83 talks in nine different countries at events like Beyond Tellerrand, Smashing Conference, Jamstack Conf, CSSConf, and The White House. Formerly part of CloudCannon, Netlify, Filament Group, NEJS CONF, and NebraskaJS. Learn more about Zach »

3 Comments

Isaac Z. Schlueter Disqus
04 Apr 2008

I wouldn't read too much into the fact that there's only one JS include, or that all the CSS rulesets are each on a single line. Many professional sites, especially those developed here at Yahoo, use some kind of build script to concatenate and minify the JS and CSS in order to save bandwidth and requests.For example, on http://buzz.yahoo.com your browser will see one JS and one CSS for every page. However, in development, we often had 2-3 JS files for each major component, and nothing is minified. Our build script parsed through each page when it was installed on the server, and shrunk everything down into nice browser-friendly packages.If you don't have a build script (which is fine in many cases) then you're left balancing the needs of browsers with the needs of the development team, and the two groups often differ in what works best for them.Personally, I can't stand CSS rulesets all on one line. My eyes and brain just can't parse it.Only around 10% of the browser's time is actually spent waiting for/parsing the HTML content. The vast majority of the time is spent waiting for external components, applying CSS, and running JS. With gzipping, the overhead of whitespace is minimal, so the isn't much advantage to removing whitespace from markup. Some bandwidth "saving" techniques actually *increase* the size of the gzipped content, so it's important to actually measure output rather than just counting the characters removed.
Zach Leatherman Disqus
04 Apr 2008

It's actually funny that you mention a build script for JavaScript and CSS. That's what I've been working on the last 2 days at work, a ANT build script that uses YUI Compressor, which as I understand, uses your CSS minimization code. The tricky part I'm wading through right now is: How do you automate what to combine?Do you look through your HTML source and find similar dependencies between them? And how do you find a good balance between code that can be combined into a single file and the ability to use reuse files for cached files between different pages?Of course, I wouldn't advocate developing a medium to large project with only one JavaScript or CSS file. That can get seriously unwieldy when it comes to code management, team programming, and source control. But at the end, when you push your code to production, you should trend towards that goal.I haven't really been comfortable Gzipping content until IE6 gets the last stake in its coffin. Do you guys sniff clients to feed Gzipped content?I've been thinking that it might be a good idea to pick up Steve Souder's book on performance optimizations for the web. A lot of that stuff is just so much more complicated that just writing good code. And that's definitely something I need more information on.
Jauder Ho Disqus
16 Apr 2008

After much painful digging and testing, IE6 below XP SP2 (without the SV1 in the User Agent) does not support gzip.With that in mind, it *is* possible to construct a webserver config to serve up gzip content to browsers that support it.Here's my config for nginx. It should not be hard to produce an equivalent for apache.http://tumblelog.jauderho.c...