Thorough online book for learning JavaScript and jQuery.

Handy tool for converting characters to different formats. Geeky unicode stuff.

It sure would be nice if the blip.tv player had an easy way to change which video is playing in a playlist using their JavaScript API. But they don’t, so I had to roll my own to make the two play together nicely. Here is the end result (Note there are some line breaks I put in here for visual formatting, it might not work): var player; var currentPlaylistItem; var currentState; function getUpdate(type, arg1, arg2) { switch(type) { case "state": currentState = arg1; break; case "item": currentPlaylistItem = arg1; var episode = player.getCurrentItem(); document.title = episode.title; break; } }

var flashvars = { 'file': 'http://blip.tv/play/ha0CjMVEh_8o', 'enablejs': 'true', 'javascriptid': 'blip_player', 'autostart': 'false' };

var params = { 'allowscriptaccess': 'always', 'allowfullscreen': 'true', 'expressinstall': '/millennials/flash/expressInstall.swf' };

var attributes = { 'id': 'blip_player', 'name': 'blip_player' }; swfobject.embedSWF('http://blip.tv/play/ha0CjMVEh_8o', 'blip_player', '770', '470', '8.0', false, flashvars, params, attributes, swfCallBack);

function swfCallBack() { player = document.getElementById('blip_player'); $('#agenda h3 a, #agenda a.blip_tv').click(function(){ var playlistItemNum = $(this).attr('href').split('#')[1]; changePlaylist(Number(playlistItemNum)); $.scrollTo('.video .player', 800); return false; }); }

function changePlaylist(num) { var direction = 'prev'; var diff = currentPlaylistItem - num; if (diff < 0) { direction = 'next'; diff = Math.abs(diff); } for(i=0; i < diff; i++) { player.sendEvent(direction); } if (currentState == 0) { player.sendEvent('play'); } }

There are three requirements to getting started as outlined in the blip.tv wiki:

The player must be embeded with the enablejs=true Flash variable set The player must be embeded with allowScriptAccess=always object/embed parameter set A JavaScript function must exist named getUpdate()

The first part of my script sets up three global variables that we’ll use.

player will reference the object/embed element by an ID. It is how we send commands to the show player. currentPlaylistItem is the number of the video selected (or position) in the playlist. currentState is either 2 (playing), 1 (loading), or 0 (stopped) depending on the current state of the player.

The getUpdate() function listens to the blip.tv player for changes like when the player is stopped or a video is changed in the playlist. The type argument is a string which we can send through a switch statement to determine what we need to do. If the state of player has changed then we update our currentState variable with the value of arg1 (which will be a number between 0 and 2). If the event is an item change, we will update the currentPlaylistItem variable to reflect that. As an added bonus we get the title of the current playing video and change the title of the webpage to reflect this. This has zero SEO value and is really only a convenience to our audience.  Now that we know what is going on, lets get to the fun stuff. Three variables (which are really Objects) are created for swfobject so we can easily embed the video player dynamically into the page. The ‘blip_player’ paramter is the ID of the player that we’ll be referencing shortly. The swfCallBack() function is called once the blip.tv player has loaded. There we set our player variable to reference the element of the blip.tv player. I used a line of jQuery to set the onClick() events of a group of links that will change the playlist when they are clicked. In the HTML the links contain direct links to each blip.tv video and an anchor with a number after it. This number is the playlist position of the specific video. jQuery makes it a snap to extract just that number from the URL which we store in the playlistItemNum variable. The playlistItemNum variable is passed along to a function called changePlaylist() which does all of the heavy lifting. Since the blip.tv show player doesn’t have a direct way of going to a specific video in a playlist, we have to hit the next or previous button on the player programmatically. The direction is set to ‘prev’ initially.  diff is calculated by subtracting the number passed to the function from the position of the currently playing video, currentPlaylistItem. If diff is a negative number than we need to switch the direction variable to ‘next’ and get rid of the negative number by calling the absolute value method ( Math.abs() ). Now we simply send the player a command to go to the next or previous video as many times as we need to get to the desired video via a loop. Finally, if the player is stopped, we send the video player a command to start playing the video. As an added nicety, we gently scroll the viewer up the page to the top of the video player so they’re not left wondering why nothing happened. The jQuery scrollTo plugin makes this a breeze to do. There is one caveat for the changePlaylist() function to work: the playlist needs to be visible on the blip.tv show player. This is simply an option you set on the player configuration screen on blip.tv. Without it showing, we can’t get which video is playing and the whole thing falls apart. That wraps up how to roll your own playlist changing function as well as shed some light on how you might control other things about the blip.tv show player using JavaScript. You can see this in action on the Pew Research Center Millennial Conference video page. If you have any questions leave them in the comments or get in contact. a

jQuery plugin that lets you easily rotate images using Canvas and VML for IE.

Save a text-based file client side for reduced server load.

ThemeForest.net is an online marketplace for developers to sell themes, templates, and other web development related goodies. A lot of the files are for the backend making it next to impossible for someone to copy them without breaking into your server. But ThemeForest offers JavaScripts for sale and even offers a live preview. By the very nature of the web, a front end technology like JavaScript requires the source code to be downloaded to your computer before it can run. This means anyone with a little know-how can easily bypass the need to buy the script and piece it together themselves. For example, take this JavaScript calendar widget which has 0 sales as of this writing. All you have to do is go to the live preview and remove the frame by clicking the link in the top left corner. From there it’s just a matter of viewing the source (Choose View->Source in Internet Explorer, View->Page Source in Firefox) and copying the necessary JavaScript and CSS files. Here’s everything you need for this calendar widget:

http://s3.envato.com/files/199652/css/calendar.css http://s3.envato.com/files/199652/css/setup.css http://s3.envato.com/files/199652/css/text.css http://s3.envato.com/files/199652/js/resources.js http://s3.envato.com/files/199652/js/config.js http://s3.envato.com/files/199652/js/calendar.js

Now before you get all upitty about the ethics behind this, you should know that this script is freely available from the author’s own site, which was based on an open source project from around 2006 according to comments in the CSS files. Granted ThemeForest isn’t targeted at professional developers like me so someone might be more than happy to plunk down $8 to download everything in one nice, neat package. But if I were selling scripts on ThemeForest, with the expectation of a profit, I would be pissed that ThemeForest didn’t take more precaution to protect my source code. At the least they could obfuscate the live preview code using a tool like /packer/. At any rate this demonstrates why it’s so hard to sell JavaScripts by themselves due to the very nature of how they work in an open web. a

I picked up JavaScript by accident before jQuery, Prototype or any of the other smitten tools that make web developers lives easier. The web was just coming back to life in early 2005 from the dot-com bomb. I was enrolled in the Digital Media Production program at the Art Institute of Philadelphia; a degree encompassing video, web, and multimedia all rolled up into one. Back then almost everything about building websites fell under the term ’scripting.’ ‘Scripting 1′ was really an introduction to HTML with a little bit of CSS thrown in. I managed to test out of this class with an example site I put together for a friend a week earlier. Logically, Scripting 2 would seem to be more advanced HTML and CSS techniques, but my thinking was wrong. My school deemed ‘Scripting 2′ as a JavaScript class.

My only experience with JavaScript before ‘Scripting 2′ was the auto-generated cruft from Dreamweaver MX used in rollovers and jumpmenus. I had no idea what it did or how it worked; I only knew not to muck with it or things would break. I also spent most of my Dreamweaver time in design view, not code view. The required reading for the class was Beginning JavaScript by Paul Wilton. It was still a leading book at the time even though it was 5 years old. That’s how stagnant web development was compared to the blistering pace of progress made today. Some of the more advanced topics included dynamic HTML (DHTML) on Internet Explorer 4.0 and Netscape Navigator 4.x. Yea it was that old, but a lot of the basics still hold true even today.

I read that book cover to cover to get a handle of JavaScript and help me complete my projects consisting of things like temperature converters and form validation. After 11 weeks it finally began to make sense. I began thinking about solving problems with it which led me to my personal project Deviant Bordermaker. The simple tool calculated image sizes for specific ratios given an image. It was developed long before Adobe Air as an offline app that people would download and run locally. Ecstatic couldn’t even begin to describe the feeling of bringing an idea to life and overcoming the barriers of learning a new technology. I knew from that day on that JavaScript would be a part of my career. Fast forward nearly 2 years later when I land my first job at USNews & World Report. My very first task was to develop a quiz-building tool. Since I knew zilch about server-side programming languages, like PHP, I built the app using JavaScript. The final output was the HTML necessary for the quiz to run that a producer could simply copy and paste into the right place. Thinking back on it, the JavaScript was probably overly complex but I certainly learned a lot and continued to push the boundaries of my JavaScript chops. From there I slowly learned the Prototype JavaScript framework, which was the defacto library at the time. At first I didn’t feel like it was making anything easier as I was struggling to grasp the object oriented model of doing things in Prototype. This hard work paid off as learning jQuery was a breeze; it’s pretty much the same thing but with different names for things. JavaScript has come a long way since 2005. The language continues to be pushed into new areas thanks to AJAX, web applications, and a rekindled browser war. Learning JavaScript will go a long way in learning other things like PHP and should definitely be a foundation skill for most any frontend developer. How did you come across JavaScript? a

WordPress plugin to track visitors without JavaScript enabled.

Excellent PHP regex testing tool.

5 WYSIWYG editors

A JS script that adds classes indicating support for advanced features. Then you can have CSS fallbacks based on what browser a person is using.

Every web developer is looking forward to the new HTML spec, HTML 5. The new spec will birth 20 new elements to add more underlying semantic meaning to content. The new elements came out of popular IDs and Class attributes for common situations in web design: <nav> is just like <div id=”nav”>. But these new elements are just a stop gap.

I wish the web community could move beyond pigeon-holing ourselves with specific elements. Why can’t we make our own elements to better describe our content? If I had my way <div>s would be ancient history and any element not already defined in the HTML spec would be treated by browsers like a <div>. There are many benefits to opening up the element nomenclature like this. 1) It will be much easier to describe content. No longer will we need to shoehorn our content into quasi-relevant elements. Did you know the <address> tag is to define the contact information for the author or owner of a document and not to hold a plain street address? 2) No more div-itis. Web developers will no longer have to wade through a dozen </div> tags. <div> tags are the least-semantic structural elements in a web designers toolbox; it literally means ‘division’ of a page and is used to mark off different sections within a document. Things can get pretty messy when using too many <div>s however as it is hard to tell where they end. Take a look at this code example:

<div id="container"> <div id="article"> ... <div id="chart"> ... </div> </div> </div>

Look how much better this markup looks from both a readability and maintainability perspective:

<container> <article> ... <chart> ... </chart> </article> </container>

A benefit to free-form elements is the semantic closing tags making it clear where each element begins and ends. 3) Microformats might actually work. The movement to create semantic markup using loosely agreed upon Classes slowly died off due to the extra bloat it introduced to the underlying code. With the ability to create your own tags, Microformats could flourish and we can begin to set-up our own best practices for describing content. 4) Faster JavaScript. Not many browsers support the JavaScript method getElementsByClassName but every browser supports getElementsByTagName. Because of this many libraries have had to write their own implementations which are many times slower than native methods. Faster DOM traversal = faster JavaScript! What will it take to make this a reality? Boogers We’re already going to have issues with older browsers supporting brand new elements with HTML 5. We might as well go all the way and make sure every browser can support whatever element we can come up with. After all we only have one shot to get HTML right for this generation according to John Allsopp. Many browsers already support free-form elements both with CSS and JavaScript. To really flesh this out I created the Booger Test and below are my findings.

Firefox 3+ supports the <booger> tag as if it were a native element but has to be explicitly set to display:block. Firefox 2 has no problem with CSS unless there children elements in which case the <booger> tag collapses. Weird! All versions of Internet Explorer don’t know what to do with the <booger> tag but they do function normally when using a JavaScript shiv Safari and Chrome have no problems. Every browser I tested passed the JavaScript portions (getElementsByTagName(”booger”)) of the booger test with flying colors!

So as you can see, we are really close to being able to use our own elements. HTML 5 is already going in this direction but it would be a real shame if everyone got hung up on what frivolous new element names we should all agree to use instead of coming up with new functionality to move the capabilities of the web forward. a

jQuery plugin to simulate the effect of flipping a card over.

Lits of places to look for a snippit of code.

JavaScript frameworks for doing animation.