Paul Kinlan on web.dev

Farewell to HTML5Rocks

2022-06-29T00:00:00Z

After 10 years and 100 million pageviews this commit completes our transition of content of HTML5Rocks to homes that are maintained on developer.chrome.com and web.dev. It feels like a bit of an end of an era.

I was around for the founding of HTML5Rocks. We had so much fun building the serving infrastructure (several times) and creating a lot of the content—from walkthroughs of WebSQL and AppCache, the first introductions to new APIs such as IndexedDB, and explainers for How the Browser works.

Our most popular article was about CORS (Cross Origin Resource Sharing), followed by dragging and dropping files, and then one of the first introductions to getUserMedia and WebRTC. Contrasting the popularity of core "simple" tasks against the new and shiny capabilities is something that impacts developers today just as much as it did in 2012.

One thing I will miss the most is the community that developed around the site. HTML5Rocks was the first public site I helped to create that managed to build a huge community around it. It was one of the quickest ways to get feedback from developers that could be fed right back into the browser engineering teams. However, over the last couple of years as our priorities changed, "HTML5" became "HTML", and we slowly stopped creating new content and engaging with the community on the site. As the founders of our team moved on, I was left as the only person who could deploy the site and so I felt it was time to ensure that we had a permanent home that has a dedicated team supporting both the content and the infrastructure.

With this transition it was important for us to maintain the content (it's still valuable), but more importantly maintain the in-bound links. People found our content interesting enough for them to share with their audiences, so I'd like to maintain that trust given to us and ensure that all the links will still resolve to the content. If you do see an issue with any of the content, reach out to us and file an issue on web.dev or developer.chrome.com issue trackers.

Thank you to everyone who wrote content for the site, for the people who translated the content so that it could be read everywhere, and all the readers and commenters who made the site the place to go and learn about what's new on the web.

I'm off to register HTMLLivingStandardRocks.com…

♥️ Paul

Photo by Oliver Paaske on Unsplash

Google I/O 2022: That's a wrap!

2022-05-13T00:00:00Z

At Google IO 2022 we shared updates on our progress to help create a web that is instant, and connects people, no matter their device or bandwidth. A powerful platform that delivers experiences that we once never thought possible in a browser. And one that people can trust to keep their data safe. Here's a recap on how we're making it easy for you to build experiences that people will love.

An instant web #

Great web performance is a partnership between the browser and web developers. That's why we've made it easy for you to measure how well your website performs with the three Core Web Vitals. Optimizing your Vitals results in a better user experience, and better discoverability through Google Search. Be sure to check out our session, Core Web Vitals in the real world to learn how websites around the world are optimizing their scores to achieve better user experiences.

Largest Contentful Paint (LCP) is an important, user-centric metric for measuring perceived load speed. A fast LCP helps reassure the user that the page is useful, because it marks the point in the page load timeline when the main content has loaded. To learn more about this complex metric, check out our session, A deep dive into optimizing LCP.

Another new performance metric is something we are calling Interaction to Next Paint (INP). Unlike First Input Delay, it considers not just the first interaction, but all interactions on a page. INP therefore does a better job of capturing the interaction latency as experienced by the user. Learn more by checking out The State of Responsiveness on the Web session. For help with your performance journey, be sure to check out the new Performance Insights panel in Chrome DevTools along with many more updates based on your feedback.

Powerful capabilities #

Since last I/O, an array of new APIs have landed in stable Chrome. These unlock powerful new web experiences for the user. One of my favorite examples is how Adobe brought Creative Cloud to the web, starting with Photoshop and Illustrator.

We're also continuing to expand on the ways websites can integrate with the underlying operating system and hardware. Advanced apps now have the capability to seamlessly integrate with the operating system, so users can find the app on their desktop or homescreen, or easily access their files. We've also continued to improve installability, so be sure to check out how to make a richer install experience.

Safe and secure #

Chrome innovation extends to our work on user privacy and security. That's why we're taking a different approach by providing a path for developers to maintain functionality, while keeping the user safe. This is our Privacy Sandbox vision. Learn more about the progress we've made to phase out third-party cookies and land new APIs without cross-site tracking. We have a number of new origin trials that you can participate in today that will help you preserve web functionality, while safeguarding user privacy.

And to keep users safe from phishing, we need better authentication methods. We're removing the friction of sign on and passwords with passkeys, which you can learn more in our session, A path to a world without passwords.

Beautiful and delightful #

This last year has seen huge improvements across all browsers in CSS and layout primitives. For Chrome, RenderingNG has made it possible to deliver a number of features that have been long hoped for by developers. Watch our State of CSS and explore new styling APIs available today and tomorrow: container queries, subgrid, color functions, or check out our Shared Element Transitions talk to learn how we are working to bring seamless transitions between pages.

Simplifying web development #

We share our innovation through Chromium, our open-source browser project that brings the web to Android apps, TVs and VR headsets, and is the engine powering other browsers.

We're mindful that your priorities are for building features that work across many browsers. Learn about how we, along with other browsers, are working together to make it easier to develop for the web by ensuring features are interoperable so you can focus on building rich web experiences for users.

Finally, be sure to check out our What's new for the web platform keynote where we'll walk you through the latest web platform features and their availability across browsers so you know when you can rely on them in your sites and apps.

Quickly create nice CSS gradients with the CSS Gradient Creator

2022-05-04T00:00:00Z

This CSS Gradient Generator by Josh W Comeau is a very good, simple Web App that helps you to create "Beautiful, lush gradients".

I personally struggle mapping the syntax to a visual so this tool has been a great help for me. It focuses on creating linear gradients and it allows you to configure them using a number of different color modes (like HCL) even though they aren't directly supported on the linear-gradient CSS function. Josh's supporting blog post goes into more detail about how the color interpolation is calculated and applied to something the browser can render—it's a fascinating read into some of the theory behind how it works.

Linear gradient #

Browser support

Chrome 26, Supported 26
Firefox 16, Supported 16
Edge 12, Supported 12
Safari 7, Supported 7

Source

Hero image by Luke Chesser on Unsplash

Recording Audio from the User

2016-08-23T00:00:00Z

Many browsers now have the ability to access video and audio input from the user. However, depending on the browser, it might be a full dynamic and inline experience, or it could be delegated to another app on the user's device.

Start simple and progressively #

The easiest thing to do is simply ask the user for a pre-recorded file. Do this by creating a simple file input element and adding an accept filter that indicates we can only accept audio files, and a capture attribute that indicates we want to get it direct from the microphone.

<input type="file" accept="audio/*" capture />

This method works on all platforms. On desktop, it will prompt the user to upload a file from the file system (ignoring the capture attribute). In Safari on iOS, it will open up the microphone app, allowing you to record audio and then send it back to the web page; on Android, it will give the user the choice of which app to use record the audio in before sending it back to the web page.

Once the user has finished recording and they are back in the website, you need to somehow get ahold of the file data. You can get quick access by attaching an onchange event to the input element and then reading the files property of the event object.

<input type="file" accept="audio/*" capture id="recorder" />
<audio id="player" controls></audio>
  <script>
    const recorder = document.getElementById('recorder');
    const player = document.getElementById('player');

    recorder.addEventListener('change', function (e) {
      const file = e.target.files[0];
      const url = URL.createObjectURL(file);
      // Do something with the audio file.
      player.src = url;
    });
  </script>
</audio>

Once you have access to the file, you can do anything you want with it. For example, you can:

Attach it directly to an <audio> element so that you can play it
Download it to the user's device
Upload it to a server by attaching it to an XMLHttpRequest
Pass it through the Web Audio API and apply filters on to it

Whilst using the input element method of getting access to audio data is ubiquitous, it is the least appealing option. We really want to get access to the microphone and provide a nice experience directly in the page.

Access the microphone interactively #

Modern browsers can have a direct line to the microphone allowing us to build experiences that are fully integrated with the web page and the user will never leave the browser.

Acquire access to the microphone #

We can directly access the Microphone by using an API in the WebRTC specification called getUserMedia(). getUserMedia() will prompt the user for access to their connected microphones and cameras.

If successful the API will return a Stream that will contain the data from either the camera or the microphone, and we can then either attach it to an <audio> element, attach it to a WebRTC stream, attach it to a Web Audio AudioContext, or save it using the MediaRecorder API.

To get data from the microphone, we just set audio: true in the constraints object that is passed to the getUserMedia() API.

<audio id="player" controls></audio>
<script>
  const player = document.getElementById('player');

  const handleSuccess = function (stream) {
    if (window.URL) {
      player.srcObject = stream;
    } else {
      player.src = stream;
    }
  };

  navigator.mediaDevices
    .getUserMedia({audio: true, video: false})
    .then(handleSuccess);
</script>

If you want to choose a particular microphone, you can first enumerate the available microphones.

navigator.mediaDevices.enumerateDevices().then((devices) => {
  devices = devices.filter((d) => d.kind === 'audioinput');
});

You can then pass the deviceId that you wish to use when you call getUserMedia.

navigator.mediaDevices.getUserMedia({
  audio: {
    deviceId: devices[0].deviceId,
  },
});

By itself, this isn't that useful. All we can do is take the audio data and play it back.

Access the raw data from the microphone #

To access the raw data from the microphone, we have to take the stream created by getUserMedia() and then use the Web Audio API to process the data. The Web Audio API is a simple API that takes input sources and connects those sources to nodes which can process the audio data (adjust Gain etc.) and ultimately to a speaker so that the user can hear it.

One of the nodes that you can connect is an AudioWorkletNode. This node gives you the low-level capability for custom audio processing. The actual audio processing happens in the process() callback method in the AudioWorkletProcessor. Call this function to feed inputs and parameters and fetch outputs.

Check out Enter Audio Worklet to learn more.

<script>
  const handleSuccess = async function(stream) {
    const context = new AudioContext();
    const source = context.createMediaStreamSource(stream);

    await context.audioWorklet.addModule("processor.js");
    const worklet = new AudioWorkletNode(context, "worklet-processor");

    source.connect(worklet);
    worklet.connect(context.destination);
  };

  navigator.mediaDevices.getUserMedia({ audio: true, video: false })
      .then(handleSuccess);
</script>

// processor.js
class WorkletProcessor extends AudioWorkletProcessor {
  process(inputs, outputs, parameters) {
    // Do something with the data, e.g. convert it to WAV
    console.log(inputs);
    return true;
  }
}

registerProcessor("worklet-processor", WorkletProcessor);

The data that is held in the buffers is the raw data from the microphone and you have a number of options with what you can do with that data:

Upload it straight to the server
Store it locally
Convert it to a dedicated file format, such as WAV, and then save it to your servers or locally

Save the data from the microphone #

The easiest way to save the data from the microphone is to use the MediaRecorder API.

The MediaRecorder API will take the stream created by getUserMedia and then progressively save the data that is on the stream into your preferred destination.

<a id="download">Download</a>
<button id="stop">Stop</button>
<script>
  const downloadLink = document.getElementById('download');
  const stopButton = document.getElementById('stop');


  const handleSuccess = function(stream) {
    const options = {mimeType: 'audio/webm'};
    const recordedChunks = [];
    const mediaRecorder = new MediaRecorder(stream, options);

    mediaRecorder.addEventListener('dataavailable', function(e) {
      if (e.data.size > 0) recordedChunks.push(e.data);
    });

    mediaRecorder.addEventListener('stop', function() {
      downloadLink.href = URL.createObjectURL(new Blob(recordedChunks));
      downloadLink.download = 'acetest.wav';
    });

    stopButton.addEventListener('click', function() {
      mediaRecorder.stop();
    });

    mediaRecorder.start();
  };

  navigator.mediaDevices.getUserMedia({ audio: true, video: false })
      .then(handleSuccess);
</script>

In our case, we are saving the data directly into an array that we can later turn into a Blob, which can be then used to save the data to our Web Server or directly to the storage on the user's device.

Ask permission to use microphone responsibly #

If the user has not previously granted your site access to the microphone, then the instant that you call getUserMedia, the browser will prompt the user to grant your site permission to the microphone.

Users hate getting prompted for access to powerful devices on their machine and they will frequently block the request, or they will ignore it if they don't understand the context of which the prompt has been created. It is best practice to only ask to access the microphone when first needed. Once the user has granted access, they won't be asked again, however, if they reject access, you can't ask the user for permission again.

Use the permissions API to check if you already have access #

The getUserMedia API provides you with no knowledge of if you already have access to the microphone. This presents you with a problem, to provide a nice UI to get the user to grant you access to the microphone, you have to ask for access to the microphone.

This can be solved in some browsers by using the Permission API. The navigator.permission API allows you to query the state of the ability to access specific API's without having to prompt again.

To query if you have access to the user's microphone, you can pass in {name: 'microphone'} into the query method and it will return either:

granted — the user has previously given you access to the microphone;
prompt — the user has not given you access and will be prompted when you call getUserMedia;
denied — the system or the user has explicitly blocked access to the microphone and you won't be able to get access to it.

And you can now quickly check to see if you need to alter your user interface to accommodate the actions that the user needs to take.

navigator.permissions.query({name: 'microphone'}).then(function (result) {
  if (result.state == 'granted') {
  } else if (result.state == 'prompt') {
  } else if (result.state == 'denied') {
  }
  result.onchange = function () {};
});

Feedback #

Capturing an image from the user

2016-08-23T00:00:00Z

Many browsers now have the ability to access video and audio input from the user. However, depending on the browser it might be a full dynamic and inline experience, or it could be delegated to another app on the user's device. On top of that, not every device even has a camera. So how can you create an experience that uses a user generated image that works well everywhere?

Start simple and progressively #

If you want to progressively enhance your experience, you need to start with something that works everywhere. The easiest thing to do is simply ask the user for a pre-recorded file.

Ask for a URL #

This is the best supported but least satisfying option. Get the user to give you a URL, and then use that. For just displaying the image this works everywhere. Create an img element, set the src and you're done.

Though, if you want to manipulate the image in any way, things are a bit more complicated. CORS prevents you from accessing the actual pixels unless the server sets the appropriate headers and you mark the image as crossorigin ; the only practical way around that is to run a proxy server.

File input #

You can also use a simple file input element, including an accept filter that indicates you only want image files.

<input type="file" accept="image/*" />

This method works on all platforms. On desktop it will prompt the user to upload an image file from the file system. In Chrome and Safari on iOS and Android this method will give the user a choice of which app to use to capture the image, including the option of taking a photo directly with the camera or choosing an existing image file.

The data can then be attached to a <form> or manipulated with JavaScript by listening for an onchange event on the input element and then reading the files property of the event target.

<input type="file" accept="image/*" id="file-input" />
<script>
  const fileInput = document.getElementById('file-input');

  fileInput.addEventListener('change', (e) =>
    doSomethingWithFiles(e.target.files),
  );
</script>

The files property is a FileList object, which I'll talk more about later.

You can also optionally add the capture attribute to the element, which indicates to the browser that you prefer getting an image from the camera.

<input type="file" accept="image/*" capture />
<input type="file" accept="image/*" capture="user" />
<input type="file" accept="image/*" capture="environment" />

Adding the capture attribute without a value let's the browser decide which camera to use, while the "user" and "environment" values tell the browser to prefer the front and rear cameras, respectively.

The capture attribute works on Android and iOS, but is ignored on desktop. Be aware, however, that on Android this means that the user will no longer have the option of choosing an existing picture. The system camera app will be started directly, instead.

Drag and drop #

If you are already adding the ability to upload a file, there are a couple of easy ways that you can make the user experience a little richer.

The first is to add a drop target to your page that allows the user to drag in a file from the desktop or another application.

<div id="target">You can drag an image file here</div>
<script>
  const target = document.getElementById('target');

  target.addEventListener('drop', (e) => {
    e.stopPropagation();
    e.preventDefault();

    doSomethingWithFiles(e.dataTransfer.files);
  });

  target.addEventListener('dragover', (e) => {
    e.stopPropagation();
    e.preventDefault();

    e.dataTransfer.dropEffect = 'copy';
  });
</script>

Similar to the file input, you can get a FileList object from the dataTransfer.files property of the drop event;

The dragover event handler lets you signal to the user what will happen when they drop the file by using the dropEffect property.

Drag and drop has been around for a long time and is well-supported by the major browsers.

Paste from clipboard #

The final way to get an existing image file is from the clipboard. The code for this is very simple, but the user experience is a little harder to get right.

<textarea id="target">Paste an image here</textarea>
<script>
  const target = document.getElementById('target');

  target.addEventListener('paste', (e) => {
    e.preventDefault();
    doSomethingWithFiles(e.clipboardData.files);
  });
</script>

(e.clipboardData.files is yet another FileList object.)

The tricky part with the clipboard API is that, for full cross-browser support, the target element needs to be both selectable and editable. Both <textarea> and <input type="text"> fit the bill here, as do elements with the contenteditable attribute. But these are also obviously designed for editing text.

It can be difficult to make this work smoothly if you don't want the user to be able to input text. Tricks like having a hidden input that gets selected when you click on some other element may make maintaining accessibility harder.

Handling a FileList object #

Since most of the above methods produce a FileList, I should talk a little about what that is.

A FileList is similar to an Array. It has numeric keys and a length property, but it isn't actually an array. There are no array methods, like forEach() or pop(), and it isn't iterable. Of course, you can get a real Array by using Array.from(fileList).

The entries of the FileList are File objects. These are exactly the same as Blob objects except that they have additional name and lastModified read-only properties.

<img id="output" />
<script>
  const output = document.getElementById('output');

  function doSomethingWithFiles(fileList) {
    let file = null;

    for (let i = 0; i < fileList.length; i++) {
      if (fileList[i].type.match(/^image\//)) {
        file = fileList[i];
        break;
      }
    }

    if (file !== null) {
      output.src = URL.createObjectURL(file);
    }
  }
</script>

This example finds the first file that has an image MIME type, but it could also handle multiple images being selected/pasted/dropped at once.

Once you have access to the file you can do anything you want with it. For example, you can:

Draw it into a <canvas> element so that you can manipulate it
Download it to the user's device
Upload it to a server with fetch()

Access the camera interactively #

Now that you've covered your bases, it's time to progressively enhance!

Modern browsers can get direct access to cameras, allowing you to build experiences that are fully integrated with the web page, so the user need never leave the browser.

Acquire access to the camera #

You can directly access a camera and microphone by using an API in the WebRTC specification called getUserMedia(). This will prompt the user for access to their connected microphones and cameras.

Support for getUserMedia() is pretty good, but it isn't yet everywhere. In particular, it is not available in Safari 10 or lower, which at the time of writing is still the latest stable version. However, Apple have announced that it will be available in Safari 11.

It's very simple to detect support, however.

const supported = 'mediaDevices' in navigator;

When you call getUserMedia(), you need to pass in an object that describes what kind of media you want. These choices are called constraints. There are a several possible constraints, covering things like whether you prefer a front- or rear-facing camera, whether you want audio, and your preferred resolution for the stream.

To get data from the camera, however, you need just one constraint, and that is video: true.

If successful the API will return a MediaStream that contains data from the camera, and you can then either attach it to a <video> element and play it to show a real time preview, or attach it to a <canvas> to get a snapshot.

<video id="player" controls autoplay></video>
<script>
  const player = document.getElementById('player');

  const constraints = {
    video: true,
  };

  navigator.mediaDevices.getUserMedia(constraints).then((stream) => {
    player.srcObject = stream;
  });
</script>

By itself, this isn't that useful. All you can do is take the video data and play it back. If you want to get an image, you have to do a little extra work.

Grab a snapshot #

Your best supported option for getting an image is to draw a frame from the video to a canvas.

Unlike the Web Audio API, there isn't a dedicated stream processing API for video on the web so you have to resort to a tiny bit of hackery to capture a snapshot from the user's camera.

The process is as follows:

Create a canvas object that will hold the frame from the camera
Get access to the camera stream
Attach it to a video element
When you want to capture a precise frame, add the data from the video element to a canvas object using drawImage().

<video id="player" controls autoplay></video>
<button id="capture">Capture</button>
<canvas id="canvas" width="320" height="240"></canvas>
<script>
  const player = document.getElementById('player');
  const canvas = document.getElementById('canvas');
  const context = canvas.getContext('2d');
  const captureButton = document.getElementById('capture');

  const constraints = {
    video: true,
  };

  captureButton.addEventListener('click', () => {
    // Draw the video frame to the canvas.
    context.drawImage(player, 0, 0, canvas.width, canvas.height);
  });

  // Attach the video stream to the video element and autoplay.
  navigator.mediaDevices.getUserMedia(constraints).then((stream) => {
    player.srcObject = stream;
  });
</script>

Once you have data from the camera stored in the canvas you can do many things with it. You could:

Upload it straight to the server
Store it locally
Apply funky effects to the image

Tips #

Stop streaming from the camera when not needed #

It is good practice to stop using the camera when you no longer need it. Not only will this save battery and processing power, it will also give users confidence in your application.

To stop access to the camera you can simply call stop() on each video track for the stream returned by getUserMedia().

<video id="player" controls autoplay></video>
<button id="capture">Capture</button>
<canvas id="canvas" width="320" height="240"></canvas>
<script>
  const player = document.getElementById('player');
  const canvas = document.getElementById('canvas');
  const context = canvas.getContext('2d');
  const captureButton = document.getElementById('capture');

  const constraints = {
    video: true,
  };

  captureButton.addEventListener('click', () => {
    context.drawImage(player, 0, 0, canvas.width, canvas.height);

    // Stop all video streams.
    player.srcObject.getVideoTracks().forEach(track => track.stop());
  });

  navigator.mediaDevices.getUserMedia(constraints).then((stream) => {
    // Attach the video stream to the video element and autoplay.
    player.srcObject = stream;
  });
</script>

Ask permission to use camera responsibly #

If the user has not previously granted your site access to the camera then the instant that you call getUserMedia() the browser will prompt the user to grant your site permission to the camera.

Users hate getting prompted for access to powerful devices on their machine and they will frequently block the request, or they will ignore it if they don't understand the context for which the prompt has been created. It is best practice to only ask to access the camera when first needed. Once the user has granted access they won't be asked again. However, if the user rejects access, you can't get access again, unless they manually change camera permission settings.

Compatibility #

More information about mobile and desktop browser implementation:

We also recommend using the adapter.js shim to protect apps from WebRTC spec changes and prefix differences.

Feedback #

Beyond the Rack

2015-10-25T00:00:00Z

Beyond the Rack re-engages users on the mobile web, increasing revenue per visit by 26% with push notifications.

Push notifications allowed us to bring one of the most compelling capabilities from our native app to our mobile site. We see a direct 20% click-through rate from push notifications—having another channel to reach our users is a game changer.

Richard Cohene, VP Marketing, Beyond the Rack

Key Insights #

52% of total users are mobile web
26% is the average increase in spend that occurred by members who visited via push
20% click through rate from push notifications
72% more time spent on the site per visit from members who visited via push notifications

Download PDF Case study

About Beyond the Rack #

Beyond the Rack is a leading online retailer that runs sale events of designer products for its 14 million members globally. Until recently, the company primarily depended on targeted, daily emails to re-engage users. Recent internal research showed that 52% of users were visiting their site via the mobile web, so they looked for ways to improve their mobile engagement and sales. At this point Beyond the Rack reached out to their mobile shopping platform partner Mobify. Working with Mobify, Beyond the Rack implemented push notifications on their mobile website and saw a 50% increase in repeat visits within 3 months. The company also found push notifications delivered higher value visits, with members spending 26% more per visit on average.

Timely, relevant notifications #

Every day, Beyond the Rack sends emails to their members about new and exclusive sales events. With limited sale periods—usually 48 hours—the company couldn’t rely solely on customers checking their email to generate sales. Beyond the Rack’s new push notifications provided a 20% click through rate which worked perfectly for flash sales alerts. The notifications also provided Beyond the Rack with another touchpoint to interact with a highly-engaged and commercially-valuable audience.

High attention users arrive from push notifications #

Beyond the Rack members who visited the site via push notifications spent 72% more time on the site per visit and shopped more often than the average visitor. By creating timely pushes, Beyond the Rack increased the relevance and excitement of their pushes - and customers showed their love through higher sales.

The value of web-based push notifications for business #

More than 50% of new members discover Beyond the Rack via the mobile web so having an avenue to re-engage them after this initial interaction in a personalized way makes it more than just a platform for discovery. Because push messages appear at the front of a customer’s mobile phone home screen, they prompt greater response and more immediate action.

About Push Notification #

Push notifications enable your mobile web users to choose to receive notifications on their device just like an installed native app. This lets you effectively re-engage them with customized, compelling content.

More Information #

For more information on Push Notifications on the web check out our resources:

User Location

2014-01-01T00:00:00Z

The Geolocation API lets you discover, with the user's consent, the user's location. You can use this functionality for things like guiding a user to their destination and geo-tagging user-created content; for example, marking where a photo was taken.

The Geolocation API also lets you see where the user is and keep tabs on them as they move around, always with the user's consent (and only while the page is open). This creates a lot of interesting use cases, such as integrating with backend systems to prepare an order for collection if the user is close by.

You need to be aware of many things when using the Geolocation API. This guide walks you through the common use cases and solutions.

Summary #

Use geolocation when it benefits the user.
Ask for permission as a clear response to a user gesture.
Use feature detection in case a user's browser doesn't support geolocation.
Don't just learn how to implement geolocation; learn the best way to use geolocation.
Test geolocation with your site.

When to use geolocation #

Find where the user is closest to a specific physical location to tailor the user experience.
Tailor information (such as news) to the user's location.
Show the position of a user on a map.
Tag data created inside your application with the user's location (that is, geo-tag a picture).

Ask permission responsibly #

Recent user studies have shown that users are distrustful of sites that simply prompt the user to give away their position on page load. So what are the best practices?

Assume users will not give you their location #

Many of your users won't want to give you their location, so you need to adopt a defensive development style.

Handle all errors out of the geolocation API so that you can adapt your site to this condition.
Be clear and explicit about your need for the location.
Use a fallback solution if needed.

Use a fallback if geolocation is required #

We recommend that your site or application not require access to the user's current location. However, if your site or application requires the user's current location, there are third-party solutions that allow you to obtain a best guess of where the person currently is.

These solutions often work by looking at the user's IP address and mapping that to the physical addresses registered with the RIPE database. These locations are often not very accurate, normally giving you the position of the telecommunications hub or cell phone tower that is nearest to the user. In many cases, they might not even be that accurate, especially if the user is on VPN or some other proxy service.

Always request access to location on a user gesture #

Make sure that users understand why you’re asking for their location, and what the benefit to them will be. Asking for it immediately on the homepage as the site loads results in a poor user experience.

DO: Always request access to location on a user gesture.

DON'T: Ask for it on the homepage, as the site loads; this results in a poor user experience.

Instead, give the user a clear call to action or an indication that an operation will require access to their location. The user can then more easily associate the system prompt for access with the action just initiated.

Give a clear indication that an action will request their location #

In a study by the Google Ads team, when a user was asked to book a hotel room in Boston for an upcoming conference on one particular hotels site, they were prompted to share their GPS location immediately after tapping the "Find and Book" call to action on the homepage.

In some cases, the user became frustrated because they didn't understand why they were being shown hotels in San Francisco when they wanted to book a room in Boston.

A better experience is to make sure users understand why you’re asking them for their location. Add a well-known signifier that is common across devices, such as a range finder, or an explicit call to action such as “Find Near Me.”

Use a range finder

A specific call to action to find near me

Gently nudge users to grant permission to their location #

You don't have access to anything users are doing. You know exactly when users disallow access to their locations but you don't know when they grant you access; you only know you obtained access when results appear.

It's good practice to "nudge" users into action if you need them to complete the action.

We recommend:

Set up a timer that triggers after a short period; 5 seconds is a good value.
If you get an error message, show a message to the user.
If you get a positive response, disable the timer and process the results.
If, after the timeout, you haven't gotten a positive response, show a notification to the user.
If the response comes in later and the notification is still present, remove it from the screen.

button.onclick = function () {
  var startPos;
  var nudge = document.getElementById('nudge');

  var showNudgeBanner = function () {
    nudge.style.display = 'block';
  };

  var hideNudgeBanner = function () {
    nudge.style.display = 'none';
  };

  var nudgeTimeoutId = setTimeout(showNudgeBanner, 5000);

  var geoSuccess = function (position) {
    hideNudgeBanner();
    // We have the location, don't display banner
    clearTimeout(nudgeTimeoutId);

    // Do magic with location
    startPos = position;
    document.getElementById('startLat').innerHTML = startPos.coords.latitude;
    document.getElementById('startLon').innerHTML = startPos.coords.longitude;
  };
  var geoError = function (error) {
    switch (error.code) {
      case error.TIMEOUT:
        // The user didn't accept the callout
        showNudgeBanner();
        break;
    }
  };

  navigator.geolocation.getCurrentPosition(geoSuccess, geoError);
};

Browser support #

The majority of browsers now support the Geolocation API but it's a good practice to always check for support before you do anything.

You can easily check for compatibility by testing for the presence of the geolocation object:

// check for Geolocation support
if (navigator.geolocation) {
  console.log('Geolocation is supported!');
} else {
  console.log('Geolocation is not supported for this Browser/OS.');
}

Determining the user's current location #

The Geolocation API offers a simple, "one-shot" method to obtain the user's location: getCurrentPosition(). A call to this method asynchronously reports on the user's current location.

window.onload = function () {
  var startPos;
  var geoSuccess = function (position) {
    startPos = position;
    document.getElementById('startLat').innerHTML = startPos.coords.latitude;
    document.getElementById('startLon').innerHTML = startPos.coords.longitude;
  };
  navigator.geolocation.getCurrentPosition(geoSuccess);
};

If this is the first time that an application on this domain has requested permissions, the browser typically checks for user consent. Depending on the browser, there may also be preferences to always allow—or disallow—permission lookups, in which case the confirmation process is bypassed.

Depending on the location device your browser is using, the position object might actually contain a lot more than just latitude and longitude; for example, it might include an altitude or a direction. You can't tell what extra information that location system uses until it actually returns the data.

Watching the user's location #

The Geolocation API allows you to obtain the user's location (with user consent) with a single call to getCurrentPosition().

If you want to continually monitor the user's location, use the Geolocation API method, watchPosition(). It operates in a similar way to getCurrentPosition(), but it fires multiple times as the positioning software:

Gets a more accurate lock on the user.
Determines that the user's position is changing.

var watchId = navigator.geolocation.watchPosition(function (position) {
  document.getElementById('currentLat').innerHTML = position.coords.latitude;
  document.getElementById('currentLon').innerHTML = position.coords.longitude;
});

When to use geolocation to watch the user's location #

You want to obtain a more precise lock on the user location.
Your application needs to update the user interface based on new location information.
Your application needs to update business logic when the user enters a certain defined zone.

Best practices when using geolocation #

Always clear up and conserve battery #

Watching for changes to a geolocation is not a free operation. While operating systems might be introducing platform features to let applications hook in to the geo subsystem, you, as a web developer, have no idea what support the user's device has for monitoring the user's location, and, while you're watching a position, you are engaging the device in a lot of extra processing.

After you no longer need to track the user's position, call clearWatch to turn off the geolocation systems.

Handle errors gracefully #

Unfortunately, not all location lookups are successful. Perhaps a GPS could not be located or the user has suddenly disabled location lookups. In the event of an error, a second, optional argument to getCurrentPosition() is called so that you can notify the user inside the callback:

window.onload = function () {
  var startPos;
  var geoSuccess = function (position) {
    startPos = position;
    document.getElementById('startLat').innerHTML = startPos.coords.latitude;
    document.getElementById('startLon').innerHTML = startPos.coords.longitude;
  };
  var geoError = function (error) {
    console.log('Error occurred. Error code: ' + error.code);
    // error.code can be:
    //   0: unknown error
    //   1: permission denied
    //   2: position unavailable (error response from location provider)
    //   3: timed out
  };
  navigator.geolocation.getCurrentPosition(geoSuccess, geoError);
};

Reduce the need to start geolocation hardware #

For many use cases, you don't need the user's most up-to-date location; you just need a rough estimate.

Use the maximumAge optional property to tell the browser to use a recently obtained geolocation result. This not only returns more quickly if the user has requested the data before, but it also prevents the browser from starting its geolocation hardware interfaces such as Wifi triangulation or the GPS.

window.onload = function () {
  var startPos;
  var geoOptions = {
    maximumAge: 5 * 60 * 1000,
  };

  var geoSuccess = function (position) {
    startPos = position;
    document.getElementById('startLat').innerHTML = startPos.coords.latitude;
    document.getElementById('startLon').innerHTML = startPos.coords.longitude;
  };
  var geoError = function (error) {
    console.log('Error occurred. Error code: ' + error.code);
    // error.code can be:
    //   0: unknown error
    //   1: permission denied
    //   2: position unavailable (error response from location provider)
    //   3: timed out
  };

  navigator.geolocation.getCurrentPosition(geoSuccess, geoError, geoOptions);
};

Don't keep the user waiting, set a timeout #

Unless you set a timeout, your request for the current position might never return.

window.onload = function () {
  var startPos;
  var geoOptions = {
    timeout: 10 * 1000,
  };

  var geoSuccess = function (position) {
    startPos = position;
    document.getElementById('startLat').innerHTML = startPos.coords.latitude;
    document.getElementById('startLon').innerHTML = startPos.coords.longitude;
  };
  var geoError = function (error) {
    console.log('Error occurred. Error code: ' + error.code);
    // error.code can be:
    //   0: unknown error
    //   1: permission denied
    //   2: position unavailable (error response from location provider)
    //   3: timed out
  };

  navigator.geolocation.getCurrentPosition(geoSuccess, geoError, geoOptions);
};

Prefer a coarse location over a fine-grained location #

If you want to find the nearest store to a user, it's unlikely that you need 1-meter precision. The API is designed to give a coarse location that returns as quickly as possible.

If you do need a high level of precision, it's possible to override the default setting with the enableHighAccuracy option. Use this sparingly: it's slower to resolve and uses more battery.

window.onload = function () {
  var startPos;
  var geoOptions = {
    enableHighAccuracy: true,
  };

  var geoSuccess = function (position) {
    startPos = position;
    document.getElementById('startLat').innerHTML = startPos.coords.latitude;
    document.getElementById('startLon').innerHTML = startPos.coords.longitude;
  };
  var geoError = function (error) {
    console.log('Error occurred. Error code: ' + error.code);
    // error.code can be:
    //   0: unknown error
    //   1: permission denied
    //   2: position unavailable (error response from location provider)
    //   3: timed out
  };

  navigator.geolocation.getCurrentPosition(geoSuccess, geoError, geoOptions);
};

Emulate geolocation with Chrome DevTools #

Once you've got geolocation set up, you'll want to:

Test out how your app works in different geolocations.
Verify that your app degrades gracefully when geolocation is not available.

You can do both from Chrome DevTools.

Open Chrome DevTools.
Press Esc to Open the Console drawer.
Open the Console drawer menu
Click the Sensors option to show the Sensors tab.

From here you can override the location to a preset major city, enter a custom location, or disable geolocation by setting the override to Location unavailable.

Feedback #

Touch and mouse

2013-03-13T00:00:00Z

Introduction #

For close to thirty years, desktop computing experiences have centered around a keyboard and a mouse or trackpad as our main user input devices. Over the last decade, however, smartphones and tablets have brought a new interaction paradigm: touch. With the introduction of touch-enabled Windows 8 machines, and now with the release of the awesome touch-enabled Chromebook Pixel, touch is now becoming part of the expected desktop experience. One of the biggest challenges is building experiences that work not only on touch devices and mouse devices, but also on these devices where the user will use both input methods - sometimes simultaneously!

This article will help you understand how touch capabilities are built into the browser, how you can integrate this new interface mechanism into your existing apps and how touch can play nicely with mouse input.

The State of Touch in the Web Platform #

The iPhone was the first popular platform to have dedicated touch APIs built in to the web browser. Several other browser vendors have created similar API interfaces built to be compatible with the iOS implementation, which is now described by the "Touch Events version 1" specification. Touch events are supported by Chrome and Firefox on desktop, and by Safari on iOS and Chrome and the Android browser on Android, as well as other mobile browsers like the Blackberry browser.

My colleague Boris Smus wrote a great HTML5Rocks tutorial on Touch events that is still a good way to get started if you haven’t looked at Touch events before. In fact, if you haven’t worked with touch events before, go read that article now, before you continue. Go on, I’ll wait.

All done? Now that you have a basic grounding in touch events, the challenge with writing touch-enabled interactions is that the touch interactions can be quite a bit different from mouse (and mouse-emulating trackpad and trackball) events - and although touch interfaces typically try to emulate mice, that emulation isn’t perfect or complete; you really need to work through both interaction styles, and may have to support each interface independently.

Most Importantly: The User May Have Touch And a Mouse #

Many developers have built sites that statically detect whether an environment supports touch events, and then make the assumption that they only need to support touch (and not mouse) events. This is now a faulty assumption - instead, just because touch events are present does not mean the user is primarily using that touch input device. Devices such as the Chromebook Pixel and some Windows 8 laptops now support BOTH Mouse and Touch input methods, and more will in the near future. On these devices, it is quite natural for users to use both the mouse and the touch screen to interact with applications, so "supports touch" is not the same as "doesn’t need mouse support." You can’t think of the problem as "I have to write two different interaction styles and switch between them," you need to think through how both interactions will work together as well as independently. On my Chromebook Pixel, I frequently use the trackpad, but I also reach up and touch the screen - on the same application or page, I do whatever feels most natural at the moment. On the other hand, some touchscreen laptop users will rarely if ever use the touchscreen at all - so the presence of touch input shouldn’t disable or hinder mouse control.

Unfortunately, it can be hard to know if a user’s browser environment supports touch input or not; ideally, a browser on a desktop machine would always indicate support for touch events so a touchscreen display could be attached at any time (e.g. if a touchscreen attached through a KVM becomes available). For all these reasons, your applications shouldn’t attempt to switch between touch and mouse - just support both!

In IE10 on Windows 8, Microsoft introduced a new model called Pointer Events. Pointer Events are a unification of Mouse Events and touch input, as well as other input methods such as pen input. There is work to standardize the Pointer Event model at the W3C, and in the short term, there are libraries out there like PointerEvents and Hand.js that you can use to prototype how Pointer Events could work in your code to remove some of the need to independently support mouse and touch. For really great touch and mouse interaction, you may need to customize your user experience for mouse and touch separately, but unified event handling can make this easier in many scenarios. However, there are significant challenges with this model - namely, it requires supporting redundant input models, and it’s not broadly supported yet - and it will take some time to settle down into a solid, cross-browser standard. In the meantime, the best advice is to support both mouse and touch interaction models. There are a lot of challenges with simultaneously supporting touch and mouse events, so this article explains those challenges and the strategies to overcome them. Additionally, some of this advice is just general "implementing touch" advice, so it may be redundant if you are already used to implementing touch in a mobile context.

Supporting Mouse and Touch Together #

#1 - Clicking and Tapping - the "Natural" Order of Things #

The first problem is that touch interfaces typically try to emulate mouse clicks - obviously, since touch interfaces need to work on applications that have only interacted with mouse events before! You can use this as a shortcut - because "click" events will continue to be fired, whether the user clicked with a mouse or tapped their finger on the screen. However, there are a couple of problems with this shortcut.

First, you have to be careful when designing more advanced touch interactions: when the user uses a mouse it will respond via a click event, but when the user touches the screen both touch and click events will occur. For a single click the order of events is:

touchstart
touchmove
touchend
mouseover
mousemove
mousedown
mouseup
click

This, of course, means that if you are processing touch events like touchstart, you need to make sure that you don’t process the corresponding mousedown and/or click event as well. If you can cancel the touch events (call preventDefault() inside the event handler), then no mouse events will get generated for touch. One of the most important rules of touch handlers is:

However, this also prevents other default browser behavior (like scrolling) - although usually you’re handling the touch event entirely in your handler, and you will WANT to disable the default actions. In general, you’ll either want to handle and cancel all touch events, or avoid having a handler for that event.

Secondly, when a user taps on an element in a web page on a mobile device, pages that haven’t been designed for mobile interaction have a delay of at least 300 milliseconds between the touchstart event and the processing of mouse events (mousedown). It could be done using Chrome, you can turn on "Emulate touch events" in Chrome Developer Tools to help you test touch interfaces on a non-touch system!

This delay is to allow the browser time to determine if the user is performing another gesture - in particular, double-tap zooming. Obviously, this can be problematic in cases where you want to have instantaneous response to a finger touch. There is ongoing work to try to limit the scenarios in which this delay occurs automatically.

	Chrome for Android	Android Browser	Opera Mobile for Android)	Firefox for Android	Safari iOS
Non-scalable viewport	No delay	300ms	300ms	No delay	300ms
No Viewport	300ms	300ms	300ms	300ms	300ms

The first and easiest way to avoid this delay is to "tell" the mobile browser that your page is not going to need zooming - which can be done using a fixed viewport, e.g. by inserting into your page:

<meta name="viewport" content="width=device-width,user-scalable=no">

This isn’t always appropriate, of course - this disables pinch-zooming, which may be required for accessibility reasons, so use it sparingly if at all (if you do disable user scaling, you may want to provide some other way to increase text readability in your application). Also, for Chrome on desktop class devices that support touch, and other browsers on mobile platforms when the page has viewports that are not scalable, this delay does not apply.

#2: Mousemove Events Aren’t Fired by Touch #

It’s important to note at this point that the emulation of mouse events in a touch interface does not typically extend to emulating mousemove events - so if you build a beautiful mouse-driven control that uses mousemove events, it probably won’t work with a touch device unless you specifically add touchmove handlers too.

Browsers typically automatically implement the appropriate interaction for touch interactions on the HTML controls - so, for example, HTML5 Range controls will just work when you use touch interactions. However, if you’ve implemented your own controls, they will likely not work on click-and-drag type interactions; in fact, some commonly used libraries (like jQueryUI) do not yet natively support touch interactions in this way (although for jQueryUI, there are several monkey-patch fixes to this issue). This was one of the first problems I ran into when upgrading my Web Audio Playground application to work with touch - the sliders were jQueryUI-based, so they did not work with click-and-drag interactions. I changed over to HTML5 Range controls, and they worked. Alternately, of course, I could have simply added touchmove handlers to update the sliders, but there’s one problem with that…

#3: Touchmove and MouseMove Aren’t the Same Thing #

A pitfall I've seen a few developers fall into is having touchmove and mousemove handlers call into the same codepaths. The behavior of these events is very close, but subtly different - in particular, touch events always target the element where that touch STARTED, while mouse events target the element currently under the mouse cursor. This is why we have mouseover and mouseout events, but there are no corresponding touchover and touchout events - only touchend.

The most common way this can bite you is if you happen to remove (or relocate) the element that the user started touching. For example, imagine an image carousel with a touch handler on the entire carousel to support custom scrolling behavior. As available images change, you remove some <img> elements and add others. If the user happens to start touching on one of those images and then you remove it, your handler (which is on an ancestor of the img element) will just stop receiving touch events (because they’re being dispatched to a target that’s no longer in the tree) - it'll look like the user is holding their finger in one place even though they may have moved and eventually removed it.

You can of course avoid this problem by avoiding removing elements that have (or have ancestors that have) touch handlers while a touch is active. Alternately, the best guidance is rather than register static touchend/touchmove handlers, wait until you get a touchstart event and then add touchmove/touchend/touchcancel handlers to the target of the touchstart event (and remove them on end/cancel). This way you'll continue to receive events for the touch even if the target element is moved/removed. You can play with this a little here - touch the red box and while holding hit escape to remove it from the DOM.

#4: Touch and :Hover #

The mouse pointer metaphor separated cursor position from actively selecting, and this allowed developers to use hover states to hide and show information that might be pertinent to the users. However, most touch interfaces right now do not detect a finger "hovering" over a target - so providing semantically important information (e.g. providing "what is this control?" popup) based on hovering is a no-no, unless you also give a touch-friendly way to access this information. You need to be careful about how you use hovering to relay information to users.

Interestingly enough, though, the CSS :hover pseudoclass CAN be triggered by touch interfaces in some cases - tapping an element makes it :active while the finger is down, and it also acquires the :hover state. (With Internet Explorer, the :hover is only in effect while the user’s finger is down - other browsers keep the :hover in effect until the next tap or mouse move.) This is a good approach to making pop-out menus work on touch interfaces - a side effect of making an element active is that the :hover state is also applied. For example:

<style>
img ~ .content {
  display:none;
}

img:hover ~ .content {
  display:block;
}
</style>

<img src="/awesome.png">
<div class="content">This is an awesome picture of me</div>

Once another element is tapped the element is no longer active, and the hover state disappears, just as if the user was using a mouse pointer and moved it off the element. You may wish to wrap the content in an <a> element in order to make it a tabstop as well - that way the user can toggle the extra information on a mouse hover or click, a touch tap, or a keypress, with no JavaScript required. I was pleasantly surprised as I began work to make my Web Audio Playground to work well with touch interfaces that my pop-out menus already worked well on touch, because I’d used this kind of structure!

The above method works well for mouse pointer based interfaces, as well as for touch interfaces. This is in contrast to using "title" attributes on hover, which will NOT show up when the element is activated:

<img src="/awesome.png" title="this doesn't show up in touch">

#5: Touch vs. Mouse Precision #

While mice have a conceptual disassociation from reality, it turns out that they are extremely accurate, as the underlying operating system generally tracks exact pixel precision for the cursor. Mobile developers on the other hand have learned that finger touches on a touch screen are not as accurate, mostly because of the size of the surface area of the finger when in contact with the screen (and partly because your fingers obstruct the screen).

Many individuals and companies have done extensive user research on how to design applications and sites that are accommodating of finger based interaction, and many books have been written on the topic. The basic advice is to increase the size of the touch targets by increasing the padding, and reduce the likelihood of incorrect taps by increasing the margin between elements. (Margins are not included in the hit detection handling of touch and click events, while padding is.) One of the primary fixes I had to make to the Web Audio Playground was to increase the sizes of the connection points so they were more easily touched accurately.

Many browser vendors who are handling touch based interfaces have also introduced logic into the browser to help target the correct element when a user touches the screen and reduce the likelihood of incorrect clicks - although this usually only corrects click events, not moves (although Internet Explorer appears to modify mousedown/mousemove/mouseup events as well).

#6: Keep Touch Handlers Contained, or They’ll Jank Your Scroll #

It’s also important to keep touch handlers confined only to the elements where you need them; touch elements can be very high-bandwidth, so it’s important to avoid touch handlers on scrolling elements (as your processing may interfere with browser optimizations for fast jank-free touch scrolling - modern browsers try to scroll on a GPU thread, but this is impossible if they have to check with javascript first to see if each touch event is going to be handled by the app). You can check out an example of this behavior.

One piece of guidance to follow to avoid this problem is to make sure that if you are only handling touch events in a small portion of your UI, you only attach touch handlers there (not, e.g., on the <body> of the page); in short, limit the scope of your touch handlers as much as possible.

#7: Multi-touch #

The final interesting challenge is that although we’ve been referring to it as "Touch" user interface, nearly universally the support is actually for Multi-touch - that is, the APIs provide more than one touch input at a time. As you begin to support touch in your applications, you should consider how multiple touches might affect your application.

If you have been building apps primarily driven by mouse, then you are used to building with at most one cursor point - systems don’t typically support multiple mice cursors. For many applications, you will be just mapping touch events to a single cursor interface, but most of the hardware that we have seen for desktop touch input can handle at least 2 simultaneous inputs, and most new hardware appears to support at least 5 simultaneous inputs. For developing an onscreen piano keyboard, of course, you would want to be able to support multiple simultaneous touch inputs.

The currently implemented W3C Touch APIs have no API to determine how many touch points the hardware supports, so you’ll have to use your best estimation for how many touch points your users will want - or, of course, pay attention to how many touch points you see in practice and adapt. For example, in a piano application, if you never see more than two touch points you may want to add some "chords" UI. The PointerEvents API does have an API to determine the capabilities of the device.

Touching Up #

Hopefully this article has given you some guidance on common challenges in implementing touch alongside mouse interactions. More important than any other advice, of course, is that you need to test your app on mobile, tablet, and combined mouse-and-touch desktop environments. If you don’t have touch+mouse hardware, use Chrome’s "Emulate touch events" to help you test the different scenarios.

It’s not only possible, but relatively easy following these pieces of guidance, to build engaging interactive experiences that work well with touch input, mouse input, and even both styles of interaction at the same time.

Multiplayer audio fun

2011-07-01T00:00:00Z

Using the Web Audio API, WebSockets and a very nice designed UI here comes a demo where you can generate notes on the fly and with other people in real time. We will keep posting quick updates with the demos that developers around the world make with HTML5.

3D and CSS

2010-09-07T00:00:00Z

Introduction #

For a long time 3D has been the preserve of desktop applications. Recently with the introduction of advanced smart-phones that have access to native GPU acceleration we have started to see 3D used nearly everywhere.

Commonly, 3D is primarily used as a device for gaming or some advanced user interfaces. It wasn't until the introduction of Perspective transforms in WPF and Silverlight that a suitable model for applying 3D effects to user interface elements became a practical solution for application developers (after all 3D isn't exactly easy).

The CSS 3D Transform Model was introduced as a Draft specification in March 2009 to allow web developers to create interesting and compelling user interfaces that take advantage of 3D by allowing application authors to apply 3D perspective transformations to any visual DOM element.

The CSS 3D Transformation Working Draft is a logical extension to the CSS 2D Transformation Model, introducing some extra properties, including: perspectives, rotations and transforms in a 3D space.

Never before have we been able build 3D interfaces so easily. These technologies have lowered the barrier to entry. No longer do you have to be a mathematical whizz to build 3d elements.

It must be noted that the CSS 3D module is designed to help developers build rich and visually interesting applications, it is not designed to enable you to build immersive 3d worlds.

Browser Support and Hardware Acceleration #

-webkit-perspective #

Browser support

Chrome 36, Supported 36
Firefox 16, Supported 16
Edge 12, Supported 12
Safari 9, Supported 9

Source

-webkit-transform-3d #

Browser support

Chrome 2, Supported 2
Firefox 49, Supported 49
Edge 12, Supported 12
Safari 4, Supported 4

Source

The important piece of information to remember is that although a browser may "support" 3d, it may not be able to render 3D due to hardware and driver limitations. 3D scenes based on the DOM can be very computationally expensive and therefore browser vendors have decided rather than slow the browsers down with a pure software rendering solution, they instead will take advantage of GPU which might not be available on all platforms

Feature Detection #

What about feature detection? I was hoping that you weren't going to ask! Developers have been using tools such as Modernizr to detect support for specific browser features and abilities. Whilst it is possible to detect the presence of support for 3D transformations, it is not possible to detect for the presence of hardware acceleration, and hardware acceleration is the key ingredient.

Basic Sample #

There is nothing better than jumping straight in. In this sample we will apply a basic set of rotations of an arbitrary DOM element.

We start by defining a perspective on the root element.

<div style="-webkit-perspective: 800; perspective: 800; margin: 100px 0 0 50px">

Perspective is important because it defines how the depth of the 3D scene is rendered, values from 1-1000 will produce a very pronounced effect, and values over 1000 less so. We then add an iframe and apply a 30 degree rotation around the Z and Y axis

<iframe
    src="http://www.html5rocks.com/"
    style="-webkit-transform: rotate3d(0, 1, 1, 30deg)"></iframe>

BAM! That is it, the element is fully interactive, and in all respects it is a fully fledged DOM element (except that it now looks even cooler). If your browser doesn't support 3D transformations, nothing will happen. You will just see a simple iframe with no rotation applied. If your browser supports 3d transformations but without hardware acceleration, it might look a little odd.

Animating #

The thing that I love about CSS3 3D transformations is that it ties so beautifully with the CSS Transition module. Animations and transitions are easy to define in CSS, and applying these to 3d is no exception.

To animate elements that have a 3D perspective applied is easy. Simply set the "transition" style to be "transform", attach a duration and an animation function. From then on, any change to the "tranform" style will be animated.

We have re-factored the previous examples to use document styles, rather than inline styles. Not only does it clear the example up, it allows the sample to take advantage of the :hover pseudo selector. By using the :hover selector, transitions can be initiated by simply moving the mouse over the element. Awesome!

Summary #

This was just a quick glance over some of the cool effects that can be applied to any visible DOM element using CSS 3D transformations. There are still many things that can be done that have not been covered in this tutorial.

A simple TODO list using HTML5 WebDatabases

2010-02-17T00:00:00Z

Introduction #

Web Databases are new in HTML5. Web Databases are hosted and persisted inside a user's browser. By allowing developers to create applications with rich query abilities it is envisioned that a new breed of web applications will emerge that have the ability to work online and off-line.

The example code in this article demonstrates how to create a very simple todo list manager. It is a very high level tour of some of the features available in HTML5.

Pre-requisites #

This sample uses a namespace to encapsulate the database logic.

var html5rocks = {};
html5rocks.webdb = {};

Asynchronous and Transactional #

In the majority of cases where you are using Web Database support you will be using the Asynchronous API. The Asynchronous API is a non-blocking system and as such will not get data through return values, but rather will get data delivered to a defined callback function.

The Web Database support through HTML is transactional. It is no possible to execute SQL statements outside of a transaction. There are two types of transactions: read/write transactions (transaction()) and read only transactions (readTransaction()). Please note, read/write will lock the entire database.

Step 1. Opening the database #

The database needs to be opened before it can be accessed.
You need to define the name, version, description and the size of the database.

html5rocks.webdb.db = null;

html5rocks.webdb.open = function() {
var dbSize = 5 * 1024 * 1024; // 5MB
html5rocks.webdb.db = openDatabase("Todo", "1", "Todo manager", dbSize);
}

html5rocks.webdb.onError = function(tx, e) {
alert("There has been an error: " + e.message);
}

html5rocks.webdb.onSuccess = function(tx, r) {
// re-render the data.
// loadTodoItems is defined in Step 4a
html5rocks.webdb.getAllTodoItems(loadTodoItems);
}

Step 2. Creating a table #

You can only create a table by executing a CREATE TABLE SQL statemen inside a transaction.

We have defined a function that will create a table in the body onload event. If the table doesn't already exist, a table will be created.

The table is called todo and has 3 columns.

ID - a incrementing sequential ID column
todo - a text column that is the body of the item
added_on - the time that the todo item was created

html5rocks.webdb.createTable = function() {
var db = html5rocks.webdb.db;
db.transaction(function(tx) {
tx.executeSql("CREATE TABLE IF NOT EXISTS " +
                "todo(ID INTEGER PRIMARY KEY ASC, todo TEXT, added_on DATETIME)", []);
});
}

Step 3. Adding data to a table #

We are building a todo list manager so it is pretty important that we are able to add todo items in to the database.

A transaction is created, inside the transaction an INSERT into the todo table is performed.

executeSql takes several parameters, the SQL to execute and the parameters values to bind the query.

html5rocks.webdb.addTodo = function(todoText) {
var db = html5rocks.webdb.db;
db.transaction(function(tx){
var addedOn = new Date();
tx.executeSql("INSERT INTO todo(todo, added_on) VALUES (?,?)",
    [todoText, addedOn],
    html5rocks.webdb.onSuccess,
    html5rocks.webdb.onError);
});
}

Step 4. Selecting data from a table #

Now that the data is in the database, you need a function that gets the data back out. In Chrome, Webdatabase's use standard SQLite SELECT queries.

html5rocks.webdb.getAllTodoItems = function(renderFunc) {
var db = html5rocks.webdb.db;
db.transaction(function(tx) {
tx.executeSql("SELECT * FROM todo", [], renderFunc,
    html5rocks.webdb.onError);
});
}

Note that all of these commands used in this sample are asynchronous and as such the data is not returned from the transaction or the executeSql call. The results are passed through to the success callback.

Step 4a. Rendering data from a table #

Once the data has been fetched from the table, the loadTodoItems method will be called.

The onSuccess callback takes two parameters. The first being the transaction of the query and the second being the result set. It is fairly simple to iterate across the data:

function loadTodoItems(tx, rs) {
var rowOutput = "";
var todoItems = document.getElementById("todoItems");
for (var i=0; i < rs.rows.length; i++) {
rowOutput += renderTodo(rs.rows.item(i));
}

todoItems.innerHTML = rowOutput;
}
function renderTodo(row) {
return "<li>" + row.todo + 
        " [<a href='javascript:void(0);' onclick=\'html5rocks.webdb.deleteTodo(" + 
        row.ID +");\'>Delete</a>]</li>";
}

The effect of this method call is that the todo list is rendered into a DOM Element called "todoItems".

Step 5. Deleting data from a table #

html5rocks.webdb.deleteTodo = function(id) {
var db = html5rocks.webdb.db;
db.transaction(function(tx){
tx.executeSql("DELETE FROM todo WHERE ID=?", [id],
    html5rocks.webdb.onSuccess,
    html5rocks.webdb.onError);
});
}

Step 6. Hooking it all up #

When the page loads, open the database and create the table (if needed) and render any todo items that might already be in the database.

....
function init() {
html5rocks.webdb.open();
html5rocks.webdb.createTable();
html5rocks.webdb.getAllTodoItems(loadTodoItems);
}
</script>

<body onload="init();">

A function that takes the data out of the DOM is needed so, call the html5rocks.webdb.addTodo method

function addTodo() {
var todo = document.getElementById("todo");
html5rocks.webdb.addTodo(todo.value);
todo.value = "";
}