First an important clarification: The robustness principle only applies to ambiguities in a protocol specification.

It is sometimes confused with flexibility in acceptable input - for example JavaScript having optional semicolons. But JavaScript semicolon insertion is specified in detail in the ECMAScript standard. Whether is is good language design is a separate question, but there is no ambiguity in the specification and therefore no place for the robustness principle.

The principle does not allow you to go against a specification. For example a JavaScript parser is not allowed to accept common misspellings of keywords. The spec is unambiguous about spelling of keywords, so that would just be invalid.

This lead to the conclusion: Having a detailed spec which covers all eventualities is always the most robust solution. If you are designing a protocol, you should take care to avoid ambiguities in the specification.

HTML initially did not specify how to process invalid HTML which lead to a number of incompatibilities. But in HTML5 the processing of invalid HTML is also specified so this eliminates the need for the the robustness principle.

When you are designing a library or API you decide on the interface yourself, so the principle is not relevant. It is only relevant when integrating with component you have no control over.

But in the very specific case where you are implementing a protocol with ambiguities in the specification, I will argue the robustness principle is common sense. Just don't apply the principle outside of this context.

The robustness principle only applies when implementing an ambiguous specification.

For example, imagine a protocol specification which states:

A request payload starts with the word GET in uppercase or lowercase.

This would be ambiguous - GET and get is clearly both allowed but it is not absolutely clear if e.g. Get or gEt is allowed. So following Postels Law, you accept all case combinations in input, but you make sure to only emit either GET or get. This ensures the highest chance of interoperability if other implementors have interpreted the ambiguous parts differently.

But ideally, a protocol specification should be completely unambiguous. The real HTTP spec states for example:

By convention, standardized methods are defined in all-uppercase
US-ASCII letters. [...] When a request method is received that is unrecognized or not implemented by an origin server, the origin server SHOULD respond with the 501 (Not Implemented) status code.

So this makes it clear that only GET is recognized and Get or get should result in an error code. An implementation that accepted Get would not be "robust" or "liberal", it would be non-compliant and broken.

Silently ignoring invalid input is fine if the spec explicitly allows it. For example, TCP is allowed to silently drop packages because the protocol is designed to handle unreliable connections anyway. But silently ignoring a malformed HTTP request is not allowed by the HTTP spec.

The Robustness Principle is sometimes confused with flexibility in acceptable input - for example JavaScript having optional semicolons. But JavaScript semicolon insertion is specified in detail in the ECMAScript standard. Whether it is good language design is a separate question, but there is no ambiguity in the specification and therefore no need to apply the robustness principle in the implementation.

Unspecified behavior in C should not be confused with Postels Law either. The C spec is not ambiguous, rather it gives very specific parameters for what freedom an implementation has.

HTML and CSS are notorious for differences and incompatibilities across implementations. But Postels Law is not to blame for this. The problems are due to:

1. Bugs, mistakes and omissions in implementations.
2. Ambiguities or lack of detail in the standards

For example, the infamous "quirks mode" was due to bugs in the browser rendering engine. Most significantly IE mistakenly included padding and border in the calculation of width in the box model. Arguably, the spec was ambiguous, but the choice did not have anything to do with Postels Law since neither formula is more "liberal" or "strict" than the other.

Having a detailed spec which covers all eventualities is always the most robust solution. If you are designing a protocol, you should take care to avoid ambiguities in the specification.

When you are designing a library or API you decide on the interface yourself, so the principle is not relevant. It is only relevant when integrating with component you have no control over.

But in the very specific case where you are implementing a protocol with ambiguities in the specification, I will argue the robustness principle is common sense. Just don't apply the principle outside of this context.

First an important clarification: The robustness principle only applies to ambiguities in a protocol specification.

It is sometimes confused which having flexibility in acceptable input - for example JavaScript having optional semicolons. But JavaScript semicolon insertion is specified in detail in the ECMAScript standard. Whether is is good language design is a separate question, but there is no ambiguity in the specification and therefore no place for the robustness principle.

The principle does not allow you to go against a specification. For example a JavaScript parser is not allowed to accept common misspellings of keywords. The spec is unambiguous about spelling of keywords, so that would just be invalid.

This lead to the conclusion: Having a detailed spec which covers all eventualities is always the most robust solution. If you are designing a protocol, you should take care to avoid ambiguities in the specification.

HTML initially did not specify how to process invalid HTML which lead to a number of incompatibilities. But in HTML5 the processing of invalid HTML is also specified so this eliminates the need for the the robustness principle.

When you are designing a library or API you decide on the interface yourself, so the principle is not relevant. It is only relevant when integrating with component you have no control over.

But in the very specific case where you are implementing a protocol with ambiguities in the specification, I will argue the robustness principle is common sense. Just don't apply the principle outside of this context.

First an important clarification: The robustness principle only applies to ambiguities in a protocol specification.

It is sometimes confused with flexibility in acceptable input - for example JavaScript having optional semicolons. But JavaScript semicolon insertion is specified in detail in the ECMAScript standard. Whether is is good language design is a separate question, but there is no ambiguity in the specification and therefore no place for the robustness principle.

The principle does not allow you to go against a specification. For example a JavaScript parser is not allowed to accept common misspellings of keywords. The spec is unambiguous about spelling of keywords, so that would just be invalid.

This lead to the conclusion: Having a detailed spec which covers all eventualities is always the most robust solution. If you are designing a protocol, you should take care to avoid ambiguities in the specification.

HTML initially did not specify how to process invalid HTML which lead to a number of incompatibilities. But in HTML5 the processing of invalid HTML is also specified so this eliminates the need for the the robustness principle.

When you are designing a library or API you decide on the interface yourself, so the principle is not relevant. It is only relevant when integrating with component you have no control over.

But in the very specific case where you are implementing a protocol with ambiguities in the specification, I will argue the robustness principle is common sense. Just don't apply the principle outside of this context.