How the web actually works
How the web works, explained by the people who read the specification.
Web Today covers the mechanisms of the web: standards, browsers, tracking, accessibility and performance. We explain how things work rather than announcing what is new.
Why mechanisms, not launches
Most writing about the web is written to a release calendar. A vendor announces something, twenty outlets summarise the announcement, and a fortnight later nobody can tell you what actually changed on the platform. The announcement was the story, which is convenient for the company doing the announcing and close to useless for anyone trying to build, publish or simply understand what their browser is doing.
We take the opposite approach. When something changes in the platform we go and read what changed: the specification text, the browser bug, the implementation notes, the discussion in the working group. Then we explain the mechanism, because the mechanism is the part that stays true after the launch post has been quietly rewritten. A reader who understands how a thing works can evaluate the next twelve claims made about it without our help, which is the only kind of coverage worth publishing.
What we cover
Standards and how they are made: what a specification actually requires, which parts are optional, where implementations diverge, and how a proposal travels from an idea to something shipped in browsers. Browsers themselves, including the engines, their release processes, and the difference between a feature being announced and a feature being usable by a site with real visitors.
Privacy and tracking, which we treat as a technical subject as much as a policy one. What a given technique can actually observe, whether a mitigation works or merely inconveniences the least motivated trackers, and what a change to the platform does to the people being tracked rather than to the companies doing it. Accessibility, covered as engineering rather than compliance: what assistive technology does with your markup, why a pattern fails, and how to tell.
Performance, from the network up: what makes pages slow on the connections and devices most people have, rather than on a fast laptop in an office. And throughout, the consequences for the people who cannot influence any of this, ordinary users and small publishers who have to live with whatever the platform decides.
Our editorial line
We are sceptical of hype, and that scepticism is technical rather than temperamental. When a vendor says a change protects users, we ask what specifically it stops, who it stops it for, and what it does not stop. When a change is described as necessary for the web, we ask who benefits and who now needs permission from whom.
We think the web is worth defending as an open platform: viewable source, linkable documents, a low barrier to publishing, and no single party in a position to decide who gets to be on it. That commitment is a lens, not a licence to be unfair. We describe the strongest version of a position we disagree with, and we correct ourselves in public when the specification says something other than what we claimed.
We also try to be honest about uncertainty. Plenty of questions about the platform do not have a settled answer, and saying so is more useful than manufacturing a confident conclusion.
Editorial standards
We report what we have verified. Claims about behaviour are tested where they can be tested, and we say what we tested, in which browser, at which version, so a reader can reproduce it or show that we got it wrong. Where a claim rests on a document, we cite the document and quote the relevant clause rather than paraphrasing it into something more convenient for our argument.
Sources are shown. Specifications, bug trackers, commit history and working group minutes are largely public, and we link to them so readers can check our work directly. Where we have spoken to someone, we say who and in what capacity. Anonymity is granted only where a person faces genuine risk from speaking, and we say in the article why we granted it.
Allegations are not reported as findings. If a company is accused of something, that is an accusation, and we label it as one and give its status: raised by whom, before which body, decided or not. We do not name any individual on the strength of a complaint. Corporate conduct is reported at the level of the organisation and the evidence, not by identifying junior employees, and we do not speculate about the motives of named people.
Corrections are published rather than edited away. Errors are fixed in the article with a dated note at the foot saying what was wrong, and material corrections are listed on a public corrections page. Substantive changes to a piece after publication are noted with a timestamp. We would rather carry a visible record of our mistakes than a clean archive that cannot be trusted.
A few terms as we use them
The vocabulary of the platform is often used loosely in coverage. Here is what we mean.
- Specification
- The normative text defining required behaviour, as distinct from a blog post describing a feature.
- Implementation
- What a particular browser engine actually does, which may differ from the specification.
- Interoperability
- Two or more independent implementations behaving the same way for the same input.
- Progressive enhancement
- Building so the core content and function work without the optional layers, then adding them.
- Origin
- The scheme, host and port combination that most of the web's security model is built around.
Who reads this
Developers who want to know why something behaves the way it does, not just which incantation makes the warning go away. People who run small sites and keep discovering that a platform change has broken or degraded something they built. Designers and writers who would like to understand the constraints they are working inside. And technically curious readers who want to know what their browser is doing on their behalf.
We assume you can read code and follow an argument, and we do not assume you already know the subject. Terms get explained the first time they appear, and pieces link back to the earlier explanation instead of repeating it.
Independence
We take no money from a company in exchange for coverage of that company. Anything commercial is labelled, positioned so it cannot be mistaken for editorial, and never written by the person covering that area. Where a writer has an interest in something being reported on, that interest is disclosed in the piece.
We do not claim endorsement from any standards body, browser vendor or regulator, and being cited by one would not change how we cover it.
Read the specification, test the behaviour, then write the article: that is the whole method.