Today kicks off a new series focused on interviewing people doing amazing work on the web using JavaScript, CSS, HTML, SVG, WebGL, or any of the other new-fangled Three-Letter Acronyms coming out. We call these people Web Ninjas.

Our kickoff blog post for the Web Ninja Interviews is Erik Arvidsson, one of the original Obi Wan Kenobi’s karate chopping JavaScript whether it’s called DHTML, Ajax, or HTML5. He is one of the original JavaScript bad-asses. 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!)

Erik Arvidsson: I’m a Frontend Engineer at Google and I’ve been there for 5 years.

I’m currently working on Chrome. A lot of Chrome’s UI is done using HTML+CSS+JS. For example I created the New Tab Page and the new Bookmark Manager. Working on Chrome is a breath of fresh air. I no longer have to care about cross browser issues and I can use all the goodies from HTML5 and CSS3 that we have in Chrome. Another big difference working on Chrome UI compared to working on web apps is that we only have to work with ToT (tip of tree) and when I find bugs in Chrome/WebKit I try to fix them instead of finding work arounds. As soon as the bug gets fixed I know that 100% of the users will have the bug fix.

Before Chrome I worked on Gears and then later moved over to the Gmail team to ship Offline Gmail. Working on Gmail and Offline was very exciting. Gmail is the largest web app I’ve worked with and it taught me a lot about the issues with large scale projects using JS. For example, the large memory working set caused us to have to do major low level refactoring to not get dog slow in IE6 since JScript had an extremely inefficient GC.

When I got to Google the state of JavaScript was a mess. Me and Dan Pupius took it upon ourselves to fix this and Closure (library) was born. A lot of the best practices from creating large scale web apps such as Gmail went into Closure and we worked closely with the Closure Compiler people making sure we would get the most efficient JavaScript possible.

I am also a member of the ECMA TC39 [working group]. The group that is responsible for the standardization of JavaScript. JavaSript as a language has a lot of warts but I love the flexibility that it gives us developers. Yes, it is too easy to do the wrong things in JS and I think JS needs some soft boundaries to encourage the programmer to do the right thing. Today, writing programs that are efficient and easy to maintain requires too much boiler plate code. I also think it is important to continue to keep JavaScript dynamic and flexible. I am afraid of initiatives to make everything static and locked down. There are plenty of good static languages and there are lots of projects that compile from <insert language here> to JavaScript.

Before Google I worked on a small company where I created a GUI toolkit called Bindows. It was a big change going from a 1 engineer company to Google and working on a code base with hundreds of different engineers.

Earlier than that I created WebFX with Emil. This was one of the earlier DHTML web sites and it got quite a lot of creds back in those days.

In 2000 I worked on something called WebOS (yes, that was the name) and we built a complete desktop environment and GUI toolkit for IE5 and later rearchitectured that to work with Netscape 4 and IE4 (yuk).

I got into DHTML around 98. I had a web page at my university where I used a lot of CSS for IE3 and I was into the whole beta scene. I was pretty excited what early alphas of Windows98 where doing with Windows Explorer where a lot of the UI was done in HTML and I absorbed every little method and property as the IE4 developer previews came out. It was like Christmas every time a new beta came out. One thing that made me so excited about DHTML was that I could with, very little code and no compilation, do things that would take hundreds of lines of code to write in Java, C++ or any of the other languages/toolkits they were teaching at the university.

Brad Neuberg:You were one of the first to jump into DHTML, watched the transition and rebrand with ‘Ajax’, and have watched as HTML5 has come on the scene. What are some of the things that excite you the most about what is happening on the web today? Are there any old tricks in particular you are looking forward to not needing to do as more modern browsers arrive on the scene?

Erik Arvidsson: I think one of the most exciting thing about the web is the richness and usability of modern web apps. The speed improvements that Chrome pushed so hard for have paid off and all the browsers today are a lot faster. The other reason applications have become better is the tireless work of people like Steve Souders who keep reminding people that latency is important.

I find a lot of the new CSS3 features available in WebKit allows me to do more with less. I really like being able to use a canvas as my background image and CSS transitions (although I often find them too limited) are really amazing. I also like the direction aware CSS properties (padding-start, margin-end, text-align: end etc) which allow me to remove a lot of CSS that is used to display the page correctly in RTL. I understand that most people do not have to care about RTL but for Chrome all the UI has to work in RTL.

With IE9, event abstractions is a thing of the past and good riddance. Just implement your own EventTarget interface and your JS objects works exactly like the DOM objects.

I’m also happy that Explorer Canvas will not be needed much longer. It was a fun project but VML in general was never well implemented and it has caused me a lot of head aches.

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

We’re finishing up another iteration of the New Tab Page for Chrome as well as moving all the settings UI to HTML. Besides from that I’m getting more into WebKit. It is such a mind blowing change to be able to actually fix the browser when something is not working as it should.

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?

Erik Arvidsson: I’m really excited about IE9. I feel like all the browsers today are finally supporting a big chunk of CSS, JS, DOM and HTML. If you are willing to use Chrome Frame for your old IE users all your users will have access to modern web APIs. This has never happened before and I expect a lot of applications to be rewritten with this in mind, leading to faster, more interactive and more usable applications.

Another big thing is that I believe that the innovation in the web browser and the standardization communities have been focused on providing missing capabilities like drag and drop of files, offline, rich graphics etc. However, the usability of these APIs have been lacking. Everything feels more disconnected now than it ever did before. I think and hope that we will see a lot of work making things fit better together in the future. I have a few pet peeves that I would like to see fixed:

How come NodeList is not an instance of JS arrays? Why can’t I do document.querySelectorAll(’.foo’).forEach? Why can’t I splice that collection? Yes, there are issues with some of these collections being read only etc but nothing that cannot be solved. Why is it that DOM and JS never seem to fit together? Why can’t I do “new HTMLButton”? Why can’t I create custom HTML element in JS? How come all JS libraries wrap elements with a JS object and they all build their own component models that never work together.

I think some of this comes down to be able to make the platform self hosting. I’m not saying that we should build the input[type=range] element in user code. I’m just saying that I think it should be possible to do so. Same goes for CSS which is far from extensible today.

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 :)

Erik Arvidsson: This is a trick that I settled on while working on the Bookmark Manager for Chrome. It allows you to sub class HTML elements which in turn allows you skip the common JS wrapper that all JS toolkits use.

In the code above the constructor creates an element but it changes the prototype chain of the element to add our custom object before the built in prototype, effectively allowing us to inject our own behavior, and then returns that element. Now you can effectively work with the element instead of having to keep track of whether you got the element or the element wrapper. Things like document.querySelector(’.foo’).myProperty just works.

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?

The way I learned it was to read the API docs of MSDN (the whole thing). With every new release I scoured for changes in the DOM (using for in loops) but today you can do the same with Web Inspector or Firebug. Just keep playing with the new stuff, you don’t have to build anything useful, just get a feeling for what the API can do for you. One thing that I found fun and educational was to build small games. Just take one of your favorite games from the 8-bit era and reimplement it. It has never been as easy to do this as today since we now have canvas (WebGL) and fast JS engines.

And of course, read Ajaxian and other blogs to see what crazy shit people are coming up with these days.

I’ve been doing alot of experimenting with HTML5/CSS3 on the iPhone doing animation, and I’ve been surprised with the low frame rate of animating through Canvas or SVG. If you are trying to do animation, especially 3D, on the iPhone it seems like the name of the game is to it through the GPU, and the only way to do that these days on iOS is CSS3 Animations/Transitions/3D.

These experiments caused me to stumble on Paul Hayes interesting work simulating a 3D animated cube using CSS3, hence they happen on the GPU on the iPhone/iPad and are quite fast:

A 3D cube can be created solely in CSS, with all six faces. Using JavaScript to detect key presses and update inline styles this cube can be intuitively navigated.

Adobe is pleased to announce the availability of the Adobe® Illustrator® CS5 HTML5 Pack. This add-on for Illustrator CS5 15.0.1 provides initial support for HTML5 and CSS3, extends SVG capability in Illustrator CS5, and helps you easily design web and device content. In combination with the HTML5 features available in the Adobe Dreamweaver CS5 11.0.3 updater, these new tools allow web designers to take advantage of the latest advancements in HTML5.

While HTML5 and CSS3 will not be finalized for some time, and SVG support in browsers will continue to evolve, the extension provides support for a set of currently implemented features.

Some of the benefits of the HTML5 Pack:

Efficiently design for web and devices by exporting Illustrator Artboards for unique screen sizes using SVG and CSS3 media queries.

You can designate certain attributes (i.e., fill, stroke, opacity) as variables right from the Appearance panel in Illustrator. When saved as SVG, developers can easily change the variable definition to “reskin” or modify the art. You can even create global variables.

Multi-screen SVG

You can create multiple artboards in Illustrator at various sizes, for example to design art for different screen sizes. You might do this to create different designs for mobile, tablet, and desktop versions of a design for example. You can then save your file as SVG and include all the different artboards. Illustrator creates an HTML file and a CSS file, along with separate SVG files for each artboard. The CSS uses media queries to detect the screen size and automatically serves up the correct SVG image.

Mark objects as canvas in SVG

You can select an object on the Illustrator artboard and then choose Object > HTML5 Canvas > Make. These elements are rasterized and included as canvas elements when saved as SVG, giving developers the ability to control the elements via JavaScript.

Export named character styles as CSS

You can define character styles in your Illustrator document, and then export those character styles as a valid CSS file. You can do this directly from the Character Styles panel.

Export artwork appearances as CSS

You can select an object in Illustrator and export valid CSS directly from the Appearance panel. Of course, if you mockup an entire page in Illustrator, you can simply select all of it and export it to a single CSS file. IDs are picked up from the Layers panel (so you want to name artwork carefully), and Illustrator can export Fill, Stroke, Opacity, and Absolute Position and Dimensions.

Include selected Graphic Styles as CSS in SVG

You can select styles from the Graphic Styles panel and choose to have them exported when you save your file as SVG. What’s really cool is that you can include styles even if they aren’t applied to your artwork. This would allow you to deliver multiple styles to a developer within a single SVG, and even programmatically swap styles.

The heart of his tutorial is using getImageData() and looping through the red, green, blue, and alpha values of each pixel to change it’s luminance:

So, what can we use to make an image black and white? The luminance. The luminance is how much a color is luminous to the human eye and it’s used to measure the clipping white in video editing systems, for example. In video editing system a white color that “break” the screen is a white that is too white to be represented on a common TV.

This is important because by calculating the average number between red, green and blue values we could obtain a value for every pixel that represent a static mathematical representation of the color luminance.

But there’s a problem, an human eye see colors dynamically. For example, if we take similar shades of blue and green, our eyes will detect the green color more luminous than the blue. In our algorithm we could use the static average formula, but our image will be too flat, and we’ll lose a lot of color depth.

This formula calculates the luminance of a color as it’s perceived by the human eye, so the green channel has more importance than the red and the blue. In our Javascript code we calculate for every pixel the grayscale number, by using exactly this formula. Then we assign this value to the red, green and blue channels of our pixel. By doing this for every pixel we are able to get a black and white version of our original image. There are obviously other more complex methods to calculate the correct grayscale value, but they could be too heavy to be used in an HTML5 canvas element, and we can say that for an everyday use, the luminance algorithm is good.

Unless you tell it otherwise, tinySrc will resize the image to fit the screen of the mobile handset visiting your site. For example, if an iPhone visits the site, the image will be constrained to its screen size of 320px x 480px.

In this particular case, the image is of landscape orientation, and width is the constraining dimension. Aspect ratios are always preserved by tinySrc, so our 640px by 400px image will emerge resized for an iPhone as 320px by 200px.

The Yahoo! YUI is an incredibly feature-rich JavaScript library with a LOT of functionality but getting your head around all of those features can be tough. The YUI team wants to help developers get up and running more quickly and announced yesterday the release of SimpleYUI; a basic and more streamlined version of the YUI library.

SimpleYUI will contain basic DOM access and manipulation including support for CSS 3 selectors in the selector engine, animations via the new transition module, the event system, Ajax and JSON support.

The great thing is that when you’re ready to leverage more advanced features like managed attributes and custom events, you still have the ability to do on-demand loading just like you’d expect from the full-featured version of YUI. This includes any YUI 2 or 3 component or YUI 3 Gallery module.