Browser compatibility and progressive enhancement

Objectives

By the end of the lesson, you can say what compatibility means (and what it does not), you can explain feature detection and progressive enhancement, and you can use the Can I use? site while knowing its limitations.

Why is the page not the same everywhere?

Web standards provide a common basis (see 1.5), but browsers are separate programs from separate manufacturers, and they introduce novelties at different paces. In addition, the users' device, display, settings, and habits differ: one uses the page with enlarged text, another with a keyboard, another on a slow mobile network. If we expected exactly the same pixel-level result everywhere, it would never be fulfilled. The question is what must be ensured in every environment.

What are we comparing?

A course page can look different on a phone, on a desktop, and with enlarged text. This is not an error in itself. But if the enrolment link disappears, the button does not work, or the text becomes unreadable, the interface does not fulfil its purpose. Compatibility is therefore worth looking at on three levels.

flowchart TD
    K[Compatibility] --> T[Content is available]
    K --> M[Action is usable]
    K --> O[Page is readable]
    T --> C[Goal is reachable]
    M --> C
    O --> C

• Content: does the user get the necessary information?
• Action: can the user start and finish the task (for example also with a keyboard)?
• Appearance: is the layout readable and clear?

A beautiful page can be unusable if its main action can only be reached with a mouse.

Standards and implementations

Standard elements (link, button, form field) have built-in meaning and behavior, so there are fewer differences between browsers. If an arbitrary box element and a lot of custom JavaScript imitate the same thing, every detail (keyboard, focus, role) must be solved separately. A page that opened in your own browser therefore does not prove general compatibility.

Progressive enhancement and the fallback path

Progressive enhancement starts from a usable base and extends it layer by layer:

1. Base: the content in HTML, in a readable structure.
2. Appearance: CSS for clarity.
3. Convenience: JavaScript for fast filtering and immediate feedback.

If a layer is missing, the base remains. This does not apply equally to every application: a full browser-based image editor is built on a different basic operation than an information page.

Feature detection means that when the code runs, the program checks whether the necessary capability is available, and chooses a solution accordingly:

if ("IntersectionObserver" in window) {
  // advanced solution
} else {
  // simpler fallback
}

Checking the name of the browser (user agent sniffing) is fragile: the name does not tell what a specific version supports. The existence of the capability must be checked, and if it is missing, a fallback solution or understandable feedback is needed.

Can I use?: a quick check of support

Can I use? collects support tables by browser version for web technologies, with a color code (supported, not supported, partial, unknown), and its data is openly available. We can look up IndexedDB, for example, and see in which browsers the support is full or partial.

What to watch for:

• At partial support and at the notes it is worth stopping: even a green mark does not prove that the feature actually works well on a given device.
• The percentage usage data refers to a measurement group, not necessarily to your own users.
• The site is a design starting point, not a test of your own application. The important paths must be tried in the target browsers.

How do we check?

The check should start from the user task: can the page be opened? Is the essential information readable? Are the controls reachable with a keyboard? Can the basic action be completed on a narrow display and in another browser? Compatibility is not a one-time stamp: as the content and the interface change, new errors can appear. It is worth recording which environments and paths matter for the purpose of the page.

Worked example: the filter in Kurzuspont

The course list of Kurzuspont has a filter that uses a new browser capability to load further items while scrolling.

Layer	What does it do?	If the capability is missing
HTML	The whole list is readable with links	This is always there
CSS	A clear card layout	A simpler but readable list
JavaScript	Gradual loading after feature detection	The whole list loads at once

This way the path leading to enrolment remains in every environment, and the convenience feature appears only where it works.

Common misconceptions

Statement	Clarification
"It is compatible if it looks exactly the same everywhere."	Basic usability is more important than pixel-level identity.
"If it works for me, it works everywhere."	One browser and setting is just one test environment.
"Standardization rules out all differences."	Support and bugs can differ.
"It is enough to check the name of the browser."	The actual presence of the needed capability must be checked.
"A green mark on Can I use? means the feature works well for everyone."	It informs, but does not replace trying it out.

In brief

• Compatibility can be understood at the level of content, operation, and appearance; it does not mean pixel identity.
• Progressive enhancement protects the base: HTML, then CSS, then JavaScript.
• Feature detection is more reliable than the name of the browser.
• Can I use? is a good starting point, but the important paths must be tried.

Review questions

1. Why is it not an error if the page looks different on a phone?
2. What is the difference between feature detection and checking the name of the browser?
3. What layers make up progressive enhancement?
4. What does Can I use? not tell you about a given feature?

Learning resources

• Can I use... — browser support tables.
• Critical rendering path (MDN) — why it matters what arrives and when.