Progressive Enhancement, Where Art Thou?

Drew McLellan wonders Why is Progressive Enhancement so unpopular?:

Does that mean we shouldn’t use JavaScript? Of course not. Scripting in the browser is an important part of the experience of using the web in 2014. It’s my opinion that you shouldn’t depend on JavaScript running for your site to work. Build with HTML, add styling with CSS, add behaviour with JavaScript. If the JavaScript fails, the HTML should still work.

Simon St. Laurent touched on this as well in Web Application Development is Different (and Better):

Let’s extend the Web and help it do more – but let’s do that by valuing the many strengths it already brings.

Intentional or not the last few years have brought us a strong push to ignore the idea of progressive enhancement. In many cases that has been to our detriment.

Page Visibility

The W3C recommendation on Page Visibility was updated this week. Being able to detect if a tab currently has focus is an opportunity to adjust features and performance accordingly.

The HTML5 Rocks tutorial on Page visibility has example that automatically pauses a video when the tab is out of focus. The Mozilla Developer Network also uses the video pause example for Page Visibility. Must be the “Hello World” of Page Visibility examples.

Another example would be to turn down the update frequency when a tab is out of focus. No point in updating a page every second, even with a websocket, if the tab is in the background. The Page Visibility API makes it easy to dial the frequency down to something more modest, like once a minute, then turn it back up again when the tab gets focus.

Browser support for the Page Visibility API is pretty good in current versions. The two exceptions are Opera Mini and the Android Browser.

To deal with cross browser differences check out Visibility.js.

JavaScript Keyboard Shortcuts

I came across a JavaScript library for managing keyboard shortcuts called Mousetrap. It is open source, has no other dependancies, includes a nice set of features, and is reasonably small.

There are two sites that I specifically use keyboard shortcuts in everyday: Gmail and Feedly. While I only use a handful of the available shortcuts, the ones that I do use are extremely helpful. Time for me to start adding a few keyboard shortcuts to internal sites I use at work.

Minified.js

I’m not surprised to see more and more “lightweight” JavaScript libraries pop up as jQuery has grown in size. The pendulum tends to swing hard from one direction to the other with these things.

One that I came across recently is Minified.js:

Minified.js is a client-side JavaScript library, comparable to jQuery and MooTools in scope. Its features include DOM manipulation, animation, events, cookies and HTTP requests.

The size of the JavaScript file you send across the wire is certainly one factor to consider, especially for mobile users. I’m more curious to see what the performance looks like when using similar features. In some cases that is even more important than the size of the file.

Is JavaScript On Mobile Fast Enough?

Detailed post on why mobile web apps are slow. Many of the points revolve around:

Here’s the point: memory management is hard on mobile.

For the web devs in the house, this sums up the performance of JavaScript on mobile devices:

It’s comparable to IE 8

When is the last time you used IE 8 for any significant amount of time? Yeah, I can’t remember either.

Long discussion on Hacker News debating some of the individual points. Overall the conclusions still appear to be sound.

Brython

Brython, Python in your browser:

Brython is designed to replace Javascript as the scripting language for the Web. As such, it is a Python 3 implementation, adapted to the HTML5 environment, that is to say with an interface to the DOM objects and events.

That is a trip. Practical? Probably not. Definitely neat though.

The brython.js code that does all the heavy lifting is only 175,936 bytes.

Favicon Alerts with Tinycon

I came across a cool favicon hack recently called Tinycon, which provides a Javascript function to add a small alert bubble to a favicon image. You can see a demo of it in action at http://tommoor.github.com/tinycon/.

Basic usage is super simple:

Tinycon.setBubble( 6 );

sets a favicon alert bubble with the number six in it.

After looking at this I was surprised that Gmail hadn’t done this already. For that matter, perhaps the Google Chrome browser could provide some native functions to make it perform even better.

Code for Tinycon is available at https://github.com/tommoor/tinycon under the MIT open source license.

Automatically Loading a Gravatar Image Based on Form Field Input

I’ve seen several examples of automatically loading a Gravatar image on the fly based on an input form field. After coming across another one recently and not finding a Javascript library that would do this for me, I sat down to play with this process a bit. I knew the process wasn’t complex, but at the same time it seemed like something that should have an easy to use drop in module to make it work. The result is a simple jQuery plugin I’m calling form2gravatar.

The source code is available at https://github.com/josephscott/form2gravatar, along with a simple demo at http://josephscott.org/code/javascript/form2gravatar/. To get started you need a form field, and a target image element:

<div>
	Email <input type="text" name="email" id="email">
</div>
<div>
	<img src="http:////www.gravatar.com/avatar/00000000000000000000000000000000?d=mm&s=64" id="gravatar" alt="Gravatar" height="64" width="64">
</div>

Assuming you’ve loaded jQuery and form2gravatar.js you can then trigger a Gravatar image lookup with:

$( '#email' ).form2gravatar( { target: '#gravatar' } );

This tells form2gravatar to watch the keystrokes in the #email element and update the #gravatar image. By default it will check the form value several times a second, which makes it easy to update the image rapidly, but might be a waste in some cases. So there is an option to only do an image update when the form field loses focus (use_blue).

For pages with several form fields setting use_blur to true will still provide a good experience and have almost no performance impact on the page. If you only have a few form fields (like on a log in page) I’d stick with the default behavior. You can adjust how frequently the form field is checked with the timer_interval option.

Here is a list of all the options in form2gravatar:

	var opt = {
		'default_img'	: 'mm',
		'size'		    : 64,
		'ssl'		    : false,
		'target'	    : false,
		'timer_interval': 100,
		'use_blur'	    : false
	};

The only one that is required is target. The other option many folks will want look at is default_img, which by default uses the mystery man from Gravatar. You can use any of the other Gravatar default options (404, mm, identicon, monsterid, wavatar, retro, and blank) along with a URL to some other image.

The Github repo includes a demo.html file that shows this in use for sign in page. From there you can copy and tweak it into what ever shape you’d like.