Quite an impressive open source implementation of HTML5′s video. It aims for a cross-browser, consistent implementation of a modern video player. It’s fully featured and includes a lightweight Flash fallback (yes, that’s still both applicable and important).

Additionally, you can piggyback the CDN-hosted version, or go ahead and do it yourself. Lots of good included here.

Advertise here with BSA

Yesterday seems to have been the day of project releases. scrollorama is a neat little piece of work that helps you better utilize “scrolly stuff”. The demo page outlines just a few things you can do when combined with other great things like lettering.js.

Scroll-based behavior changes, when used properly (read: responsibly), can really be an integral piece of your UX.

Advertise here with BSA

JavaScript is an amazing tool, as evidenced by not only its explosion the past few years, but also the sheer number of highly technical blog articles and posts like these coming out.

Closures in JavaScript are often a topic of discussion. It’s often very confusing to those JavaScript writers who are looking to move beyond jQuery and really start to learn JavaScript itself.

There’s a lot of good information in that thread, but I’m really liking the (currently) top voted explanation.

Advertise here with BSA

All that aside though, it’s an impressive alpha. I seriously love it’s potential and I’m really hoping to make it my own over the next few months. Naturally, the biggest hangup is the lack of tools I’ve become so accustomed to in TextMate. The great thing there is that the snippets and color schemes can be carbon copied into Sublime Text 2, the only outstanding items are Commands. Those aren’t directly portable from TextMate to Sublime Text 2.

I work in HTML, CSS, JavaScript, and PHP. In TextMate I make heavy use of the validators because it’s not an IDE and doesn’t have inline validation as you would find in an integrated environment. Sublime Text 2 doesn’t come with any such validators out of the box, but there are some forum posts. I found some resources on getting JavaScript validation working in Sublime Text 2:

• Sublime Text 2 (Alpha) Google Closure JavaScript Linter Build package
• (V2 only) JavaScript Google Closure Linter Build

I went through the process of getting Google Closure Linter installed and running fine via Terminal, but got [Errno 2] File not found errors in Sublime Text 2. Additional Googling to find out why got me nowhere so I went with JSLint for the time being and thought I’d share how.

Adding JSLint validation to Sublime Text 2

To implement JSLint we’re going to first need JSLint. There are a number of resources for this, but I went with an OS X executable provided courtesy of javascriptlint.com. I made a new folder in my Applications folder and called it a day. JSLint is prepped and ready to go.

The other half of this puzzle is integration with Sublime Text 2. To do that, you’ll need to create a new Build System:

Upon invoking that menu, Sublime will give you an empty file to work with, outlining the structure of Build Systems. Sweet, but what to do with that? We want to send the current file we’re working with to JSLint for validation. To do that, our Build System will look like this:

{
   "cmd": ["/Applications/jsl/jsl", "-process", "$file"],
   "selector": "source.js"
}

Note the path to Applications/jsl/jsl — that’s where I store my JSLint install, but you will need to modify that to the path on your system. The next parameter is the -process flag that JSLint uses to define the file to validate, and the final parameter is the $file flag that will be replaced with the file path to the file you’re currently working on.

The selector will help Sublime Text 2 automatically use this JSLint Build System when you’re working within a JavaScript file.

After modifying for your system, save the file to the default path Sublime Text 2 brings up in the save dialog and restart Sublime. Open up a .js file and hit CMD+B, or use Tools > Build. An inline prompt will appear giving you the JSLint results:

I’ll continue fiddling around with getting Closure Linter to work as I’d like to have the option, but if anyone’s got a tip regarding the error I was getting I’d love to hear some feedback.

Advertise here with BSA

This article is rightfully making the rounds, it’s really important that you read it. For those not familiar with hash-bangs, it’s the newfangled “solution” (from Google) to create AJAX-crawlable websites. The best real-life example you’ve likely seen is the URL structure of New (is it still considered “New”?) Twitter, e.g. http://twitter.com/#!/jchristopher

That #! doohicky is a hash-bang, and it’s causing a ruckus, recently very much so for Gawker and it’s recent massive redesign. Definitely give the article a read, it’s worth it.

Advertise here with BSA

In the days of “JavaScript” equating to “jQuery” to so many people, it’s super awesome to see someone continuing to publish more technical JavaScript articles. If you’re not subscribing to JavaScript, JavaScript I highly suggest it. It may not make sense, but we should always mind the fact that jQuery is not the definition of JavaScript, but it rocks as hard as it does because JavaScript is awesome. The professional in you should strive to understand JavaScript on it’s native level, not abstracted to the sheltered world that is jQuery. This coming from a guy who works with jQuery each and every day.

Enjoy!

Advertise here with BSA

Back when standards were standards if you were building anything that didn’t have a fall back plan in place for a lack of JavaScript, you were doing it wrong. Yes it took more time and it took better planning but that’s the point. When you’re a professional you’re supposed to be doing it right, right?

The rise of (my) Web standards

Back when JavaScript was reborn, when its use began transforming into what we know and love today, the rules were still being written. I remember thinking about how I should approach learning this skill I knew would soon be essential. My first stop when teaching myself something is Google. Of course back in the day Google was still polluted with DHTML tutorial sites and wretched implementations. After reading countless tutorials comprised mostly of “copy and paste this snippet here and that snippet there” I knew it was time to hit the books.

It took about four seconds of poking around to realize that there was more than meets the eye when it came to JavaScript for me. I needed to learn about the DOM before I tried to manipulate it. If there’s one thing that drives me batty it’s the notion of ’learning the framework instead of the language’ and this is no exception. JavaScript though, has a completely new layer to work with.

I won’t detail the issues I have behind learning a framework or platform as opposed to the language here, but it can be applied to every programming language, every markup language, CSS, and JavaScript as well. To sum it up: learning the framework gives the language a bad name. We’ll leave it at that and the rest for another article.

I grabbed myself a copy of DOM Scripting by Jeremy Keith and to this day I’m glad I did. DOM Scripting was instantaneously followed by Bulletproof Ajax, also published by Mr. Keith. If I had to choose two books as a suggestion to someone looking to learn proper JavaScript I think these two are it. There are of course subsequent, more advanced books that I’d also suggest, but these two works will help you to realize which blog posts are junk and which are gold.

The theory behind writing JavaScript, as I took it, can be taken from DOM Scripting:

Separate behavior from structure using unobtrusive JavaScript. Add dynamic effects with progressive enhancement. Ensure backwards-compatibility through graceful degradation.

I lived by those rules. I still do. But am I stuck in the past while everyone is moving forward?

The new Web

Has building a proper Web stack become old school? What I’ve been curious about lately surrounds the trend that requiring JavaScript for your Web app is something we hardly blink at. MobileMe has just recently relaunched with a new look:

Looks really great, but if you hit the page with a JavaScript-incapable browser it’s a bit different:

Back in the day we’d all have scoffed at such a thing, comparing it to a “This site looks best in IE6″ badge straight out of the 1990s. What’s changed since then? Why is this now an acceptable practice? I understand that Apple is a progressive company, bringing the web in its best form to the largest population possible, and making it look great, but that’s my point. Is this new school of thought going to transform itself into common practice?

The entire point behind breaking away from closed platforms such as Flash (yes, it’s a closed platform no matter how much marketing gets put behind it) is to build a universally accessible Web. Devices are advancing, yes. Browsers are advancing, yes. But does that give us the liberty to put the fruits of our labor on a back burner now that we’ve reached some sort of plateau in the evolution of the browser?

I’m not dogging Apple

Apple isn’t the only one producing Web applications that show similar messages if you’re using a JavaScript incapable browser. In fact, other more popular platforms are doing it even worse:

There was a time, if I remember correctly, where Google Docs gave a notification similar to MobileMe as opposed to loading a non working pseudo interface that does nothing but confuse a visitor. Gmail still retains its fully functional JavaScript-less implementation, albeit behind a quick message notifying you what you’re in for:

Depending on your choice, you can end up at a really well put together version of Gmail:

To me, Gmail remains to be one of the best implemented modern Web applications because of this very attribute.

Where are we headed, really?

I’ve tried to wrap my head around these poorly implemented Web applications to find out the real inspiration behind them. Are companies rushing JavaScript dependent platforms out the door simply to get things live before the competition? Are metrics showing that supporting JavaScript simply doesn’t make fiscal sense? Are we to a point where leading Web companies care more about dollars and cents than users?

What about the Web applications themselves? We’re working with the most rich implementations of JavaScript we’ve ever seen. Many times, it doesn’t even make sense to offer a degraded version of an application simply because the desired feature is built within JavaScript from the ground up; there’s nothing else to show. This is not a bad thing. I’m concerned in particular for those applications that could in fact have a decent degraded version. Does it change the opinion we have behind the modern Web though? I’m speaking from a front end developer point of view here, a conversation between us professionals, not as users.

Do we need to move beyond this self-imposed requirement of providing a gracefully degraded version of our application? If so, would it not be a (short) matter of time before that school of thought trickles all the way down to the Coda Slider we plan to implement? In essence, what’s the difference? We’d all be thrilled if we could just make that AJAX request and call it a day without having to first build an alternate version, but is it the right thing to do as professionals?

The groundwork has been laid by some of the best thinkers in our industry, and neglecting to build a proper stack, to me, pushes all of that hard work aside in favor of (too) rapid deployment. If your metrics show a 99% JavaScript enabled audience, are you willing to forsake that 1%?

I’m not only concerned about that 1%, I’m (perhaps) more concerned about how it affects the overall implementation. Working from your degraded version is going to result in a much more stable environment upon which to build your behavioral layer. Skipping that valuable step can and probably will result in a less structurally sound document.

I have a tendency to remain loyal to influential circumstances that have shaped me as a professional, but I’m curious how (if?) these events are affecting other designers and developers, if at all. Do you continue to be curious about degraded versions of modern Web applications? I could be way off base in even thinking about things to this level, and if that’s it by all means feel free to call me out on it, but there’s something under my skin about what’s going on. Thoughts?

Advertise here with BSA

I like the business end of Web design. I’ve come to the conclusion that one of the reasons I like it so much is due to my enjoyment of problem solving. Web design as a business is a problem, plain and simple. Everyone has their own way of doing things, we’re working in a medium that many of our clients don’t fully understand, and it’s sometimes very difficult to completely resolve the final terms of an agreement and be fully confident you’ve covered all your bases. This is something I like thinking about, something I like dealing with. If you’re not in the same boat, I hope you don’t plan on freelancing being a walk in the park. The business end is just as big of a deal as the design/development end. You want to get paid.

Style guides? For code?

A style guide is a straight and to the point document that outlines how you should be formatting your code. It covers indentation, alignment, spacing, tabs, naming, and just about every other aspect of writing code apart from the logic itself.

Whether you’re writing a script, some markup, or programming, you have a way of doing it. You put your brackets in a certain place because either it looks better to you, or your teacher told you to write it that way. The same goes for the spaces you include in your arguments list, your array declarations, and so on. These are important details to consider, especially when you’re looking at someone else’s code.

Even if you didn’t realize you did it yourself, looking at someone else’s code can just come off as… unorganized. At first you can’t quite put your finger on it but you’ll find yourself asking “how the heck does this even work?” If you’ve ever had one of those moments, you’ll appreciate a good style guide in your workflow.

Structuring your style guide

There isn’t a real set of rules to writing your style guide(s); they will probably undergo a long series of revision as you realize the little details you’ve forgotten over time. I think coming up with a style guide is really good team based exercise, something I plan to finalize with my team over the coming weeks.

At my company, we’ll need four style guides to cover our workflow:

• HTML
• CSS
• JavaScript
• PHP

Currently these style guides are a work in progress, but as small snippets look something like this:

HTML

Our HTML style guide will cover things you’d expect to find in other code style guides, but certain aspects of formatting will be included in nearly every example. Things like the ‘closing’ comment for block level elements based on their class or id.

Block element with class

<div class="group">

</div>
<!-- /group -->

Block element with ID

<div id="address">

</div>
<!-- /address -->

Block element with class and ID

<div class="group" id="services">

</div>
<!-- /services -->

CSS

Probably the biggest rule to cover in a CSS style guide would be whether you’re going for single line or multi line, a debate that will carry us through the end of time. Front enders seem to be very passionate about their decision to go with one or the other, so we’re lucky to have a number of tools that will convert from one format to the other on the fly.

Comment Basics

/* ================ */
/* = MAIN SECTION = */
/* ================ */

.main { width:100%; }

	/* Child section */
	.child { border:1px solid #f00; }

Selector property value formatting

.section { width:200px; height:200px; }
.section #child { border:2px solid #f00; }
.section p { margin-bottom:1.2em; }
.section ul { list-style:disc; }
.section ul li { margin-bottom:0.6em; font-size:1.1em; }

JavaScript

We’re a jQuery house, so a significant portion of our JavaScript style guide will include jQuery-specific notes. Along those lines, more generic JavaScript instructions will be needed as well.

Conditionals

if( $('#address').height() < 100 ) {
	do_this();
} else {
	do_that();
}

Chaining

$('.group')
	.find('> p')
	.removeClass('someclass')
	.addClass('newclass')
	.find('ul')
		.addClass('targetclass')
	.end()
.end()
.slideDown();

PHP

I’ve always liked the way CodeIgniter writes PHP. Their guide is extremely in depth and I’d simply like to use that as our style guide as well. One of the best things about CodeIgniter’s style guide is that both correct and incorrect usage is outlined.

Bracket and Parenthetic Spacing

// INCORRECT:
$arr[ $foo ] = 'foo';

// CORRECT:
$arr[$foo] = 'foo'; // no spaces around array keys

Do you use style guides?

I’m becoming increasingly comfortable with the idea that at least some form of style guide, whether on a team or individually, is an extremely important part of the process. It helps with everything from readability to quality control and especially helps a team become that much more cohesive. Are you/is your team using style guides? Have you found them to be helpful, hurtful, or ineffective?

Advertise here with BSA

Advertise here with BSA

Advertise here with BSA