By the end of the lesson, you can distinguish a standard, a specification, and an implementation, you know the three important standardizing communities, and you understand why interoperability and open standards are valuable for the web.
Why do we need common rules?
If we send a university link to someone, we expect it to open on a phone, on a laptop, on another operating system, and preferably in another browser. This works not because all devices are the same, but because the participants follow common rules. The author of a page cannot know what device the visitor uses; the common rules give the certainty that the same document can be interpreted everywhere.
Standard, specification, implementation
A standard is a commonly accepted set of technical rules.
A specification is its detailed, written description.
An implementation is a concrete program (browser, server, tool) that tries to realize the specification.
A standard prescribes observable behavior, not the internal code. So Chrome, Firefox, and Safari are completely different programs, yet they must display the same document in a similar way.
flowchart TB
S[Common specification] --> B1[Browser A]
S --> B2[Browser B]
S --> W[Web server]
B1 <-->|common rules| W
B2 <-->|common rules| W
Who creates the standards?
Community
Role
Typical examples
W3C
Developing web recommendations and guidelines (founded in 1994)
accessibility guidelines, the language of style sheets
WHATWG (Web Hypertext Application Technology Working Group)
The living standards of the web platform used by browsers; founded in 2004 by representatives of Apple, Mozilla, and Opera
HTML, DOM, URL, Fetch
IETF (Internet Engineering Task Force)
Standardizing internet protocols; the output is the RFC series
HTTP, TLS
None of these communities "controls the internet" centrally. They provide open processes in which manufacturers, developers, and researchers coordinate. The IETF, for example, discusses public drafts (Internet-Drafts) in working groups, decides by "rough consensus" rather than by voting, and the final result receives an RFC number. The description of HTTP is like this too: RFC 9110 describes the HTTP semantics, 9111 the caching, and 9112 the message format of HTTP/1.1.
The WHATWG maintains living standards: the text keeps changing according to feedback and new features, and does not appear in versions. This is why HTML today is not "HTML 5" but a continuously updated document.
Interoperability
Interoperability means that different systems can work together. On the web it matters at several levels:
the same page can be used in several browsers;
a server communicates with many kinds of clients;
an API can be reached by programs written in different languages;
the user is not forced into the world of a single manufacturer.
Interoperability is not perfect: differences between browsers, uneven feature support, and inherited limitations remain (chapter 3 deals with these). Standards and public tests reduce exactly this.
Open standards and dependence
The documentation of an open standard is accessible to anyone, and in principle anyone can implement it. This supports competition and long-term accessibility. In contrast, if a solution is built exclusively on one manufacturer's own technology, vendor lock-in can develop: it is hard to switch to another provider or tool, because everything is tied to it.
This does not mean that every service that depends on one manufacturer should be avoided. It means it is worth considering consciously: what happens if the manufacturer discontinues, makes more expensive, or changes the service?
Worked example: "It only works in this browser"
Suppose the enrolment button of Kurzuspont works in only one browser, because the developers relied on a feature available there but not standardized. Some of the students cannot enrol. The cause may be a faulty implementation, a non-standard technology, or a lack of compatibility testing. For a university, public administration, or other important service this is especially serious, because it excludes some of the users.
Prevention: choosing standard solutions, trying the important functions in several browsers, and planning a fallback for the case when a capability is missing.
Common misconceptions
Statement
Clarification
"A standard prevents innovation."
A common base makes it easier for an innovation to be widely usable.
"If it works in Chrome, it works everywhere."
Browser support and bugs can differ.
"The W3C makes laws."
The W3C develops standards and recommendations; legal obligations come from other sources.
"HTML 5 is the latest version, which HTML 6 will follow."
HTML is a living standard of the WHATWG, continuously updated.
In brief
A standard is a set of rules, a specification is its description, an implementation is its realization.
The W3C, the WHATWG, and the IETF develop web standards in open processes.
Interoperability is a core value of the web, but it is not perfect.
An open standard reduces dependence; vendor lock-in increases it.
Review questions
What is the difference between a specification and an implementation?
Which community deals with the standardization of HTTP, and which with HTML?
Why is it a problem if a university service can be used in only one browser?
What is a "living standard", and how does it differ from numbered editions?
Learning resources
WHATWG FAQ — the community's self-introduction and the concept of a living standard.
Web standards and interoperability
Objectives
By the end of the lesson, you can distinguish a standard, a specification, and an implementation, you know the three important standardizing communities, and you understand why interoperability and open standards are valuable for the web.
Why do we need common rules?
If we send a university link to someone, we expect it to open on a phone, on a laptop, on another operating system, and preferably in another browser. This works not because all devices are the same, but because the participants follow common rules. The author of a page cannot know what device the visitor uses; the common rules give the certainty that the same document can be interpreted everywhere.
Standard, specification, implementation
A standard prescribes observable behavior, not the internal code. So Chrome, Firefox, and Safari are completely different programs, yet they must display the same document in a similar way.
flowchart TB S[Common specification] --> B1[Browser A] S --> B2[Browser B] S --> W[Web server] B1 <-->|common rules| W B2 <-->|common rules| WWho creates the standards?
None of these communities "controls the internet" centrally. They provide open processes in which manufacturers, developers, and researchers coordinate. The IETF, for example, discusses public drafts (Internet-Drafts) in working groups, decides by "rough consensus" rather than by voting, and the final result receives an RFC number. The description of HTTP is like this too: RFC 9110 describes the HTTP semantics, 9111 the caching, and 9112 the message format of HTTP/1.1.
The WHATWG maintains living standards: the text keeps changing according to feedback and new features, and does not appear in versions. This is why HTML today is not "HTML 5" but a continuously updated document.
Interoperability
Interoperability means that different systems can work together. On the web it matters at several levels:
Interoperability is not perfect: differences between browsers, uneven feature support, and inherited limitations remain (chapter 3 deals with these). Standards and public tests reduce exactly this.
Open standards and dependence
The documentation of an open standard is accessible to anyone, and in principle anyone can implement it. This supports competition and long-term accessibility. In contrast, if a solution is built exclusively on one manufacturer's own technology, vendor lock-in can develop: it is hard to switch to another provider or tool, because everything is tied to it.
This does not mean that every service that depends on one manufacturer should be avoided. It means it is worth considering consciously: what happens if the manufacturer discontinues, makes more expensive, or changes the service?
Worked example: "It only works in this browser"
Suppose the enrolment button of Kurzuspont works in only one browser, because the developers relied on a feature available there but not standardized. Some of the students cannot enrol. The cause may be a faulty implementation, a non-standard technology, or a lack of compatibility testing. For a university, public administration, or other important service this is especially serious, because it excludes some of the users.
Prevention: choosing standard solutions, trying the important functions in several browsers, and planning a fallback for the case when a capability is missing.
Common misconceptions
In brief
Review questions
Learning resources