HTML5 APIs

Course 3 · Ch 10

HTML5 APIs Grab-Bag

Geolocation, Notifications, and the Clipboard API — three browser-native capabilities, all permission-gated, all genuinely useful in the right context

Several browser APIs don't fit neatly into any single theme covered so far, but share one important trait: each requires explicit user permission before doing anything, since each touches something genuinely sensitive (location, push interruptions, clipboard contents).

Geolocation API

navigator.geolocation.getCurrentPosition(
  (position) => {
    console.log(position.coords.latitude, position.coords.longitude);
  },
  (error) => {
    console.error('Location denied or unavailable:', error.message);
  }
);

📍 getCurrentPosition()

One-off location request — triggers the browser's permission prompt the first time, then returns coordinates via the success callback.

🔄 watchPosition()

Continuously tracks location as it changes, calling the success callback repeatedly — for genuine live-tracking use cases, not a one-time lookup.

Geolocation requires HTTPS — yet another item on this course's growing list

Same requirement as service workers and PWA installability (Chapters 6-7) — browsers refuse geolocation access on plain HTTP (localhost excepted), since location data is genuinely sensitive. By this point in the course, the pattern should be clear: meaningful, security-sensitive browser capabilities consistently require HTTPS.

Notifications API

// Must request permission explicitly — never assume it's already granted
Notification.requestPermission().then((permission) => {
  if (permission === 'granted') {
    new Notification('New message', {
      body: 'You have a new message from Philip',
      icon: '/icon.png'
    });
  }
});

Three possible permission states: granted, denied, and default (not yet asked) — once a user explicitly denies, most browsers don't re-prompt automatically; the user has to manually re-enable it via browser settings.

Asking for notification permission immediately on page load is a near-universally disliked pattern

A permission prompt appearing before a user has done anything, with no context for why notifications would be useful, is one of the most commonly cited "annoying website behaviour" complaints — and often results in an instant, permanent denial. Requesting permission in direct response to a relevant user action (clicking "Notify me when this is back in stock") converts far better and respects the user's context.

Clipboard API

// Writing to the clipboard — must be triggered by a genuine user action (a click), not run freely
document.getElementById('copyButton').addEventListener('click', () => {
  navigator.clipboard.writeText('https://osztromok.com/linux')
    .then(() => console.log('Copied!'));
});

// Reading from the clipboard — also gated, and often needs explicit permission
navigator.clipboard.readText().then((text) => {
  console.log('Clipboard contains:', text);
});

The classic "Copy link" button pattern

A button that copies a URL or code snippet to the clipboard, with a brief "Copied!" confirmation message, is one of the most common and genuinely useful real-world applications of this API — and exactly the kind of feature a course-content site like osztromok.com could reasonably use for sharing a specific chapter's link.

Clipboard writes must originate from a genuine user gesture

Browsers block clipboard-writing calls that aren't triggered directly by a user action like a click — a script that tries to silently write to the clipboard on page load, on a timer, or in response to a non-interactive event will simply fail. This is a deliberate security restriction, preventing pages from silently overwriting whatever a user has copied without their knowledge.

The Common Thread — Permissions and Graceful Fallbacks

Every API in this chapter can fail — denied permission, unsupported browser, an insecure context. Real code should always check for support and handle the failure path explicitly, never assume success.

if ('geolocation' in navigator) {
  // safe to use
} else {
  // offer a fallback — e.g. let the user type in their location manually
}

Chapter 10 Quick Reference

Geolocation: getCurrentPosition() for a one-off lookup, watchPosition() for continuous tracking; requires HTTPS
Notifications: requestPermission() returns granted/denied/default; ask in response to a relevant user action, never on page load
Clipboard: writeText()/readText(); writes must originate from a genuine user gesture (a click), not run freely
Common pattern across all three: explicit permission required, can fail, always handle the failure path gracefully
Check for API support ('geolocation' in navigator, etc.) before relying on any of them
Next chapter: Internationalization — lang attributes, dir, character encoding edge cases