Quite a while ago, I wrote an article about jQuery .on() and off() - an improved way of attaching events in jQuery - and still the best way to attach events to DOM elements in jQuery.
Being able to apply and remove events with on() and off() is great, but sometimes there is a requirement to either trigger or remove a subset of events that have been added to an element. For example:
$('.item').trigger('click'); // both functions are triggered
$('.item').off('click'); // both functions are removed.
Using event namespacing we can assign names to event handlers when we create them, and then use them later on to target specific functionality when we call trigger() or off(). The name you choose for your event namespace should be relevant for the functionality you are calling. For example:
$('.item').trigger('click.navigate'); // only the function assigned to the namespace navigate would be triggered.
$('.item').off('click.notify'); // only the function assigned to the namespace notify would be removed.
It's also possible to use multiple namespaces, like so:
$('.item').trigger('click.navigate'); // will trigger the click event function.
$('.item').off('click.notify'); // will remove the click event.
Namespacing events in jQuery has been available for some time and isn't limited to just on() and off(). It also works with .bind() and .unbind() too.
Inspired by a post by Ben Howdle I read earlier this week on how difficult it can be for newcomers to get in to the industry, I decided that I wanted to write a post with some hints and advice for developers who are just starting out their careers.
This post does not include any code or best practices and it is not a tutorial or guide to writing web pages. Instead the points below are aimed toward explaining what to expect as a web developer, and some of the key things you should consider as early in to your journey as possible.
There are so many things to learn in web development now that it can feel incredibly overwhelming - but it can also be very rewarding. What fascinated me about web development was the ability to create - I love to create - and when I started out building web pages I found it incredibly easy to express my creativity with HTML and CSS in just a few lines of code. I could create something and then publish it on the web for others to see very quickly (which at the start of your career will likely just be your Dad and your best friend).
2012 really felt like a progressive step forward for Responsive Web Design. As big corporate companies like Starbucks and Microsoft as well as governments began to introduce breakpoints in to their web pages to cater for the diverse range of devices now available on the market, it no longer felt like the technology was only for use for blogs and news sites. Responsive Design proved it was ready for mass consumption.
In parallel, using a responsive grid became popular as a convienent way of handling column configurations over breakpoints. From simple grids like the one used in Twitter Bootstrap to the SASS driven SUSY that allows you to keep semantic markup while managing columns over breakpoints; grids in a responsive design became popular.
Using these techniques, we could ensure that content was king and provide the optimal experience for our users regardless of how they were viewing our web page.
There Appears To Be a Problem.
But for all the possibilities media queries allow, there appears to be a problem with the current selection of available conditions. We're often told that we should build for content first and not design, yet the most widely used media queries are built in completely the opposite way: min-width and max-width. These two media queries measure the width of the page - often this is useful but there are situations where this isn't helpful, particularly on larger scale websites.
A couple of months ago, I gave a PechaKucha talk about creating a 3D animated particles effect with the canvas element.
For those who've not come across the concept of a PechaKucha before, the idea is to present on a topic for 20 slides with 20 seconds per slide. The event I attended was slightly different with just 5 minutes to show those 20 slides (so 15 seconds a slide).
Whenever I talk to web developers I find that the canvas element still remains a mystery to most, so I wanted to do a short presentation that could introduce developers who had not used the canvas element before to the concepts and show how it's not quite as scary as it seems.
It was my first PechaKucha, and during rehearsal I learnt that the format doesn't lend itself too well to explaining how to implement lines and lines of code. I tried to balance out the slides so there wasn't too much new information on each. The aim of the talk was less about teaching developers everything about canvas and more about showing how simple it can be to create an effect.
Below is a write up of the talk, and I'm going to purposefully keep it short (hopefully a 5 minute read) to allow you time to experiment. You can view the original presentation here, the slides move on every 15 seconds and the animated demos start themselves - each demo is deliberately self contained so you can dive in to the code. Please use, abuse and learn.
-moz-transform:scale(2); /* Firefox */
-ms-transform:scale(2); /* IE (9+) */
-o-transform:scale(2); /* Opera */
-webkit-transform:scale(2); /* Safari and Chrome */
transform:scale(2); /* One day someone will use this so let's keep it future proof */
It's a lot of code to scale an element, and there are various arguments on the web about why vendor prefixes are and are not bad; and there are even some solutions to avoid having to write this amount of CSS, such as Lea Verou's -prefix-free or using a class file in LESS.