Third off, I’m starting a new job on Monday. More on that later. Teaser? I’ll no longer have to worry about looking too nice at work.
Fourth off, I’m going to try to rework all of my sites this year. Oh snap. I’m starting with this site since it should be a manageable task. I’m working with Skeleton to create a fancy, modern, responsive web site.
Just like the big kids.
As you can see, I’ve already flipped the switch. Release early and often? Something like that. I’m going to customize it over the next few weeks, but after a few hours of tinkering it’s fine for human consumption (that means you, human.)
It’s true. I’m not sure what the next thing is going to be yet, but I’ve given my notice at Sapient. My last day will be the 30th of November.
Why?
Sapient is an incredible company and the people there are great, but the role wasn’t a great fit with my current interests and long-term goals. It’s been a great experience, but, after taking some time to think about it in between spoonfuls of Roman gelato, I decided that it was time to move on to something new. It’s been a hard decision since the team we’ve built here is so great, but I’m confident this is the best direction for me right now.
Free Agency?
So, why not wait it out until I have that something new in place before giving notice? Why not? I’ve got some money saved up, I haven’t had any break in between jobs since 2006 and I’d like to focus completely on finding the right opportunity without having to fit it in in the middle of a high intensity full-time job.
What’s next?
While my intent is to find another full-time job, I’m also completely open to freelance opportunities, so if you’ve got either a full-time role for a senior front end engineer or a really cool freelance project coming up, I’d love to hear about it.
Can we talk?
I’d also like to get out and do some presentations. I’ve had just a handful of opportunities over the past year, so if you’re running a conference, user group or are an organization looking to bring someone in to talk about emerging web technologies, I’d love to hook you up with the good stuff.
HTML5 defines a standardized scheme for marking up and retrieving metadata in the body of an HTML document. If you’ve worked with microformats like hCard and hCalendar then microdata will be relatively familiar. The biggest change is the move from the class name hijacking central to microformats to a new itemprop attribute. In addition to this designed solution Microdata adss two new attributes and one dom method that provides standard access to microdata. itemscope sets the scope of a microdata segment, itemtype defines a URL for the microdata format in use and document.getItems() provides access to microdata. The method returns a NodeList containing the items corresponding to an optional itemType argument or all types, if no argument is provided. the following code listing shows a sample document that features a simple bio of your humble author marked up with microdata. It leverages microdata formats from schema.org and mixes and matches three separate microdata formats, Person, Postal Address and Organization.
The new history API helps to solve one of the most troubling usability issues with Ajax application development (and Flash before it.) By default, if you use the back button on a single page app, you navigate away from the page in question. The expected behavior is to travel back to the previous state of the application.
This can mean potentially losing dozens or even hundreds of historical interactions.
While it’s true that there are script-based solutions available now to handle dynamic state in an Ajax application, the new HTML5 history API provides a single, standard solution. There’s no more choosing between schemes.
It’s not magical. In fact it leaves quite a bit of work to do. You still have to manage and reacreate application state, storing application data in a series of JavaScript objects that populate the history stack.
The following code sample illustrates a basic example. In this simple page a button click changes the color of the page background. Every time this button is pressed the history.pushState method is called. It accepts three arguments, an object representing the history state, a title for the state and a new URL to display in the browser. The state is the most important argument. In this case it’s simply an object with one property color whose value is the new hex value of the page background. It should represent whatever info you need to recreate that state in the history stack.
To do that, you need to bind a function to the popostate event. This function process the same state passed into history.pushState. In this simple example it just reads the color property but it could do anything needed to rebuild application state. In this example we’re accessing the data in e.originalEvent because of the way that jQuery handles events. The abstraction/compatibility layer on top of the standard event handling buries the original event data one layer down. If you were binding events with window.addEventListener you could skip e = e.originalEvent.
<!doctype html>
<html>
<head>
<meta charset="utf-8">
<title>History Example</title>
</head>
<body>
<div id="main">
<button id="historymaker">click to add to the history stack</button>
<p id="reporter">The Background color is #ffffff</p>
</div>
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.8.1/jquery.min.js"></script>
<script>
$( document ).ready(function(){
$( "#historymaker" ).on( "click" , function(){
//http://paulirish.com/2009/random-hex-color-code-snippets
var color = '#'+Math.floor( Math.random()*16777215 ).toString( 16 ) ;
$( "body" ).css( { "background-color" : color } );
$( "#reporter" ).text( "The background color is " + color );
history.pushState( { "color" : color }, color, color.slice( 1 , color.length )+".html" );
})
$( window ).on( "popstate" , function( e ){
e = e.originalEvent;
if ( e.state !== null ){
$( "body" ).css( { "background-color" : e.state.color } );
$( "#reporter" ).text( "The background color is " + e.state.color);
} else {
$( "body" ).css( { "background-color" : "#fff" } );
$( "#reporter" ).text( "The background color is #ffffff" );
}
});
});
</script>
</body>
</html>
In addition to the new semantic elements HTML5 provides several major enhancements to the way forms are handled. New elements, input types and attributes have been added to better map common web inputs.
For example, common web text formats like Email and URL can now be indicated to the browser in a meaningful way using new input types. Mobile devices are leading the way in implementing novel UI enhancements based on to these new form elements. Visit a site with an input type="email" on an iOs device and you’ll see the following special on-screen keyboard.
Image illustrating the special keyboard present in iOs for email inputs. check out the @ symbol.
What’s especially nice about these new form inputs is that they’re completely backwards compatible as all browsers treat unknown form types as type="text."
Some of the new form attributes are very handy and will, eventually replace a mountain of JavaScript in the wild. Attributes like placeholder, for default text in a form input, autofocus, designed to indicate which form element should receive focus when a page is visited and required, which indicates a field in a form that must contain a value for the form to be submitted, all represent common form tasks on the web that are currently handled by JavaScript. With well-written fallback code these form attributes are safe to use as older browsers just ignore the unknown attributes.
The support outlook for the completely new form elements and input types isn’t so rosy. Polyfill solutions exist, but the whole point of looking at input type="color", for a color picker, or the new meter, which indicates usage, and progress, which indicates the progress through a task, elements is to get away from using complicated JavaScript for this common functionality. Unlike something like the placeholder attribute, which can be rewritten in just a few lines of pure JavaScript, something like a color picker or progress indicator relies on a combination of CSS, HTML, JavaScript and associated images. The benefit of having native controls would therefore be significant.
The following code sample illustrates a few of these new form enhancements in action. First is a meter created with a scale of 0 to 25 with an initial value of 10, then there’s a progress element set to 42/100 and finally there are examples of two of the new input types. Both take advantage of the required attribute and the email has a placeholder. As you can see they’re all very simply designed, so with proper support from browsers they’ll offer significant UI enhancements to web applications with very little code overhead.
What the previous code sample looks like in a compliant browser.
Forms aren’t the sexiest area of HTML5 to demo, so people sometimes ignore them. I think they;’re pretty important.
People make money on the web by getting people to enter information into forms. Forms pay the bills. Anything that makes forms better is going to make the web a better place.
Take some time and look at the full suite of form enhancements. They’re pretty slick.