Browsers Situationship: When Browsers Agree but the Spec Doesn’t

What actually happens when the specification says one thing, but Chrome, Firefox, and Safari are all doing something else? You would think the answer is obvious. The specification is the specification, so the browsers are wrong and the browsers should be fixed. Except that is not always what happens. Sometimes we change the specification instead.That sounds strange if you think of a specification as an algorithm or a set of rules written first, with browsers as implementations that come later. But the history of the Web is not quite that simple. Specifications and browser implementations have influenced each other from the beginning, and that relationship is still very much alive today.So, what came first: browsers or specifications?One might think it is a chicken-and-egg question. But it is not. The historically correct answer is a little less dramatic: they grew together.In 1989, Tim Berners-Lee proposed what would become the World Wide Web. By the end of 1990, he had written the first web server and the first browser/editor, called WorldWideWeb. Around the same time, he was also developing the early versions of HTML, HTTP, and URIs.So there was never really a clear moment when someone finished a giant specification for the Web and then browser engineers went and implemented it. There was an idea, there was an implementation, and there were descriptions of how that system was supposed to work. All of those things evolved together.The W3C's history of the Web describes Berners-Lee's early specifications for URI, HTTP, and HTML as being refined and discussed in larger circles as the Web spread. That last part is very important: as the Web spread.One implementation talking to itself is relatively easy. Multiple independent implementations trying to understand and reproduce the same behaviour is where standards start becoming necessary.As more browsers appeared and more people started building websites, the Web needed common agreements. If every browser had a completely different understanding of HTML, developers could not rely on the same page behaving consistently everywhere. A Web where every implementation invents its own rules stops being much of a Web. Imagine the user experience here!In October 1994, Berners-Lee founded the World Wide Web Consortium, W3C, to coordinate the development of Web standards. A year later, in November 1995, HTML 2.0 was published as RFC 1866 through the Internet Engineering Task Force, or IETF. HTML standardization was still moving between different venues at this point; W3C would take the lead on later versions of HTML.One part of that RFC is particularly interesting in this context. It describes HTML 2.0 as bringing together, clarifying, and formalizing features that were already in common use. In other words, the Web already existed, browsers were already implementing HTML, and the specification was helping describe and stabilize something people were already using.That is quite different from thinking of standards as commandments delivered before implementations exist.Why specifications matterI do not want this to sound like specifications are just suggestions that browsers can ignore whenever they feel like it. They are not.Specifications are one of the reasons the Web works at all.A shared specification gives independent browser engines a common target. Blink, Gecko, WebKit, Servo, or any other browser engine can have completely different architectures internally, but they still need to agree on what happens when a website gives them the same input.That agreement is what allows us to build one website instead of maintaining website-for-chrome.com, website-for-firefox.com, and website-for-safari.com.Of course, there have been periods in Web history when browser-specific behaviour made this much harder. The browser wars are full of examples of browsers shipping their own features and developers having to deal with incompatible implementations. Standardization made the Web much more predictable by creating a common language that different implementations could target.Modern browser development also has shared test suites such as Web Platform Tests, or WPT. WPT contains tests for Web-platform behaviour that can be run across multiple browsers. That gives browser engineers and specification authors something more concrete than specification prose alone: they can test whether independent implementations actually agree.In an ideal world, the relationship is simple. A specification describes a behaviour, browsers implement that behaviour, shared tests verify it, and everybody agrees.Unfortunately, we are software engineers.Then reality happensSpecifications are written by humans. Browsers are written by humans. Websites are definitely written by humans. The future might belong to AI, but let's stick to humans for now because I am a human and I am still fixing bugs in browsers!All three have bugs.A specification can contain a mistake. A sentence can be ambiguous. An algorithm can describe behaviour that turns out to be impractical. Two browser engines can interpret the same wording differently. A browser can accidentally ship a bug. Websites can then start depending on that bug.And once enough websites depend on something, the question of what is "correct" becomes surprisingly complicated.Imagine that the specification says X, while Chrome, Firefox, and Safari all implement Y.At first glance, this looks easy. Chrome has a bug, Firefox has a bug, Safari has a bug. Fix all three browsers and make them implement X.But what if browsers have behaved as Y for years? What if existing websites rely on that behaviour without even knowing that they rely on it?