Archive for September, 2010

Promote JS – give newbies a chance

javascript on search

Do a search for JavaScript and you find a painful set of returns. The worst offender is having Java results show up. Ouch. (Remember: Java is to JavaScript as Ham is to Hamster!).

Compare to a search for Java, or C#, or Ruby, (or ....).

Ouch. We need better. To begin with the pirates of JSConf (lead by the awesome Mr. Chris Williams!) have started a grass roots Operation SEO at Promote JS. Go there, and help the cause by doing embeds like the following:

If we can do half of the work to promote this as we have with the awesome VaporJS library, then we should be in a better place.

Step 2: Come up with a fantastic landing area for JavaScript.

Editor's note: This was posted by Dion but he had no way to push it live. I am doing this now. To find out about my personal stance on this very cool idea, check out Why supporting promotejs is a good idea.

Web Ninja Interview: Marcin Wichary — Creator of Google Pacman Logo, HTML5 Slide Deck, and More

You know what time it is.... it's time for another Web Ninja Interview! Huzzah! The Web Ninja Interview series focuses on people doing amazing and interesting work using JavaScript, CSS, HTML, SVG, WebGL, and more.

One of the goals behind the Web Ninja Interview series is to talk with the web gurus behind many amazing web sites and products that don't directly blog or speak at conferences as much.

Today we talk with Marcin Wichary. I'm a huge fan of Marcin's work. He was behind the animated and playable Google Pac-Man logo; created the initial HTML5 fancy (shmancy) slide deck that is now an open source project; and helped with Google Instant. He also has a geek love of computer history; just as artists study the masters who came before them computer scientists should know their history. Let's begin.

Brad Neuberg: Tell us a bit about yourself, where you're from, your background, interests, and some projects you have worked on (don't be humble!)

Marcin Wichary: I grew up in Poland. I have a master’s in computer science, and a doctorate in human-computer interaction. I created my first HTML tag in… 1995? It was probably a <P>, but that’s just a guess.

I am proud of GUIdebook, which is (was) an online gallery of graphical user interfaces. Alas, I have not had time to update it since 2006.

At Google, which I joined in 2005 as a user experience designer, I helped with various internal tools and a number of search-related initiatives, including search options, real-time search, and most recently Google Instant.

Brad Neuberg: You built the HTML5 Pac-Man Google Doodle. What's the story behind that? Any technical things you ran into that surprised you?

Marcin Wichary: One of the Google illustrators and a good friend of mine Ryan Germick had an idea to create a first playable doodle for Pac-Man’s birthday. Since I’ve been exposed to arcade games a lot in my childhood, he reached out to me; I built a very early prototype the same night.

The biggest surprise was how much thought went into Pac-Man’s details. You’d think it’s a very simple game, but there’s so much nuance and polish in every aspect. I had to recreate all of it from scratch, and since I personally believe that it’s the details that make or break the experience, it was inspiring to see someone thinking about all that already 30 years ago.

Technically, I was sad to witness HTML5 audio not being quite ready to be used in games. (There’s actually very little HTML5 in the Pac-Man doodle.) And the infamous background caching bug in IE6 bit me so bad that no known solutions worked; I had to introduce a separate code path that didn’t use CSS backgrounds, just regular images cropped by parent divs.

Brad Neuberg: You created the amazing HTML5/CSS3 Slide Deck over on API Rocks. What prompted you to create this initially? What are some of the technical things you used to create this?

Marcin Wichary: A colleague suggested I give a talk to my team about HTML5. I agreed, thinking “I’ll just find a nice list of what’s there in HTML5 and make a presentation out of it.” Turned out, there was no such list, so I had to poke around and construct one myself. It was actually an interesting process. I called it “archeology of the future” – I was looking at Web technologies that’ll ultimately span years 2000 to 2020, trying to figure out how they all fit together right now, in 2010.

In terms of choosing a medium, I’ve been making my slide decks in HTML for about a decade now. Before Keynote, it was the only way for presentations to look exactly the way I wanted (have to give credit to IE6 here for its gorgeous full-screen mode), so I felt fairly comfortable following that – but utilizing newer technologies this time around. I’ve also always enjoyed teaching by example, hence the addition of sliders that allowed direct manipulation of CSS.

I am a very hands-on, low-level kind of guy. I created my first website in FrontPage, but since then I’ve been coding everything by hand. These days it means TextMate and Safari’s excellent Web inspector. I also make a point not to reuse much of what I do, but write the same things over and over again. This allows me to learn and adapt to changing technologies. (For example, I wrote two new presentation engines since the said HTML5 presentation.)

Brad Neuberg: What is a clever hack, trick, or elegant turn of code you've discovered or created while working with JavaScript, HTML, CSS, etc. that you are particularly proud of? Give good details, and don't be afraid to be technical :)

Marcin Wichary: Get an iframe, make it tiny using CSS3 translate/scale, cover with a transparent div to intercept events, and voilà – you have a nice site thumbnail without having to create an image, upload it and worry about them getting out of sync. Of course, it also comes with terrible latency, so there you go.

color: transparent and text-shadow with 0px offset means blurry text. How is that not awesome? (Not that I can think of a use for it.)

Not sure if those are particularly clever or useful – I have an attention span of a <marquee> tag and if I do anything innovative I’m usually the first to miss it – but it’s exciting to discover new uses for things that, in and of themselves, are so brand new.

Brad Neuberg: What are some of the things you are hacking on these days (that you can talk about)?

Marcin Wichary: My main project for the past several months was Google Instant, and we just launched it, so right now I’m looking around and learning about projects. I’ll be doing some internal HTML5 advocacy, teaching and workshops – hopefully some of that will surface on HTML5rocks.com.

Brad Neuberg: Tell us about a hobby, interest, or something in your background that most people wouldn't expect or know about.

Marcin Wichary: One thing that I feel keeps me in balance is collecting (and slowly going through) books about computing history. I probably have some 800 of them by now. My apartment filled with obsolete technology talking about another obsolete technology is a good counterpoint to living in the future at work. And, as always, the best technology stories are those about people – this keeps me focused on our users in the present as well.

Brad Neuberg: Where do you see HTML5, CSS3, SVG, etc. (i.e. the new stuff on the web) going in the next year? How about the next 3 years?

Marcin Wichary: They say nothing ages faster than today’s idea of tomorrow, and I’ve never been a good futurist. :) So I’ll give you my wish list instead.

I would love to see more attention paid to nuances of typography. Computers took most of them away and sure, we reclaimed some back, but not yet very many. And lord, please, layout! We’ve all been using JavaScript crutches to do that for so long that it’s not even funny anymore – indeed, in a lot of my projects the first listener I add is “onresize.”

There’s also a number of avenues in JavaScript to build pretty crappy UIs. alert() and its brethren is the only way to reliably catch the user’s attention. Oftentimes it’s like pillow talk using a bullhorn. :hover allows only for the most rudimentary and unforgiving mouseover actions. We need better defaults for stuff like that.

Brad Neuberg: For folks that want to do the kinds of cutting edge things you've been doing and have done, what advice or resources would you give them?

Marcin Wichary: One of the first popular home video game consoles was 1977’s Atari VCS 2600. It was an incredibly simple piece of hardware. It didn’t even have video memory – you literally had to construct pixels just moments before they were handed to the electron gun. It was designed for very specific, trivial games: two players, some bullets and a very sparse background. All the launch games looked like that.

But within five years, companies figured out how to make games like Pitfall, which were much, much cooler and more sophisticated. Here’s the kicker: if you were to take those games, go back in time, and show them even to the *creators* of VCS, I bet they would tell you “Naah, it’s impossible to do that. The hardware we just put together won’t ever be able to handle this.” Likewise, if you were to take Google Maps or iPhone Web apps, take your deLorean to 1991 and show them to Tim Berners-Lee, he’d be all like “get the hell out of here.”

What I’m trying to say is: Assume nothing is impossible. It’s actually easier this way. So many times people asked me if something is doable in HTML, and my initial instinct was to say “no.” But you look around, ask around, *think* around, and there’s always a way.

Something else that took me a while to internalize: you have to accept that with Web development, anything that’s worth anything will be a hack. Not just prototyping; production code as well. That’s hard to swallow when you’re used to proper, clean, sterile programming. I’d go as far as to say if you’re working on something and you never think “what I did here is terrible; hopefully one day there will be a nicer, better way to do it,” you’ve already fallen behind.

And eventually that battery of hacks in your sleeve might make you stand above. My crude and jaded metaphor of Web development is button mashing when playing video games. Everyone hates button mashers, but working with cutting-edge Web really is flying blind a lot of the time – you’re trying out all sorts of things that sometimes don’t logically make a lot of sense. But they somehow work. If you get used to that mentality and you get familiar with those hacks, you will train your instincts to know which buttons to mash first, and give yourself more buttons as well.

Lastly, if you ask a “what if?” question and leave it unanswered, you should be ashamed. :)

Brad Neuberg: Thanks Marcin!

What kinds of questions do you have for Marcin? Ask them below!

How Gmail’s Drag and Drop from the Desktop Works

The CSS Ninja details how Gmail's drag and drop from the desktop works; when you drag a file from the desktop into Gmail the file will automatically start uploading.

The CSS Ninja recreated the code in a demo (source code [zip]).

The code works in Firefox and Chrome. On Firefox the File API is used (detailed in another blog post) while on Chrome a different API is used.

How does Chrome work?

Using a bit of CSS trickery we can create the illusion of having File API support and still allow users to drag and drop files from the desktop into Gmail. I accomplish this by having the drop zone, which becomes visible on a dragenter event, contain an invisible file input with a 100% width and height of the drop zone area. The file input also has the attribute multiple on it allowing a user to drop multiple files.

HTML:
<div id="drop">
<h1>Drop files here</h1>
To add them as attachments

<input id="filesUpload" type="file" /></div>
 

The drop zone is hidden by default until a dragenter event happens on the BODY tag:

CSS:
#drop {
position: relative;
}
#drop input {
position: absolute;
width: 100%;
height: 100%;
top: 0;
left: 0;
opacity: 0;
}
 

When the drop input is activated a change event is fired and the files can be enumerated:

JAVASCRIPT:
dropArea.addEventListener("change", TCNDDU.handleDrop, false);

TCNDDU.handleDrop = function (evt) {
var files = evt.target.files;
dropArea.style.display = "none";
for(var i = 0, len = files.length; i &lt;len; i++) {
// iterate over file(s) and process them for uploading
}
};
 

The actual uploading is handled by XHR2:

Using XHR2 and the upload attribute to attach progress events so we can do a real progress bar that indicates to the user how much the file has uploaded.

Evercookie – using a lot of solutions to force a persistent cookie

delete cookies?Samy has put together an impressive solution to store persistent cookies on user's computers even when they have cookies disabled. The Evercookie script reaches deep into the toolbox to fish out some very interesting and devious tricks for local storage:

TODO: adding support for:

Pretty impressive. The only thing working around it is NOSCRIPT.

Chrome Frame is out of Beta!

Big news: Chrome Frame is now stable and out of beta!

Today, we’re very happy to take the Beta tag off of Google Chrome Frame and promote it to the Stable channel. This stable channel release provides our most polished version of Google Chrome Frame to date, allowing users to access modern web technologies like HTML5 on legacy browsers. You now can download the stable version of Google Chrome Frame and users of the Beta will be automatically updated to it in the days ahead. If you’re an IT administrator, we’ve also posted an MSI installer for deploying Google Chrome Frame in your network.

Chrome Frame is now much faster and stable. It's extremely simple to have a site use Chrome Frame:

HTML:
<meta http-equiv="X-UA-Compatible" content="chrome=1">
 

For the next step the Chrome Frame team is focusing on making start-up speed even faster and removing the need for administrator rights when installing the plug-in.

Congrats to the Chrome Frame team!

[Disclosure: Alex Russell, the chipper-looking fellow in the video, and I have worked together at Google and on Dojo before.]

HTML5 Link Prefetching

From David Walsh comes a good writeup on the HTML5 link prefetch tag:

HTML:
<!-- full page -->
<link rel="prefetch" href="http://davidwalsh.name/css-enhancements-user-experience" />

<!-- just an image -->
<link rel="prefetch" href="http://davidwalsh.name/wp-content/themes/walshbook3/images/sprite.png" />
 

You use the link tag to do prefetching, setting the rel to "prefetch" and giving the URL to the resource to prefetch. When should you use link prefetching?

Whether prefetching is right for your website is up to you.  Here are a few ideas:

  • When a series of pages is much like a slideshow, load the next 1-3 pages, previous 1-3 pages (assuming they aren't massive).
  • Loading images to be used on most pages throughout the website.
  • Loading the next page of the search results on your website.

Some things to know about link prefetching though:

A few more notes about link prefetching:

  • Prefetching does work across domains, including pulling cookies from those sites.
  • Prefetching can throw off website statistics as the user doesn't technically visit a given page.
  • Mozilla Firefox, currently the only browser to support prefetching, has actually supported prefetching since 2003.

Animating With Firefox’s mozRequestAnimationFrame

Firefox 4 is going to be a very exciting release. Robert O'Callahan details one of the new features, which should help animation, called mozRequestAnimationFrame. First the motivation:

In Firefox 4 we've added support for two major standards for declarative animation --- SVG Animation (aka SMIL) and CSS Transitions. However, I also feel strongly that the Web needs better support for JS-based animations. No matter how rich we make declarative animations, sometimes you'll still need to write JS code to compute ("sample") the state of each animation frame. Furthermore there's a lot of JS animation code already on the Web, and it would be nice to improve its performance and smoothness without requiring authors to rewrite it into a declarative form.

setTimeout and setInterval can only go so far; as Robert describes, we sometimes need something between purely JavaScript-driven animation using setTimeout and having to go full declarative using CSS3 or SMIL. mozRequestAnimationFrame is one potential way to get better synchronization and performance from JavaScript based animation.

Some sample code from Robert using it:

JAVASCRIPT:
var start = window.mozAnimationStartTime;
function step(event) {
   var progress = event.timeStamp - start;
   d.style.left = Math.min(progress/10, 200) + "px";
   if (progress &lt;2000) {
      window.mozRequestAnimationFrame();
   } else {
      window.removeEventListener("MozBeforePaint", step, false);
   }
}
window.addEventListener("MozBeforePaint", step, false);
window.mozRequestAnimationFrame();
 

It's not very different from the usual setTimeout/Date.now() implementation. We use window.mozAnimationStartTime and event.timeStamp instead of calling Date.now(). We call window.mozRequestAnimationFrame() instead of setTimeout().

Note that you will generally get about 50 frames per second using mozRequestAnimationFrame. As Robert describes in another blog post, this is a feature not a bug:

On modern systems an application usually cannot get more than 50-60 frames per second onto the screen...So even if an application updates its window 100 times a second, the user won't be able to see more than about half of those updates...firing a MozBeforePaint event more than about 50 times a second is going to achieve nothing other than wasting CPU (i.e., power). So we don't. Apart from saving power, reducing animation CPU usage helps overall performance because we can use the free time to perform garbage collection or other house-cleaning tasks, reducing the incidence or length of frame skips.

I hope that other browsers pick up this feature.

Video Conferencing with the HTML5 Device Element

Did you know that work is being done to enable videoconferencing from HTML5 applications? Ian Hickson has been doing work on the element in a separate draft to make this possible.

The element will be used to allow the user to give permission to a page to use a device, such as a video camera. A type attribute can be used for the page to give more specificity on what kind of device they want access to. Right now this could be 'media' for access to an audio or visual device; 'fs' to access the file system, such as a USB connected media player; or 'rs232' or 'usb' to access devices connected in this manner.

Example usage:

HTML:
<p>To start chatting, select a video camera: <device type=media onchange="update(this.data)"></device></p>
<video autoplay></video>
<script>
 function update(stream) {
   document.getElementsByTagName('video')[0].src = stream.url;
 }
</script>
 

The spec includes a way to work with Stream objects for the data coming from the device and to record Streams. It also includes an API for working with peer-to-peer connections, such as sendBitmap() or sendFile() to send data between a peer connection. The entire standard is still being baked but here is what a P2P connection might look like in pseudo-code:

JAVASCRIPT:
var serverConfig = ...; // configuration string obtained from server
// contains details such as the IP address of a server that can speak some
// protocol to help the client determine its public IP address, route packets
// if necessary, etc.

var local = new ConnectionPeer(serverConfig);
local.getLocalConfiguration(function (configuration) {
  if (configuration != '') {
    ...; // send configuration to other peer using out-of-band mechanism
  } else {
    // we've exhausted our options; wait for connection
  }
});

function ... (configuration) {
  // called whenever we get configuration information out-of-band
  local.addRemoteConfiguration(configuration);
}

local.onconnect = function (event) {
  // we are connected!
  local.sendText('Hello');
  local.addStream(...); // send video
  local.onstream = function (event) {
    // receive video
    // (videoElement is some <video> element)
    if (local.remoteStreams.length> 0)
      videoElement.src = local.remoteStreams[0].url;
  };
};
 

[via Aditya Mani]

Progressive enhancement using nothing but JavaScript?

Progressive enhancement is still a confusing matter for a lot of people who are very excited about the capabilities of JavaScript in modern browser environments. It can feel anachronistic to write your solutions for a non-JS environment and then once more enhances in JavaScript. I grew up like that so for me it is a simple matter of doing the right thing but with today's world of JavaScript libraries and out-of-the-box widgets it can seem a drag.

Enter Dav Glass of the YUI team. He's been turning the concept of progressive enhancement around in his head and as a JS lover and backend code "endurer" he set out to solve this issue once and for all in a pure JavaScript way.

Here's the issue: you cannot assume JS to be available on the client side as your visitors might be on a slow mobile connection or are paranoid enough to turn off JS or actually have it turned off for them by company policy or many other cases.

So in order to use pure JavaScript to render a solution that works for everybody the natural thing was to move the JS solution to the server side and re-use it on the client when it is possible.

If you say server-side JavaScript you end up quickly talking about Node.js and so did Dav.

Check out the following demo:

Express.js, Node and YUI3 for progressive enhancement by photo

All of what you see is driven by JavaScript - there is no server-side PHP fallback. Yet if you turn off JavaScript in your browser, you get the same experience.

The reason is that Dav uses Express.js and Node to render the HTML of the application server-side with JavaScript and YUI3. The code is available on GitHub and a video of him giving a talk about this is available soon on the YUI blog.

This is an exciting concept as it means that we can build progressively enhancing solutions using any widget library if we just think of the server-side case, too. This can mean a lot less code and easier maintenance as the only skill needed to build bullet-proof solutions is JavaScript.

The missing piece to the puzzle though is a fully fledged DOM renderer on the server side. DOMJS works but a C++ version would be much better in terms of performance and have all the features of DOM-2.

Web Ninja Interview: Mr. Doob

As part of our Doob-a-thon today, we have a Web Ninja Interview with Mr. Doob. The Web Ninja Interview series focuses on people doing amazing and interesting work using JavaScript, CSS, HTML, SVG, WebGL, and more.

Mr. Doob has delighted us with many awesome visualization and demos, including the recent Wilderness Downtown project. He is one of a crop of JS wizards that are taking advantage of new tools like Canvas, CSS3, SVG, and WebGL. Let's get started.

Brad Neuberg: First things first, the most important question is where the name Mr. Doob comes from?

Mr. Doob: I've always been very dependent on wearing headphones in order to get some level of concentration. Because of that I started using combinations like do_ob, dõ_õb, dò_ób, dê_êb, d=_=b, ... as IM nicknames. One day a friend greeted me as Mr.doob and the name somehow stuck. It was also easier for my coworkers to pronounce than my real name.

Brad Neuberg: Now that we have that out of the way, tell us a bit about yourself, where you're from, your background, interests, and some projects you have worked on (don't be humble!)

Mr. Doob: I'm originally from Barcelona (Spain). After primary school I studied Electronics and later Arts. From the early days I was very involved in this thing called Demoscene. Always attracted to anything computer graphics but, although I tried to learn code my mind wasn't ready yet and focused on design and editing. Because I felt I was learning way more from doing demos than attending college I stopped my education and looked for a job where I could develop my interests and ended up working as a HTML developer. Since then I've been alternating the coder and designer roles in every company.

Most of the projects I've worked on have been about creating the ID or online presence for small companies. It wasn't until I joined Hi-ReS! that I worked for bigger brands such as Sony, Nokia, Sprint, Jägermeister, Chanel, Dolce&Gabanna, ...

By that time I started experimenting with Actionscript and uploading the results to my site. Unexpectedly the site started to attract production companies and studios that were looking for some experimental effects and/or interactions.

Brad Neuberg: You recently worked with Google on The Wilderness Downtown. Tell us a bit about the project and what you did, including some technical details on how you built things.

Mr. Doob: Probably the project in which I've been able to apply most of what I've learned until now. There are some pieces of code reused in the project like three.js, the Sequencer code or the Harmony base code but my main tasks were working in the Street View shots and the birds. The Street View being by far the most challenging for performance reasons. We intended to directly use the Google StreetView Javascript Embed but it performed very slowly. A custom Street View Data viewer had to be done by drawing sinusoidally distorted columns of crops from the panorama texture. The effect isn't 100% how it should be but it's very similar and fast. After that there was the challenge of finding out where in the panorama was the user’s home so we could use the right point of view for some shots. I couldn't find much documentation about that, but just when I had a desperate email ready for the Google Maps guys I came up with idea of getting the vector from the lat/lng of the house and the lat/lng of the panorama data. It's now obvious but there was so much data around to assimilate and the deadline was approaching fast.

Brad Neuberg: Tell us about a hobby, interest, or something in your background that most people wouldn't expect or know about.

Mr. Doob: Hmm... not that it’s too interesting but... I used to be fairly good at football. At some point I had to decide whether to join a football team or joining a comic school. Some times I regret I didn't do the former. Something tells me I'll go back to that eventually...

Brad Neuberg: What is a clever hack, trick, or elegant turn of code you've discovered or created while working with JavaScript, HTML, CSS, etc. Give good details, and don't be afraid to be technical :)

Mr. Doob: It's not much of a trick or a hack, but I've always found very beneficial to avoid using libraries such as jQuery. I guess such libraries are helpful for cases where IE6+ support is required, but otherwise I think that, ironically, it over complicates things. The more control you have over your code the better.

Also, I’m still learning JavaScript and I don’t know the reason behind some objects. As an example, I recently stopped using new Image() and started using document.createElement( ‘img’ ) for consistency reasons.

Brad Neuberg: Where do you see HTML5, CSS3, SVG, (i.e. the new stuff on the web) going in the next year? How about the next 3 years?

Mr. Doob: They’ll continue evolving at a nice pace. And browsers will have to keep up to date or they’ll lose their user base.

In 3 years I think it’s all going to be WebGL though. I think it’s easy to imagine videogames moving from native applications to web applications. Windows/MacOS/Linux compatibility comes for free, the downloading/installing process won’t be needed and, if done right, the experience starts instantly. At this point Windows/MacOS/Linux as OS becomes irrelevant for most of the people.

It scares me that people browse the internet more and more from devices that can’t be used for authoring but, on the bright side, I like the fact that with Javascript nothing gets compiled and kids will be able to right click any page and see directly the code.

Brad Neuberg: What excites you the most about what is happening on the web today? What still frustrates you?

Mr. Doob: The competition between browser vendors. That competition is making the platform improve at a rate I wish the Flash platform would have been while I was into that.

This new trend of serving results in realtime and realtime interactions is also exciting. The internet is evolving very quickly.

What still frustrates me are usually stupid politics-based decisions like Safari and Internet Explorer not supporting Vorbis in <audio>, Safari only playing iTunes rendered h264 .mp4, ... And other than that I just can’t understand why ‘darker’ is being removed from context.globalCompositeOperation in the WHATWG specs.

Brad Neuberg: For folks that want to do the kinds of cutting edge things you've been doing, what advice or resources would you give or point them to?

Mr. Doob: Just look at the past. I’m not doing much else than combining old Amiga/DOS techniques with what the web has to offer. Thanks to the recent JS1k contest we now have lots of code to learn from and experiment.

Thanks Mr. Doob! What questions do you have for Mr. Doob? Ask them below!

We end with a presentation Mr. Doob gave recently at ARTtech 2010 on Laziness, Creativity, and Code:

ARTtech 2010: Laziness, Creativity and Code from AssemblyTV on Vimeo.