Kyle M. Perkins

After taking some time to get back into my craft, I realized that I had missed a lot of advancements in the HTML world, especially the evolution of the HTML API. Yes, there actually is an HTML API.

While researching some of the "new" API, I came across a bunch of articles by Aurelio De Rosa via SitePoint (a lot of good stuff there), and one of the items that caught my attention was the "Web Notifications API." Now, I will say that this stuff is still experimental (see the W3C's Working Draft for Notifications, so it's not widely supported and may even disappear. But for now, it's pretty awesome!)

Anyway, I'm sure you're not here to hear read about my day, so let's get to the point of the matter: HTML API - specifically, the Web Notifications API.

What are "Web Notifications"?

If you use an email system like Gmail or Outlook, chances are you've already seen something like this:

Well, those are technically desktop notifications and are usually controlled by software, not browsers. (Prior to HTML5, in order to get Desktop Notifications for Gmail, you had to download the "Gmail Notifier" application, and Outlook is already a software program to begin with).

The main difference is that these notifications (like the one above) are controlled by the browser - yes, the browser can control (certain) desktop notifications, and it's actually quite simple.

How to Use It

In an HTML file, add this bit of Javascript:

var notification = new Notification("New Email Received", { icon: "mail.png" })

That's pretty much it. No external libraries to load, no frameworks to bend around your whim - it's automatically built in to most modern browsers. Now, I know what you're asking: "What? That seems too simple! There has to be more." Don't worry, that was just the extremely core concept (provided by W3C). Technically, there is one more step to do: your application must first ask for permission before doing anything with the visitor's computer. (Yes, I know this seems a bit backwards, but for privacy, I can understand - especially with all of the ActiveX IE vaulnerabilities out there). This seems that the W3C wants to get rid of, but for now, it stays. (W3C says: Warning: In designing the platform notifications are the one instance thus far where asking the user upfront makes sense. Specifications for other APIs should not use this pattern and instead employ one of the many more suitable alternatives. [ref])

Notification.requestPermission(function(){
 
    //we're declaring a new object here
 
    var notification = new Notification(title, options);
 
});

There are 3 states to the "Permission" request: default (equivilant to "denied", because a choice has not been made yet), denied (the user denied the access, and therefore the request cannot proceed), or granted (the green light). This is similiar to when a browser (and/or application) asks to automatically use your physical location to determine items near you, like so:


If you haven't already allowed a site to display desktop notifications (or allowed for geolocation, as the above image), then it will ask you for permission before proceeding:


Overall, in accordance with "best practices", here's what I have learned/uncovered/researched:

First, you need to check to see if the API is supported. As this is still in the works, it isn't fully supported everywhere (for example, only Chrome, Firefox, and Safari 7+ support this - see http://caniuse.com/#feat=notifications for the full supported range).

In order to detect if the API is supported, add this bit of JS before you go calling Notifications.

//check to see if the API is supported
 
if (!('Notification' in window)){
 
    //API not supported. Show a message or something
 
    ....
 
} else {
 
    // API is supported. Do things
 
    ....
 
}

Therefore, if you have any buttons, links, or other items that make the notifications appear based on calling them, then you can disable them safely (or, if you are basing it off of automatic notifications, like emails, scores, or calendars, you can safety defer the notifications instead of having an error thrown).

Let's get fancy

The above sample is pretty much all you need to know for calling Notifications. If you want to get a little fancy with things, try this:

title = 'Email Received';
 
options = {
 
    body: 'You have a total of 3 unread emails',
 
    tag: 'preset', //The UID of the notification
 
    icon: 'https://mail.google.com/mail/u/0/images/favicon2.ico'
 
};

Before we go into detail about this, let's break it down:

• title: This is the title of the Notification (duh)


• options: This outlines a few of the Instance options available in the API
  (technically, everything is optional)
  
  
  • dir: This determines the text direction that the notification will be displayed (options are auto, ltr (left to right), or rtl (right to left) (default: auto)
  
  
  • lang: The language that the notification should be displayed in (example: 'en' for 'english') - (default: default language for computer)
  
  
  • body: The message that is displayed in the notification, like the body of a letter (default: blank)
  
  
  • tag: I like to think of this as the UID (Unique IDentifier) of the notification. Examples in the W3C Draft Documentation show usage of multiple instances of notification windows, so if you want one for your Email, Calendar, Reminders, etc, you can name each appropriately instead of just having to fall back on just 1. (default: blank)
  
  
  • icon: If you have a jpg, png, ico, or any other image file to show with the notification, you can list it here (I'd recommend the full absolute path of a web file instead of locally) (default: blank)

Those are all of the options available for the Notification API right now. Maybe more will come in the future - it just depends on what the official word is on the development.

FAQ

Can the notification automatically close after a few seconds?

I'd like to say 'yes', but the answer is unfortunately, no - at least, not completely.

I've tested my demo in Chrome and Firefox and had different results. I set up a setTimeout right after the notification is shown and tested it.

notification.onshow = function() { setTimeout(notification.close, 15000) }

However, Firefox displays the notification and automatically dismisses it after 5 seconds, regardless of the timeout, and Chrome will display the notification until you close it. Apparently, the problem is that the drafted Event Handlers don't register in the browsers, yet. I've tried to implement a calling feature of event.type == 'onshow', then call the setTimeout function, but to no avail. I've also tried to match up the event.type prior to the forEach function, but yet again, nothing.

Demo

In case you missed it above, here's the live demo again. It provides a call button that calls the notification on demand. I'm sure you can play around with it and figure out how it works.

References

Mozilla Dev Documentation: https://developer.mozilla.org/en-US/docs/Web/API/Notification W3C Draft: w3.org/TR/notifications/ Articles by Aurelio De Rosa: sitepoint.com/author/aderosa/ Aurelio's Notifications API Demo: http://aurelio.audero.it/demo/web-notifications-api-demo.html "Can I Use" browser feature comparison: http://caniuse.com/#feat=notifications