Skip navigation

Web Basics

warning: Creating default object from empty value in /var/www/vhosts/ on line 33.
Original author: 
Scott Gilbertson

The Internet Archive’s Wayback Machine is deceptively simple — plug in a website and you can see copies of it over time.

What you don’t see is the massive amount of effort, data and storage necessary to capture and maintain those archives. Filmmaker Jonathan Minard’s documentary Internet Archive takes a behind the scenes look at how (and why) the Internet Archive’s efforts are preserving the web as we know it.

The interview with Brewster Kahle, founder of the Internet Archive, especially offers a look at not just the idea behind the archive, but the actual servers that hold the 10 petabytes of archived websites, books, movies, music, and television broadcasts that the Internet Archive currently stores.

For more on the documentary, head over to Vimeo. You can learn more about the Internet Archive on the group’s website.

Your rating: None
Original author: 
Scott Gilbertson

Look Ma, no floats! Image: Abobe

HTML5 and CSS 3 offer web developers new semantic tags, native animation tools, server-side fonts and much more, but that’s not the end of the story. In fact, for developers slogging away in the web design trenches, one of the most promising parts of CSS 3 is still just over the horizon — true page layout tools.

While it’s possible to create amazingly complex layouts using tools like CSS floats, positioning rules and the odd bit of JavaScript, none of those tools were actually created explicitly for laying out content, which is why it’s amazingly complex to get them working the way you want across browsers.

Soon, however, you’ll be able to throw out your floats and embrace a better way — the CSS Flexible Box Model, better known as simply Flexbox. Flexbox enables you to create complex layouts with only a few lines of code — no more floats and “clearfix” hacks.

Perhaps even more powerful — especially for those building responsive websites — the Flexbox order property allows you to create layouts completely independent of the HTML source order. Want the footer at the top of the page for some reason? No problem, just set your footer CSS to order: 1;. Flexbox also makes it possible to do vertical centering. Finally.

We’ve looked at Flexbox in the past, but, unfortunately the spec has undergone a serious re-write since then, which renders older code obsolete. If you’d like to get up to speed with the new syntax, the Adobe Developer Blog recently published a guide to working with Flexbox by developer Steven Bradley.

Bradley walks through the process of using Flexbox in both mobile and desktop layouts, rearranging source order and elements to get both layouts working with a fraction of the code it would take to do the same using floats and other, older layout tools. The best way to wrap your head around Flexbox is to see it in action, so be sure to follow the links to Bradley’s demo page using either Chrome, Opera or Firefox 20+.

For some it may still be too early to use Flexbox. Browser support is improving, but obviously older browsers will never support Flexbox, so bear that in mind. Opera 12 supports the new syntax, no prefix necessary. Chrome supports the new syntax, but needs the -webkit prefix. Like Opera, Firefox 20+ Firefox 22 supports the unprefixed version of the new spec. Prior to v22 (currently in the beta channel), Firefox supports the old syntax. IE 10 supports the older Flexbox syntax. Most mobile browsers support the older syntax, though that is starting to change. [Update: Mozilla developer Daniel Holbert, who is working on the Flexbox code in Firefox, wrote to let me know that the Flexbox support has been pushed back to Firefox 22. Actually the new Flexbox syntax is part of Firefox 20 and up, but until v22 arrives it's disabled by default. You can turn it on by heading to about:config and searching for layout.css.flexbox.enabled pref. Set it to true and the modern syntax will work.]

So, as of this writing, only two web browsers really support the new Flexbox syntax, though Firefox will make that three in the next month or so.

But there is a way to work around some of the issues. First off, check out Chris Coyier’s article on mixing the old and new syntaxes to get the widest possible browser support. Coyier’s methods will get your Flexbox layouts working in pretty much everything but IE 9 and below.

If you’re working on a personal site that might be okay — IE 9 and below would just get a simplified, linear layout. Or you could serve an extra stylesheet with some floats to older versions of IE (or use targeted CSS classes if you prefer). That defeats some of the benefits of Flexbox since you’ll be writing floats and the like for IE, but when usage drops off you can just dump that code and help move your site, and the web, forward.

Your rating: None

NewsBlur survives a traffic surge after news of Google Reader’s pending demise gets around.
Image: NewsBlur.

One of the more interesting stories to emerge from the demise of Google Reader is that of NewsBlur, a previously small, but very nice, open source alternative RSS reader.

NewsBlur is a one-man operation that was humming along quite nicely, but when Google announced Reader would shutdown, NewsBlur saw a massive traffic spike — in a few short days NewsBlur more than doubled its user base. How NewsBlur developer Samuel Clay handled the influx of new users should be required reading for anyone working on a small site without loads of funding and armies of developers.

“I was able to handle the 1,500 users who were using the service everyday,” writes Clay, “but when 50,000 users hit an uncachable and resource intensive backend, unless you’ve done your homework and load tested the living crap out of your entire stack, there’s going to be trouble brewing.”

Having tested NewsBlur a few times right after Google announced Reader was closing, I can vouch for the fact that there were times when the site was reduced to a crawl, but it came back to life remarkably quickly for a one-man operation.

In his postmortem, Clay details the moves he had to make to keep NewsBlur functioning under the heavy load — switching to new servers, adding a new mailing service (which then accidentally mailed Clay 250,000 error reports) and other moments of rapid, awkward growth.

It’s also worth noting that Clay credits the ability to scale to his premium subscription model, writing that, “the immediate benefits of revenue have been very clear over the past few days.”

As for the future, Clay says he plans to work on “scaling, scaling, scaling,” launching a visual refresh (which you can preview at and listening to feedback from the service’s host of new users.

If you’re looking for a Google Reader replacement, give NewsBlur a try. There’s a free version you can test out (the number of feeds is limited). A premium account runs $24/year and you can also host NewsBlur on your own server if you prefer.

Your rating: None

Chrome’s malware warning page. Image: Google.

Nothing drives away your visitors quite like a message from Google that “this site may harm your computer” or “this site may have been compromised.”

Hopefully you’ll never need it, but if your site does get hacked Google has set up a new site dedicated to helping websites that have been hacked.

The “Help for Hacked Sites” section of Google’s Webmaster Tools offers up articles and videos to help you not only recover from compromising hacks, but take steps to make sure it doesn’t happen again.

Part of what makes hacked sites difficult to deal with is that oftentimes developers don’t even notice that they’ve been compromised. “Hacks are often invisible to users,” says Google in its new help section. “For example, unbeknownst to the site owner, the hacker may have infected their site with harmful code which in turn can record keystrokes on visitors’ computers, stealing login credentials for online banking or financial transactions”

Google has an 8-step program for unhacking your site, which include basics like identifying the vulnerability that was used to compromise your site, as well as how to request a review so Google will remove the dreaded “this site has been compromised” message from its search results.

For more info and all the details on what to do if you’ve been hacked, check out the new Help for Hacked Sites section of Google’s Webmaster Tools.

Your rating: None recently made a splash with its high-profile supporters — everyone from Bill Gates to Snoop Dogg have offered up their support for’s premise: that everyone should learn to code.

While’s goals are admirable, the movie above spends near zero time talking about what might be the most important part of the equation: computer science teachers.

The website has info for interested teachers, but the emphasis is still clearly on enticing students to want to learn to code. That’s great, but what about CS teachers?

To prepare for an upcoming talk at the annual Python conference, Pycon, Mozilla data architect and PostgreSQL contributor Selena Deckelmann recently started talking with actual High School CS teachers and has some surprising, if depressing, take aways about what we can do to help kids learn to code. Deckelmann’s survey is admittedly informal and rather small, but it’s a start.

Deckelmann reports that “reading comprehension is the biggest barrier to completion of AP Computer Science” and that “continued existence” is the biggest battle for a computer science teacher every year.

Deckelmann cites a 2010 report that found “the number of secondary schools offering introductory computer science courses dropped 17 percent from 2005 to 2009 and the number offering Advanced Placement (AP) computer science courses dropped 35 percent in that time period.”

More encouraging is that students at one high school learned three languages in three years (C++, Java and Python).

It’s also interesting to note that Deckelmann says “the CS teachers I’ve met want to share their lessons — with me and with other teachers,” and that “the CS teachers I’ve met don’t know other CS teachers.” That sounds like an opportunity for some kind of social site if anyone is interested — just be sure to talk to some actual teachers before you start building.

If you’re planning to be at Pycon this weekend be sure to check out Deckelmann’s talk “What teachers really need from us.”

Your rating: None

Web typography has come a long way from the days when the only way to get a custom typeface on a page was with images created in Photoshop. These days, thanks to widespread browser support for CSS @font-face and services like Typekit, a couple lines of code will add actual font files to your pages.

Go back to 2001 with that information and you would blow many a designer’s mind.

Of course if you’re not a designer, today’s overwhelming variety of type possibilities can be overwhelming. For some help deciphering it all and navigating the sometimes complex world of web typography, check out the video above of Typekit’s Jason Santa Maria‘s talk “On Web Typography.” The video comes from An Event Apart Boston in June of last year, but was only recently made available online (note that Santa Maria has since left Typekit).

After a whirlwind tour of the history of online typography, Santa Maria explores typography from a newcomer’s perspective, looking at how typography affects how you read and how to choose and combine typefaces for a better looking, easier to read site. It’s about an hour long, but you’d be hard pressed to find a better intro to and overview of the art of typography.

Your rating: None

Adobe’s proposed text-balance rule (right) versus no balancing (left). Image: Screenshot/Webmonkey.

Adobe is continuing its effort to bring better typography to the web with a new proposal for what the company is calling “Automatic Text Balancing.” If browsers adopt text balancing it could mean the end of typographic unsightliness like widows, orphans and ragged lines, and would go a long way to creating more readable text on the web.

Adobe’s proposal is based on Adobe InDesign’s “Balance Ragged Lines” feature, and works a bit like justifying text except that instead of expanding text with ugly spaces between words, the algorithm would adjust line lengths to “balance” text for easier reading.

Adobe’s Randy Edmunds outlines the basic idea behind automatic text balancing on the company’s Web Platform Blog. Essentially text balancing would mean eliminating widows (single words pushed to a new line), and also automatically presenting text so that it’s even wrapped instead of a long line followed by a shorter line.

Here’s how Edmunds and Adobe see text balance working:

I propose we use a text rendering algorithm that would be applied by browser when asked by the designer to do so to automatically balance text across multiple lines, like so:

h1 {
  text-wrap: balance;

This would make all h1 elements whenever they span more than one line to be automatically rendered such that they have balanced text. As you notice, I only propose an additional value to the existing text-wrap property of CSS.

If accepted by the W3C, Adobe’s text balance proposal would add a new balance value to the proposed CSS text-wrap rule. The text-wrap property was originally part of the CSS 3 spec, but has since been removed and remains in flux.

Adobe has already created a jQuery plugin polyfill that implements the proposed text balance algorithm. You can grab the code from GitHub. There’s also a sample page where you can see the jQuery text balancing in action. (Be sure to resize the window to see the reflow difference between balanced and unbalanced text.) There’s also an ongoing discussion on the CSS WG mailing list if you’d like to dig into the details.

Your rating: None

The iPad may have started it, but the high resolution screen will soon be the norm. Photo: Ariel Zambelich/

The rise of high-resolution screens means that web developers need resolution-independent graphics or images look blurry. For photographs responsive images may be the solution, but for simpler graphics like logos and icons there’s an easy solution that’s been with us for some time — Scalable Vector Graphics or SVG.

A slightly blurry icon or logo on a retina display probably isn’t going to drive your visitors away, but if it’s easy to fix and can potentially save you some bandwidth as well, why not?

Historically, browser support for SVG has not been particularly good, but these days SVG images work just about everywhere, except older versions of IE. Thankfully it isn’t hard to serve up regular old PNG files to older versions of IE while keeping the resolution-independent goodness for everyone else.

Developer David Bushell recently tackled the topic of SVG graphics in a very thorough post titled A Primer to Front-end SVG Hacking. Bushell covers using SVG graphics in image tags, stylesheets, sprites and even the old-school <object> method. He’s also got a great list of external resources, including SVGeezy for IE fallback, the SVG Optimizer for saving on bandwidth and grunticon which converts SVG files to PNG and data URIs for fallback images.

Head on over to Bushell’s site for more details and you can check out some of our previous posts on SVG for even more resources.

Your rating: None

Soupe du jour: tags. Image: clogozm/Flickr

Somewhere far in the web’s primordial past it was decided that the best way to mark up a menu in HTML was to use the unordered list element: <ul>. The vast majority of tutorials – if not all – you’ll ever see for creating navigation menus use the familiar list element structure, nesting links inside <li> tags. Menu plugins for WordPress and other popular publishing systems use lists for menus as well. Even the HTML5 spec uses an unordered list in its <nav> element examples.

There is, as CSS-Tricks’ Chris Coyier writes, “no debate” about how menus should be marked up. But HTML5 adds the <nav> element and there’s also a navigation role in WAI-ARIA so should we still be using lists to mark up menus?

Coyier says no. He’s dropped lists from his <nav> elements and instead uses just links and span tags. Coyier cites a talk by Reinhard Stebner, who is blind, and suggests that with most screen readers the far better solution for menus is to use divs and spans for menus.

Be sure to read through Coyier’s post for some more data on why ditching the list might be a good idea and check out Jim Doran’s write up on Stebner’s original talk, which makes a distinction between accessible and usable. That is, a technically “accessible” site might still be a usability nightmare for some users.

However, as Mozilla’s Chris Heilmann points out in the comments of Coyier’s post, the problems lists cause in some screen readers are really a result of the sorry state of screen readers. “Screen readers are damn slow to update and vary immensely between different versions… I gave up a long time ago calling something accessible or not when it works in Jaws.”

Lists for menus have advantages over the div and span route, like some extra elements for styling and the fact that they render as, well, lists even in the absence of CSS.

What do you think? Are lists for menus a legacy workaround we no longer need in the day and age of <nav> and role="navigation"? Or do they still offer enough advantages to keep using for menus?

For his part Coyier says he’s going to keep building list-free menus. “Until I see some solid research that suggests that’s dumb, I’m sticking to it,” he writes. “As always, the best would be to get more information from real screen reader users like Reinhard.”

Your rating: None

A handful of the many canvases your site will adorn. Photo: Ariel Zambelich/

In the bad old days of just four years ago it was pretty common for mobile users to get shunted off to some half-baked, feature-deprived “mobile” version of the website they were trying to visit. This misguided practice was common (and annoying) enough that even today Chrome for Android and other mobile web browsers ship with a feature that allows users to “request desktop site.”

To make that feature work Chrome for Android changes its user agent string. Any site that uses user agent strings to redirect mobile users will no longer because to redirect them and the desktop version is displayed.

Responsive websites don’t rely on user agent strings though. Instead they adapt to screen size based on CSS media queries so even if a user has the option for desktop sites checked in Chrome they still won’t get the “desktop” site (of course with responsive sites there really is no desktop site, just a desktop layout).

Provided your responsive designs are good, this isn’t a problem (and if they aren’t then you have bigger problems). However, Opera web standards evangelist Bruce Lawson raises an interesting edge case: what about users that have never seen the mobile layout and are disoriented when they do? If you were expecting, say, the desktop layout of the and instead saw the mobile layout for the first time you might be understandably confused. Here’s what Lawson has to say:

My reason for wondering [about turning off responsive design] is watching my dad use his Xmas Android phone and seeing his puzzlement that some sites look completely different on that device. Non-RWD sites loaded the layout he was familiar with — the desktop layout — which meant he could verify he was on the right site, he knew where in the layout the content he wanted was, and then scroll and zoom to it. When a site looked radically different, he’d check the URL bar to ensure that he’d typed in the right address. In short, he found RWD to be confusing and it meant he didn’t trust the site – no way would he buy anything from these sites.

The first thing to note is that this isn’t a problem unique to responsive sites. The same thing would crop up with a separate mobile experience. The difference is the inability to opt out of the responsive layout. An edge case? Sure, but Lawson isn’t alone in wondering about turning off responsive designs. CSS guru Chris Coyier tackled that very question last year, writing:

Why don’t we see opt-out responsive design? My guess is two-fold:

  1. It’s a bit technically challenging to implement and there aren’t a lot of precedents.
  2. It’s admitting you didn’t do a very good job on the responsive design.

The latter likely being the bigger factor. Like: why are we creating this responsive design at all if we aren’t sure it’s a better experience?

I would agree with both points, but clearly there are at least a few edge cases where offering an option to turn off responsive design might be a good idea. Of course it may not be worth worrying about the edge case of unfamiliar visitors — that’s the sort of decision you can only really make by looking at your own visitors and doing your own testing.

If you actually want to try it, Coyier has some ideas on how to go about creating an option to opt out of a responsive design.

Your rating: None