HTML5 platform APIs
When a brief says HTML5 it usually means capability, not markup. Play this video, work without a signal, draw this chart, know where the user is. This page is about what the browser can already do, and where it stops.
01Overview
Where the word came from, and what it means now
HTML5 stopped being a version in 2011, when HTML became a living standard. The name survived as shorthand for the browser platform that arrived with it: audio and video without a plugin, canvas, local storage, service workers and offline, geolocation, web workers. Markup and semantics are a different subject, on HTML; styling is CSS.
02Capabilities
Three capabilities buyers name out loud
The three that arrive by name in a brief, each with a specific place it gets expensive. In every one of them the API is the easy half.
- Media
Video and audio in the browser
Playback, streaming surfaces, and camera or microphone capture behind a permission prompt. The tag is trivial; the work is codecs, adaptive streaming, autoplay policy and what the player does on a bad connection.
- Offline
Working where the signal drops
Service workers, local databases and background sync for tools used away from a desk, like the field and driver apps in logistics and transportation. That is web development with an offline data model, and the hard part is what happens when two devices edited the same record.
- Canvas
Drawing more than the page can hold
Charts, diagrams, maps and data at a volume that would stall an ordinary page. Canvas buys throughput and costs you everything a screen reader or a crawler could have read, so we pair it with a text view of the same data. See HTML.
03Fit
Can it already do this, or do you need an app?
The browser is far more capable than most briefs assume, and it has hard edges in specific places. Each row below names what that capability calls for, from the browser alone to a native app, with a link where another page covers it.
| What you want to do | What that actually calls for |
|---|---|
| Play video reliably, from a desk down to an old Android phone | The browser handles itBudget for codecs, adaptive streaming and autoplay rules, and test on real devices rather than on your laptop. The tag is the trivial part. |
| A tool for people working where the signal drops | An installable web appA site that installs and keeps working offline is a real answer, provided the data can survive conflicting edits. Design the merge rules before the screens. |
| Bluetooth peripherals, background location, or NFC on a phone | Different pageBuild a native app. Browser support is uneven and permission behaviour differs per platform. See iOS and Android. |
| An interactive view of a very large dataset | Canvas, plus a text versionAnything drawn on a canvas is invisible to a screen reader and to a crawler, so it owes the same data in markup. See HTML. |
| Keep meaningful user data on the device | Record on the serverTreat storage in the browser as a cache. Space limits exist, the browser can clear it, and nothing follows a user to their second device unless you built that. |
| Push notifications and reliable background work | Check before promisingSupport differs by platform and by how the app was installed. This is the most common reason a web-first plan turns into a mobile app halfway through. |
| "We need an app" | Decide it explicitlySometimes a good mobile web experience is what you need, and sometimes it genuinely is not. Make that call on iOS and Android before anyone picks a framework. |
Scope
What we own when we use these APIs is the fallback: what happens when permission is refused, when storage is full, and when a device does not have the API at all. Checking what each device supports, and deciding what the user sees when it does not, is the deliverable rather than the happy path. unicrew has been shipping browser software since 2012, with 100+ senior in-house engineers across six countries. Our information security is certified to ISO 27001:2022. These APIs are driven from JavaScript, and where the whole front end needs an owner, that is front-end development.
04Case studies
A build that ended up on both sides of that line
One published build where the same question came up. A building-security software company already had a web client, and needed real apps on top of it.
See all case studies
05Stack
What the capability layer sits with
The four neighbours of the capability layer, each with a page of its own.
06Questions
What people ask before they promise a feature
These come up in the week before somebody commits a capability to a roadmap, which is the right week to ask them.
As a version decision, nothing: HTML is a living standard, so there is nothing to pick. In practice the two words now describe different subjects. HTML is markup and semantics, which decides accessibility and what machines can read. HTML5, the way clients use the word, means the platform APIs on this page: media, canvas, storage, offline, geolocation. If your question is about what the browser can do, you are in the right place.
Sometimes, and the deciding factor is hardware access rather than interface quality. Forms, lists, media and offline caching all work well in a browser. Bluetooth peripherals, reliable background location, deep operating-system integration and store presence do not, or not everywhere. We make that call in week one, so nobody discovers it in month four. The decision sits on iOS and Android; the build itself is mobile app development.
SVG when the elements are individually meaningful and countable: an icon, a labelled diagram, a chart with a few hundred points. Each shape is a real element, so it can be styled, made accessible and clicked. Canvas when volume is the problem, because thousands of SVG nodes will stall the browser. The trade is that a canvas is one opaque element, so anything that matters to a reader owes a second representation.
Yes, with a service worker and a local database, and the hard part is not the caching. It is deciding what happens when two people edited the same record on two devices with no connection, and what the user is shown while the app is not sure. We settle those rules before building screens, because retrofitting them means changing the data model, which means changing everything above it.
Three shapes, and which fits depends on how settled the scope is. Time and materials is billed hourly and quoted per project, which suits work still moving. Fixed price is outcome based, and we only offer it once the first read is done, because a fixed number on a capability nobody has prototyped is a guess with a contract around it. Team extension is billed monthly per engineer.
Trying to work out whether it is a browser job?
Describe the capability and the devices your users have. You will get a straight answer on whether this is a browser job or a native one. We will also say where web development or mobile app development would pick it up.