The Open Web
The open web is built on the premise that interoperable standards, implemented by multiple independent browsers, create a platform no single company controls. In practice, the degree to which this holds varies enormously. HTML rendering is largely interoperable. CSS layout is mostly consistent. But step into web application manifests, input element localisation, DNS-based service discovery, or the metadata formats that determine how shared links appear — and the implementation differences become significant, sometimes in ways that affect whether features work at all.
This topic page connects content from across the site that addresses the open web from the perspective of someone building on it — observing where standards work as intended, where implementations diverge, and where the gap between specification and reality creates practical problems. The scope covers both the visible layer (how browsers render content, handle input, present web applications) and the underlying protocols that determine how content is discovered and integrated across platforms.
Browser behaviour and rendering
Browsers are the runtime environment for the open web, and their implementation decisions determine what developers can actually rely on. The specifications describe intended behaviour. The browsers deliver actual behaviour. The distance between the two is where the interesting observations live.
GNOME Web App Icons
Web application manifests define how an installed web app should appear — name, icons, theme colours, display mode. The specification is straightforward; the implementation is not. GNOME Web (Epiphany) handles manifest icons differently from Chromium and Firefox, creating situations where a valid manifest produces correct results on some platforms and missing icons on others.
This page documents the specific icon handling in GNOME Web: which manifest fields are respected, which icon sizes are preferred, the fallback behaviour, and the practical differences from other browsers. For anyone deploying installable web applications across Linux desktops alongside Windows and macOS, understanding these differences is essential.
HTML5 Input Number Localisation
The HTML5 <input type="number"> element is one of those features where internationalisation creates problems most developers only discover through bug reports from specific locales. The core issue is decimal separators: many European locales use a comma where English-speaking locales use a period. The interaction between browser locale detection, input validation, and JavaScript value APIs produces behaviour that varies by browser, OS locale, and sometimes keyboard layout.
This page documents the localisation behaviours observed, the validation edge cases that cause silent form submission failures, and practical approaches for multi-locale numeric input. The problem is not a bug in any single browser — each is defensible in isolation. The inconsistency combined with silent failures creates a user experience problem visible only through cross-browser, cross-locale testing.
Platform APIs and integration
The open web extends beyond the browser tab into system-level integration through web APIs, manifest files, and protocol handlers that determine how web content interacts with the operating system and other applications. These integration points are where the web platform's ambition to be a first-class application platform meets the reality of operating system diversity.
GNOME Apps and the Web API
GNOME's web application integration exposes assumptions about how the manifest specification maps onto a Linux desktop. The translation from web manifest to desktop application entry involves decisions about icon handling, window management, and application identity not fully specified by the standards.
This technical note documents how GNOME handles web app installation, the desktop integration points affected, and where behaviour differs from specification expectations. The observations apply to anyone building web apps for Linux desktop installation and to the broader question of how well the web application model translates across OS paradigms.
Trackerless Magnets Extension
Browser extensions operate at the boundary between the open web and the browser platform. This development case study documents an extension that intercepts and processes magnet URIs — a protocol scheme outside HTTP/HTTPS that browsers encounter regularly through web page links.
The architecture illustrates several open-web themes: how browsers handle non-HTTP URI schemes, how content scripts interact with page content, and how WebExtensions API compatibility plays out when multiple vendors implement independently. The development notes capture specific Chrome/Firefox divergences that affect real-world functionality.
DNS and protocol-level standards
The open web depends on DNS and transport-level protocols that operate beneath the HTTP layer but fundamentally shape how content is discovered, routed, and connected. Standards at this level tend to be stable and well-specified, but adoption and implementation vary considerably — some DNS record types that have been standardised for decades remain poorly supported by the services and tools that would benefit from them.
DNS SRV Record Usage
DNS SRV records provide a standardised service discovery mechanism — looking up not just a domain's IP address, but the specific host, port, and priority for a service. The specification has been available since 1996 and certain protocols (XMPP, SIP, LDAP) rely on it heavily. But adoption beyond those protocols has been slow, with many services still relying on hardcoded ports or proprietary discovery.
This technical note examines current SRV usage — which services actually use it, where the promise of generic service discovery has stalled, and the practical implications for deploying discoverable services. DNS SRV represents a recurring pattern in the web standards landscape: a well-designed, long-standardised feature that remains underutilised.
What readers usually need
Readers arriving at this topic page typically have one of these questions:
- Web app icons not appearing correctly on Linux desktops → GNOME Web App Icons documents the manifest handling differences in GNOME Web
- Number inputs behaving differently across locales → HTML5 Input Number Localisation covers the decimal separator problem and cross-browser validation behaviour
- How GNOME integrates web applications → GNOME Apps and the Web API examines the desktop integration behaviour and its divergence from specification expectations
- Building a cross-browser extension → Trackerless Magnets Extension provides a practical development case study covering API compatibility across browsers
- How DNS SRV records are actually used → DNS SRV Record Usage assesses adoption patterns and the gap between specification and practice
Navigating related content
This topic page is one of several cross-section hubs on the site. The topics index provides the full list of available topic clusters. If you are looking for content organised by editorial type rather than by subject, the section hubs are:
- Web Development for server and front-end implementation notes
- Tech Notes for behavioural observations and protocol documentation
- Development for scripting, tooling, and extension work
- Security for investigations and protocol analysis
- How-To Guides for practical walkthroughs and configuration guides
- Reviews for product and service assessments
- Journal for reflective commentary
The open web as a theme is broad enough to touch nearly every section on the site. The pages linked from this topic hub are the ones where web standards, browser behaviour, or platform interoperability is the central subject. As new content is published that examines how the web platform behaves in practice — rendering differences, API inconsistencies, protocol adoption patterns — it will appear here alongside the existing coverage.