I'm a (full-stack) web and app developer with more than 5 years' experience programming for the web using HTML5, CSS3, JavaScript and PHP. I mainly use the LAMP stack and frameworks like jQuery, jQuery Mobile, and Cordova (PhoneGap). My interests also include web security, web accessibility, SEO and WordPress. Currently I'm self-employed working with the cited technologies and a regular blogger for several networks (SitePoint, Tuts+ and FlippinAwesome) where I write articles about the topics I usually work with and more. I'm also the author of the books jQuery in Action, third edition and Instant jQuery Selectors.

Aurelio's articles

  1. 5 Javascript APIs to Empower Your Mobile Web Pages

    Statements like

    “The mobile market is increasing”


    “People accessing the web through a mobile device (smartphones, tablets etc.) will overtake those accessing it through a desktop or a laptop”

    don't impress anymore.

    Today we're all aware, at least we should be, that the mobile market is significant when developing anything for the web.

    For years there has been discussion and differing points of view about native applications versus web applications and on which is the best. Regardless of your opinion, it used to be a fact that native mobile applications allowed to access hardware components that web pages couldn't. But is this gap still valid today? Have web technologies improved to the point where we, as developers, can code with just HTML, CSS, and JavaScript?

    In this article I'll introduce some JavaScript APIs that allow your web pages to access hardware components of mobile devices or that can empower your web application on mobile devices.

    Battery Status API

    The Battery Status API provides information about the system's battery level or status. Thanks to this API you are able to know if the battery is charging or not, how long before the battery will be fully discharged, or simply its current level. These details are accessible through four properties that all belong to the window.navigator.battery object. This API also defines events that can be fired when there are changes in the mentioned properties.

  2. Introduction to the Resource Timing API

    SitePoint has published some good articles on performance recently. In particular, Craig Buckler wrote an article entitled Average Page Weights Increase by 32% in 2013 along with another one called some easy wins to reduce the weight of a website.

    But improving the speed of our websites and apps isn’t just a matter of minifing JavaScript files and employing an image compressor. In many cases we have to deal with external resources (libraries from a CDN, videos from YouTube, images from Flickr, and so on) or internal resources that need to be accurately measured to establish what’s slowing down the loading of our pages.

    I’ve previously covered some APIs that can help in testing the performance of a website. For example, the High Resolution Time API and the User Timing API. In this article, I’ll introduce you to another API in this category: The Resource Timing API.

    What’s the Resource Timing API?

    The Resource Timing API allows you to collect complete timing information related to resources in a document. It enables you to measure user latency, which is crucial to benchmark web pages. This API is a W3C Candidate Recommendation so we can be sure that significant features are mostly locked, but there could be minor changes to the spec in the future.

    Using the Resource Timing API allows us to retrieve and analyze a detailed profile of all the network timing data for every resource on the page. We’ll cover what these data are in the next section. For the moment, it’s important that you understand how this API can help us in tracking the performance of the resources of our page, and determine how many and what resources we have to optimize.

    Now that we know what this API is, let’s delve into its features.

    Methods, Properties, and Events

    The Resource Timing API is exposed through the performance property of the window object. We can retrieve the information collected for each resource using the getEntriesByType() method. If this sounds familiar to you, this is because it’s the same method used by the User Timing API. The difference is that to retrieve information about these resources we have to pass the string resource to getEntriesByType().

  3. A Guide to the jQuery animate() Method

    jQuery is a lovely library, and for many years now it has changed the way thousands of developers approached their projects. When jQuery was created, CSS wasn’t able to create complex animations, leaving JavaScript as the way to go. jQuery helped a lot with animations thanks to the several methods created for this purpose. Although it comes with a few simple animations (fadeIn(), hide(), slideDown(), and so on), to keep its weight low, the library provides a very flexible method called animate(), which allows us to create any animation we desire. This method is the topic of this article.

    jQuery’s animate() is a wrapper method, meaning that it operates on a set of previously selected DOM elements, wrapped by jQuery. This method allows you to apply your own custom animation effects to the elements in the set. To do that, we have to provide a set of CSS style properties and values that those properties will reach at the end of the animation. The intermediate values that the style achieves during the effect (automatically handled by the animation engine) are determined by the duration of the effect and the easing function, two options we’ll discuss soon.

    The list of CSS style properties that can be animated is limited to those that accept numeric values. The value can be an absolute value (like 200), or a relative value from the starting point. In the case of an absolute value, jQuery assumes pixels as the default unit. We can also specify other units like em, rem, or percentages. To specify relative values, we have to prefix it with += or -= to indicate relative target values in the positive or negative direction, respectively.

    Now that we know a little about animate(), it’s time to look at its signatures and its parameters.

    Signatures and Parameters

    This method comes in two main forms, and most of its parameters are optional (denoted using the usual square brackets):

    • animate(properties[, duration][, easing][, callback])
    • animate(properties[, options])

    There is also a lot to say about the parameters:

    • properties (Object): A hash containing the values that should be reached at the end of the animation.
    • duration (Number|String): The duration of the effect in milliseconds or one of the predefined strings: “slow” (600ms), “normal” (400ms), or “fast” (200ms). The default is “normal”.
    • easing (String): The easing function name to use when performing the transition. The default value is “swing”.
    • callback (Function): A function to execute when the animation is completed for each animated element.
    • options (Object): A hash containing a set of options to pass to the method. The options available are the followings:

      • always (Function): A function called when the animation completes or stops without completing.
      • complete (Function): A function executed when the animation is completed.
      • done (Function): A function called when the animation completes.
      • duration (String|Number): Same as previously described.
      • easing (String): Same as previously described.
      • fail (Function): A function executed when the animation fails.
      • progress (Function): A function run after each step of the animation. The function is called only once per animated element.
      • queue (Boolean): If the animation has to be placed in the effects queue (more on this in a few moments). The default value is true.
      • specialEasing (Object): A hash of one or more CSS properties whose values are easing functions.
      • start (Function): A function executed when the animation begins.
      • step (Function): A function to invoke for each animated property of each animated element.

    The term easing is used to describe the manner in which the processing and pace of the frames of the animation are handled. The queue option allows us to run animations in sequence when it’s set to true, or in parallel when set to false. That’s quite a lot of power in our hands that we can use as we like.

    In the remainder of this article, we’ll demonstrate some of these arguments in action to give you a taste of what’s possible with animate().

    Example Uses

    In this section we’ll build some demos to unleash the power of animate(). Keep in mind that this method isn’t a good fit for very, very complex animations because of issues concerning the performance and the smoothness of the animations.

    Running a Single Animation

    Running a single animation is pretty easy, and involves just one call of the method. For example, we may want to move an element from one side of a box to the other. To illustrate this animation we’ll set up two div elements, one inside the other. We’ll style them so that the inner div has a red background. The code to complete this is shown below.

  4. Easily Improving jQuery Animations

    We’ve all used jQuery’s animate() to create nice effects on our web pages. Then, with the introduction and the rise of CSS3 they told us that our code was rubbish. They suggested that we dump all of our jQuery-based animations (and in general JavaScript-based animations) in favor of CSS-based ones.

    This change forced us to deal with a lot of browser (in)compatibility issues and lack of features; not to mention the impossibility to run them on older versions of Internet Explorer. The pain was justified by the fact that CSS animations are faster than JavaScript ones. At least they told us so. It this true? Is jQuery’s animate() so slow? Is there a way to enhance it easily without changing our code? The answer is yes.

    In this article we’ll see some of the limitations of both ways of creating animations and then how we can achieve better performance with our jQuery code.

    What’s the Problem With jQuery?

    We all know and love jQuery (actually some people don’t). This library, designed to simplify the client side scripting of HTML, has helped hundred of thousands (no real data intended) developers all over the world. It makes things like HTML document traversal and manipulation, event handling, Ajax, and much more a piece of cake, taking the burden to deal with all the browsers’ incompatibilities and bugs.

    Among its features, jQuery also allows to create animations and effects. With it, we can animate CSS properties, hide elements, fade them, and other similar effects. However, jQuery’s design goal has never been to be a performant animation engine, and it was never meant to support really complex, cpu/gpu-consuming animations. As a confirmation of this fact, jQuery’s memory consumption often triggers garbage collections that cause issues while an animation is performed. In addition, behind the scene jQuery uses setInterval() instead of requestAnimationFrame() (read more about requestAnimationFrame()) to run animations, that doesn’t help in producing high frame rates.

    Due to these factors, people “who know best” evangelized the use of CSS to create our animations and effects.

  5. 5 Grunt Tasks You Won’t Want to Miss!

    Unless you’ve lived under a stone for the past few months, you’ve surely heard about Grunt or one of the other task runners released like Gulp.js (more on this topic in our article An Introduction to Gulp.js). This family of tools has taken the frontend landscape by storm, revolutioning the way thousands of developers deal with tedious activities like concatenation, minification, image optimization, and so on.

    If you’re new to the world of task runners, and particularly to Grunt, you can either refer to the article Automate Recurring Tasks with Grunt or the Grunt getting started guide.

    In this article I’ll show you five Grunt tasks (sometimes referred as Grunt plugins) that you won’t want to miss!


    If you’ve recently spent some time writing CSS, you know that we have to deal with a lot of experimental properties and vendor prefixes. This activity is so painful that it has contributed to the success of websites such as Can I Use and CSS3 Please. Thanks to grunt-autoprefixer, this activity won’t be such a pain anymore.

    grunt-autoprefixer is a task based on the Autoprefixer library that parses CSS and adds vendor-prefixed CSS properties. The data that determines if a property needs one or more prefixes are extracted from the Can I Use database. In grunt-autoprefixer we can specify several options, but the most important one is surely browsers. The latter accepts an array of values that allows us to specify which browsers and versions we’re targeting in our project. The aim is to add only the prefixes we really need so our CSS will be as lightweight as possible.

    A basic configuration example for this task is shown below. In this configuration, we’ve specified a file to parse named main.css. The output is written to a file named `main-prefixed.css`. Additionally, the output will contain the prefixes for the last two versions of each browser supported, plus Internet Explorer 8, Internet Explorer 9, and Opera 12.1 (the last version to use the Presto engine).

    autoprefixer: {
    options: {
    browsers: ['last 2 version', 'ie 8', 'ie 9', 'Opera 12.1']
    dist: {
    src: ‘src/css/main.css’,
    dest: ‘dest/css/main-prefixed.css’
  6. 5 Things I’ve Learned About Accessibility

    Every developer should learn something new every day, at least those who want to be good. It can be something as simple as a new CSS property or as complex as a library. Whatever it is, it’s all welcomed as long as you learn something.

    In my attempt to follow this principle, I recently decided to focus on a topic I really care about and that, until now, I haven’t had the time to deepen my knowledge of: Accessibility. Accessibility (often abbreviated as a11y) is defined as the practice of removing barriers that prevent access to websites by people with disabilities.

    In this article, I’ll share with you some tips and tricks to improve the accessibility of a website. I’ve learned these recently while attending related events (like InclusiveDesign24 and the May meetup of London Web Standards).

    1. Do Not Use the accesskey Attribute

    A few years ago, I discovered the existence of an HTML attribute called accesskey. It can be associated with any HTML element and its value is established by the author of the web page. Its aim is to provide to a user a way to activate or focus a certain element through the use of a key, or a combination of keys. To give you an idea, let’s imagine we have the following menu that uses the accesskey attribute:

    [code language="html"]


    At first glance this seems like a great accessibility improvement as we’re enabling users to access a given page with a single command. But it’s not. In fact, one of the keys we set in the markup may be in use by the user’s assistive device (e.g. a screen reader), or by the browser employed by the user, or even by the user itself. As if that was not enough, we also can’t predict collisions because each browser may have a different combination of keys to press to use the specified accesskey.

    For example, a Chrome user who wants to access the blog using the value defined in the accesskey attribute has to press ALT + SHIFT + b. Nice, isn’t it? Yes, it is… until you discover that the same combination is used by Chrome to focus the bookmarks bar. Thinking of changing the value? Perhaps a t is a better choice. Nope. The combination ALT + SHIFT + t is used in Chrome to focus the toolbar. We can continue this discussion for a while, but I’m sure you get the point.

  7. Introducing the Proximity API

    Smartphones and mobile devices have gained a lot of importance in our life and it seems increasingly that we cannot live without them.

    When used properly and with moderation they are valuable tools that can help us in achieving common tasks such as knowing the next bus, locating the nearest tube, searching for an Italian restaurant and so on.

    They have also opened a whole new world to web developers. In fact, thanks to the rise of needs derived from the use of mobile devices, a set of new APIs specifically created for them has been standardized.

    In the last months I’ve introduced you to several APIs, such as the Web Notifications API and the Web Speech API. In this article I’ll describe a simple, yet useful API called Proximity API.


    The Proximity API defines events that provide information about the distance between a device and an object, as measured by a proximity sensor. This API was initially part of the the Sensor API, later split and become an independent API. The specifications of the Proximity API are considered stable because it reached the status of W3C Candidate Recommendation as of 1st October 2013.

    If you’ve ever had or used a smartphone, which I assume you have, you’ve already seen this API in action.

    Want an example? Think of your last phone call and what you did. You unlocked your smartphone, typed the number you wanted to call, and then tapped the “Call” button. Once done, you placed the smartphone near your ear and suddenly something magic happened, the screen turned off.

    This is an action many smartphones perform to safe your battery, but what powered this feature was the Proximity API. When you place your mobile device near enough to your ear, the proximity sensor fires an event that is listened to by your smartphone, which in turn shuts off the screen.

    On the web, we have other interesting use cases. Have you ever been driving while listening to music using a web service and had to stop it?

    How painful was it to take your device and then manually stop the player? I guess the answer is “A lot!”. Thanks to this API, web developers can now add a feature so that if an object (the hand in this case) is close to the device the player will pause.

    Now that we know what the Proximity API is and its use cases, we can dive into the events it exposes.

  8. An Introduction to the Web Notifications API

    The time of the 56kb connections has faded out of memory for a lot of people (mobile users not withstanding). It was a time when browsers that could open a single page where enough, and no one could even predict a future with multi-tabbed browsing. Today, we’re overwhelmed by social networks, posts, replies, comments, photos, videos, and much more. Several systems have been created to overcome the need to look at every single tab to check for new activities. One of these methods are notifications, which are very widespread on different websites.

    Until not too long ago, every developer had to implement notifications on their own, resulting in a whole set of different solutions. The W3C has defined an API to solve this problem in a standard way called the Web Notifications API.

    On mobile devices we’re very familiar with the concept of notifications. Try to be offline for a couple of hours and, as soon as you connect to the Internet, you’ll be overwhelmed by notifications from the different apps installed on your device. It’d be great to have the same mechanism, like the Web Notifications API, for our web pages that work seamlessly on desktop and mobile devices.

    Image shamelessly stolen from the presentation of Brad Frost, Death to Bullshit

    What is the Web Notifications API

    The Web Notifications API is defined as an API for end-user notifications. A notification allows alerting the user outside the context of a web page of an occurrence, such as the delivery of email. The specifications don’t describe how and where a UA should display these notifications. Therefore, we’ll see different styles on different browsers and, based on the device we’re using, we’ll see the notifications in different places (for example on mobile we may see them in the notifications bar). It’s worth noting that before you can show a notification, the browser shows an alert to the the user, who must explicitly give his/her consensus.

    An example of a notification using the Web Notifications API on Firefox
    An example of a notification using the Web Notifications API on Firefox

    This API has been around for a while, to the point that the specifications have changed several times. The specification has known two major versions. The first version was implemented in older versions of Chrome and Firefox. Now, the specification seem stable, although as of April, 19th 2014 it’s still a W3C Working Draft.

    Thinking of some use cases for such an API isn’t very hard. For example, you may want to receive a notification as soon as you receive an email. You may also want to be notified if someone mentions you in a Tweet, or posts a photo of you on Facebook or Google+.

    Now that we know what this API is, and what it’s good for, let’s delve into the description of its methods, properties, and events.

    Methods, Properties, and Events

    The Web Notifications API is exposed through the Notification property of the window object. This is a constructor that allows us to create a notification instance. It accepts two parameters – a string containing the title of the notification, and an optional object of settings. Before we see how we can create an instance, let’s look at the settings we can specify:

    • body: A string used to further specify the purpose of the notification.
    • lang: Specifies the language of the notification. Its value must be compliant with the BCP 47 standard. Examples of valid strings are en-US and it-IT.
    • dir: Defines the direction of the message’s text. Its value can be auto meaning that the direction is based on the browser’s settings, ltr to specify a left-to-right direction (for European languages), or rtl to specify a right-to-left direction (for some Asian languages).
    • tag: A string that is used as an ID that can be employed to retrieve, replace, or remove the notification.
    • icon: Specifies the URL of an image that will be used as the notification’s icon.

    To create an instance of a Notification object, we should write a statement like the following:

    var notification = new Notification(‘Email received’, {
    body: ‘You have a total of 3 unread emails’

    Pretty easy, isn’t it?

    It turns out that the settings we’ve just learned are also available as read-only properties of a notification instance. In addition, the Notification object exposes a property called permission. permission contains a string representing the current permission to display notifications. Its value can be one of the followings: denied, which means that the user has denied notifications, granted, which means the user has given permission, or default, which means the user choice is unknown.

    This API exposes two methods: requestPermission() and close(). As the names suggest, the former is used to request the permission to show notifications to the user, while the latter programmatically closes a notification. requestPermission() is a method of the Notification object and accepts an optional callback that is executed when the user accepts or denies permission. The choice is passed to the callback as a parameter, and the value can be granted, denied, or default.
    close() is an instance method and doesn’t accept any parameters.

    Sometimes we may need to perform an action as soon as the status of the notification changes. For example, we may want to know if the user has clicked the notification, or when it is closed. To do that, we can attach a handler to one of the four events exposed:

    • onclick: Fired when the user clicks on the notification.
    • onclose: Fired as soon as the user or the brower closes the notification.
    • onerror: Fired if an error occurs with the notification.
    • onshow: Fired when the notification is shown.

    A basic example of using these events is shown below.

    var notification = new Notification(‘Email received’, {
    body: ‘You have a total of 3 unread emails’

    notification.onshow = function() {
    console.log(‘Notification shown’);

  9. Talking Web Pages and the Speech Synthesis API

    A few weeks ago, I briefly discussed NLP and its related technologies. When dealing with natural language, there are two different, yet complementary, aspects to consider: Automatic Speech Recognition (ASR) and Text-to-Speech (TTS). In the article Introducing the Web Speech API, I discussed the Web Speech API, an API to provide speech input and text-to-speech output features in a web browser. You may have noticed that I only presented how to implement the speech recognition in a website, not the speech synthesis. In this article, we’ll fill the gap describing the Speech Synthesis API.

  10. 10 HTML5 APIs Worth Looking Into

    The tools available to create powerful applications on the web platform are getting better with each passing year. The HTML5 specification has added a number of useful features in new APIs that you may not have delved into yet, likely because of the lack of browser support.

    In this post, we’ll take a look at 10 HTML5 APIs that cover a whole slew of functionality and features that can help you create interactive websites, test the performance of your code, interact with a user’s device, and much more.

    And as you’ll see, support for these features is probably a lot better than you might think.