#remy sharp

REQUIREMENTS: WHAT MAKES THE PERFECT TAB?

All content is navigable and available without JavaScript (crawler-compatible and low JS-compatible).

ARIA roles.

The tabs are anchor links that:

Since tabs are clickable, the user can open in a new tab/window and the page correctly loads with the correct tab open.

Right-clicking (and Shift-clicking) doesn’t cause the tab to be selected.

Native browser Back/Forward button correctly changes the state of the selected tab (think about it working exactly as if there were no JavaScript in place).

are clickable

have block layout

have their href pointing to the id of the panel element

use the correct cursor (i.e. cursor: pointer).

The first three points are all to do with the semantics of the markup and how the markup has been styled. I think it’s easy to do a good job by thinking of tabs as links, and not as some part of an application. Links are navigable, and they should work the same way other links on the page work.

The last three points are JavaScript problems. Let’s investigate that.

...

THE SHITMUS TEST

Like a litmus test, here’s a couple of quick ways you can tell if a tabbing system is poorly implemented:

Change tab, then use the Back button (or keyboard shortcut) and it breaks

The tab isn’t a link, so you can’t open it in a new tab

These two basic things are, to me, the bare minimum that a tabbing system should have.

...

URI FRAGMENT, ABSOLUTE URL OR QUERY STRING?

A URI fragment (AKA the # hash bit) would be using mysite.com/config#content to show the content panel. A fully addressable URL would be mysite.com/config/content. Using a query string (by way of filtering the page): mysite.com/config?tab=content.

This decision really depends on the context of your tabbing system. FOr something like GitHub’s tabs to view a pull request, it makes sense that the full URL changes.

...

URL-DRIVEN TABBING SYSTEMS

Instead of making the code responsive to the user’s input, we’re going to exclusively use the browser URL and the hashchangeevent on the window to drive this tabbing system. This way we get Back button support for free.

When Remy writes, you read ;)

My aim was to show you that whilst jQuery has giving me such as huge helping hand over the years (particularly those years of poor interoperability), that native browser support is a long way to doing a lot of the common workflows I have when writing JavaScript to “do stuff” to the DOM.

Remy Sharp is the founder and curator of Full Frontal, the UK-based JavaScript conference. He also ran jQuery for Designers, co-authored Introducing HTML5 (adding all the JavaScripty bits) and is one of the curators of HTML5Doctor.com. Whilst he’s not writing articles or running and speaking at conferences, he runs his own development and training company in Brighton called Left Logic. And he built these too: jsbin.com, html5demos.com, remote-tilt.com, responsivepx.com, nodemon, inliner, mit-license.org, snapbird.org and jsconsole.com!

Any of these accomplishments are impressive, but Remy came to our attention when we were poring over our Twitter feed and saw one of his tweets:

“In the final process of ordering a canvas print of 3 years of 365 photos. Used Node.js to generate the image dynamically from flickr.”

Being the Node.js fiends that we are, we couldn’t help but be intrigued, and so we reached out to him.

NodeFly: You had us at “Used Node.js to generate the image dynamically from flickr.” What were you looking to accomplish?

Remy Sharp: I started a "365 project" back in 2009 which involved taking one picture each day. Nothing impressive, more of a visual diary. But the end game was to produce a canvas print of the 365 project.

The problem was the logistics of laying out the images - and in ignoring this problem, I ended up completing a full 3 years worth of photos. So I turned to JavaScript to automate the creation of the canvas image to be printed.

NodeFly:  Why did you go with Node.js for this?

Remy Sharp: Initially I had written code that would go off to Flickr and load all the images under a specific photo set. Then the images would be drawn on to a canvas element with their size and position calculated. However, because the images were coming from Flickr's domain, it would mean I couldn't export the canvas to a png (due to origin rules).

So I simply moved the JavaScript to the server side, included the Canvas node module and converted the regular images to be requested using the Request module. And now I was able to export the canvas to a png reading for printing.

NodeFly: Any particular challenges or advantages to using Node.js?

Remy Sharp: The big advantage for me was working around the origin rules that the browser was applying because Flickr weren't adding CORS headers to their images. It was pretty exciting being able to so simply port my browser based code to the server largely unchanged.

NodeFly: Do you have any other cool ideas or plans for Node.js? 

Remy Sharp: Lots! JS Bin is now running on Node.js to allow for techniques I'm calling Code Casting and Remote Rendering. With Code Casting you code on your machine, and viewers can watch the code and output being generated in real-time.  Remote Rendering lets you code in JS Bin on one machine, and with the same URL on any number of remote devices - mobile, tv, etc - update the output in real-time.

For obvious reasons, I'm very interested in the real-time space and using Node.js - but also I've found myself creating utilities using Node.js. For example, I ported my snapbird.org (a Twitter timeline search engine) to the command line using node: https://github.com/remy/twitterlib (though I've yet to add any docs! - it's simple npm install twitterlib to add a "tweets" CLI).

NodeFly: With Left Logic, you specialize in web development. What do you think the future holds for Node.js and web development? is it something Left Logic will be utilizing more?

Remy Sharp: The last 12 months has included a number of clients that used node.js for our solutions - and as time goes on, I can see us using node more and more for client solutions.

Left Logic is more of a JavaScript house than a pure web dev house, so using node.js is a simple and obvious progression for our business. And certainly we're looking to work with more clients to help them with their solutions - so do get in touch (through our Left Logic Contact Page)!  

NodeFly:  Thanks for sharing your work with us, and best of luck in future projects! 

I'm with Remy Sharp. Just say NO!

Daniel Glazman, co-chair of CSS Working Group, informs us non-WebKit browser vendors are considering supporting the -webkit- prefix in addition to their own for some CSS features.

In particular Mozilla, who currently uses the -moz- prefix for experimental features, said "Zero is not an option for us" when talking about how many features they should support with the -webkit- prefix. Daniel calls for developers and evangelists to stop being lazy/negligent and use all the correct vendor prefixes instead of just -webkit-.

Remy Sharp says this is a bad idea because it affects the expectations of developers and will likely make us even lazier about prefixes.

Other folks in this this ain't good crowd: Rachel Andrew, Bruce Lawson, and Gilles Vandenoostende.

Christian Heilmann says we as developers got ourselves into this mess, so let's get ourselves out of it.

Aaron Gustafson begs us to at least fix our own stuff and created a petition against other vendors supporting -webkit-.

Eric Meyer is pretty sure we aren't going to win this battle.