The capabilities and limits of the browser
Objectives
By the end of the lesson, you can list the most important programmable capabilities of the browser (files, local storage, drawing, media), explain why access is "mediated", and ask three separate questions for every capability: is it available, is it permitted, did it succeed.
Why is it important to know the limits of the browser too?
The browser does not only display HTML: a web application can draw, process a file, store data locally, play media, and request certain device functions. At the same time, a web page is a foreign, untrusted program: it cannot get unlimited access to the user's machine. The browser therefore mediates access: it allows something only through defined interfaces (APIs), under defined conditions. Whoever knows this knows what they can build on and what they cannot.
A browser API is not the same as a web API offered by a server (chapter 5). Here we mean the programmable interfaces that the browser provides to the web page: for example reading a file object or the drawing surface.
A browser-based editor uses several kinds of capabilities
A student selects an image file from their machine in a browser-based diagram editor, modifies it, and wants to continue the work later. This needs file reading, drawing, and local storage, and the three different APIs have different conditions.
flowchart LR
U[User] -->|selects a file| F[File API]
F --> A[Web application]
A --> C[Canvas 2D or WebGL]
A --> I[IndexedDB: local data]
A --> E[Export or upload]
The diagram shows a possible structure. Reading the selected file, the project stored in the browser's own storage, and uploading to the server are three separate operations: none of them automatically implies the other.
Local files: selecting and reading
The File API lets the page read a local file selected by the user. The selection can happen with an <input type="file"> element or by dragging and dropping, as MDN describes it. The selected file is available as a File object. Selection does not mean automatic upload: the page can decide to work with it only locally. A web page cannot read the user's files at will.
<label for="source">Choose an image</label>
<input id="source" type="file" accept="image/*">
This HTML only provides the selection interface; processing the file needs program code. Some browsers also offer further file-system interfaces, but their support differs, so it is not worth making a simple upload depend on them.
Local data storage
In the browser's own storage the page can keep data for the next visit. There are three important tools:
| Tool |
What is it good for? |
Characteristics |
localStorage |
Small, simple key–value data |
According to MDN about 5 MiB per origin; throws an error when exceeded |
sessionStorage |
Data tied to the session of the given browser tab |
Short-lived |
| IndexedDB |
A larger, structured data set, with transactions |
The amount is managed by the browser |
The diagram editor can, for example, put the elements of an unfinished piece of work into IndexedDB. The storage is tied to the origin. The origin is the combination of the scheme, the host, and the port (we discuss it in detail in chapter 8), so another page of a foreign origin cannot read the project. (A cookie is not meant to be client-side storage: it goes to the server with every request. More on this in chapter 7.)
Local storage is not a reliable backup:
- The space is limited. The browser calculates the quota from the disk size; in Chrome and Edge this can be up to 60% of the disk, in Firefox 10% of the disk (at most 10 GiB), but these values vary by browser and version.
- If the storage becomes full, writing fails with a
QuotaExceededError.
- The browser can empty the storage: under storage pressure it deletes the data of the least recently used origin, and moreover all the data of the origin at once. With tracking protection enabled, Safari also cleans the origin the user has not interacted with during 7 days of browser use: it deletes the data created by its scripts.
- It does not appear automatically on another device.
So exporting the important work or synchronizing it to a server must be planned separately.
flowchart TD
A[Web application] --> F[File chosen by the user]
A --> D[IndexedDB: local data of the application]
A --> S[Server: separate data exchange]
F -. not the same storage .- D
D -. no automatic synchronization .- S
Drawing: Canvas 2D and WebGL
Canvas 2D is used for images drawn by a program, simple animations, and diagrams. WebGL also works within a canvas element, but relies on graphics hardware, for interactive 2D and 3D display (WebGL: Web Graphics Library). For a static diagram, semantic HTML or a simple chart is often enough; for rotating a spatial model, WebGL is more justified.
Besides WebGL support, the actual graphics capability of the device matters too: the program must check whether it managed to get a graphics context, and must provide a simpler view or a text description as a fallback. Drawn pixels alone do not convey the meaning of the drawn objects to assistive technologies; if the graphic carries information, an accessible alternative is needed (chapter 9).
The media elements of HTML provide an interface for playing audio and video. Other APIs offer location, camera and microphone use, or the display of notifications. For these the browser usually asks the user for explicit permission. It is important that the purpose of the function is clear, and that the application stays meaningful even after refusal. A course page, for example, does not need the exact geographic location; if it offers a map function, the address should also be available as text.
| Goal |
Possible capability |
If it is not available |
| Opening an image |
File chooser and File API |
A clear error message or another input method |
| Continuing the work later |
IndexedDB |
Export or server-side saving as a separate decision |
| Spatial diagram |
WebGL |
A simpler image or a text description |
| Audio or video |
Media element |
The essential information is available in another form too |
| Location-based result |
Geolocation API |
Manual entry of location |
Three separate questions for every capability
- Is the API available in the given browser and environment? (feature detection, see 3.5)
- Are the conditions of use met? (user action, permission)
- Did the operation succeed? (creating the graphics context can fail, measuring the location can fail, the storage can fill up)
The existence of a capability is not in itself a reason to use it. The user's goal, the data handling, and the alternative path together determine whether a browser feature is a good choice.
Worked example: the "My notes" function of Kurzuspont
Kurzuspont lets a student write a note on a course. The developers first save the note to IndexedDB, so it is not lost if the student accidentally closes the tab.
| Question |
Answer |
| Is IndexedDB available? |
They check it with feature detection. |
| Are the conditions met? |
In private browsing mode the quota can differ; the program handles the error. |
| Did the save succeed? |
If the storage is full, the program signals the error. |
| Is local saving enough? |
No: the note must be saved to the server too, because the browser can empty the storage, and it does not appear on another device. |
Common misconceptions
| Statement |
Clarification |
| "A page can read any local file." |
It only has access to the file the user selected. |
| "Selecting a file is an automatic upload." |
The page can process it locally; uploading is a separate operation. |
| "IndexedDB is a visible project file." |
It is the application's database stored in the browser, tied to the origin. |
| "Local saving is a sure backup." |
The storage is limited and erasable, and does not appear on another device. |
| "WebGL is guaranteed to work on every device." |
The availability of the graphics context must be checked. |
| "The existence of an API means certain success." |
The conditions and the result of the operation are separate questions. |
In brief
- The browser gives mediated, limited access to the device through APIs.
- The file is chosen by the user; local storage (localStorage, IndexedDB) is tied to the origin and can be erased.
- Drawing (Canvas, WebGL) and media may need a fallback path and an alternative.
- For every capability three questions must be asked: is it available, is it permitted, did it succeed.
- Local storage does not replace saving on the server.
Review questions
- What is the difference between reading a selected file and uploading it?
- Why does IndexedDB not replace saving on the server?
- What is the difference between a browser API and a web API offered by a server?
- What three questions should you ask before using a new browser capability?
Learning resources
The capabilities and limits of the browser
Objectives
By the end of the lesson, you can list the most important programmable capabilities of the browser (files, local storage, drawing, media), explain why access is "mediated", and ask three separate questions for every capability: is it available, is it permitted, did it succeed.
Why is it important to know the limits of the browser too?
The browser does not only display HTML: a web application can draw, process a file, store data locally, play media, and request certain device functions. At the same time, a web page is a foreign, untrusted program: it cannot get unlimited access to the user's machine. The browser therefore mediates access: it allows something only through defined interfaces (APIs), under defined conditions. Whoever knows this knows what they can build on and what they cannot.
A browser API is not the same as a web API offered by a server (chapter 5). Here we mean the programmable interfaces that the browser provides to the web page: for example reading a file object or the drawing surface.
A browser-based editor uses several kinds of capabilities
A student selects an image file from their machine in a browser-based diagram editor, modifies it, and wants to continue the work later. This needs file reading, drawing, and local storage, and the three different APIs have different conditions.
flowchart LR U[User] -->|selects a file| F[File API] F --> A[Web application] A --> C[Canvas 2D or WebGL] A --> I[IndexedDB: local data] A --> E[Export or upload]The diagram shows a possible structure. Reading the selected file, the project stored in the browser's own storage, and uploading to the server are three separate operations: none of them automatically implies the other.
Local files: selecting and reading
The File API lets the page read a local file selected by the user. The selection can happen with an
<input type="file">element or by dragging and dropping, as MDN describes it. The selected file is available as aFileobject. Selection does not mean automatic upload: the page can decide to work with it only locally. A web page cannot read the user's files at will.<label for="source">Choose an image</label> <input id="source" type="file" accept="image/*">This HTML only provides the selection interface; processing the file needs program code. Some browsers also offer further file-system interfaces, but their support differs, so it is not worth making a simple upload depend on them.
Local data storage
In the browser's own storage the page can keep data for the next visit. There are three important tools:
localStoragesessionStorageThe diagram editor can, for example, put the elements of an unfinished piece of work into IndexedDB. The storage is tied to the origin. The origin is the combination of the scheme, the host, and the port (we discuss it in detail in chapter 8), so another page of a foreign origin cannot read the project. (A cookie is not meant to be client-side storage: it goes to the server with every request. More on this in chapter 7.)
Local storage is not a reliable backup:
QuotaExceededError.So exporting the important work or synchronizing it to a server must be planned separately.
flowchart TD A[Web application] --> F[File chosen by the user] A --> D[IndexedDB: local data of the application] A --> S[Server: separate data exchange] F -. not the same storage .- D D -. no automatic synchronization .- SDrawing: Canvas 2D and WebGL
Canvas 2D is used for images drawn by a program, simple animations, and diagrams. WebGL also works within a
canvaselement, but relies on graphics hardware, for interactive 2D and 3D display (WebGL: Web Graphics Library). For a static diagram, semantic HTML or a simple chart is often enough; for rotating a spatial model, WebGL is more justified.Besides WebGL support, the actual graphics capability of the device matters too: the program must check whether it managed to get a graphics context, and must provide a simpler view or a text description as a fallback. Drawn pixels alone do not convey the meaning of the drawn objects to assistive technologies; if the graphic carries information, an accessible alternative is needed (chapter 9).
Media, location, and notifications
The media elements of HTML provide an interface for playing audio and video. Other APIs offer location, camera and microphone use, or the display of notifications. For these the browser usually asks the user for explicit permission. It is important that the purpose of the function is clear, and that the application stays meaningful even after refusal. A course page, for example, does not need the exact geographic location; if it offers a map function, the address should also be available as text.
Three separate questions for every capability
The existence of a capability is not in itself a reason to use it. The user's goal, the data handling, and the alternative path together determine whether a browser feature is a good choice.
Worked example: the "My notes" function of Kurzuspont
Kurzuspont lets a student write a note on a course. The developers first save the note to IndexedDB, so it is not lost if the student accidentally closes the tab.
Common misconceptions
In brief
Review questions
Learning resources