New principle: Consider many & diverse use cases to avoid overfitting

We should have a principle that encourages API designers to put effort in unearthing and considering as many and as diverse use cases as possible, to avoid designing their proposed solution around very specific use cases, which would make it harder or impossible to use for the broader user need.

Perhaps we should also add a requirement to the explainer that they list at least 3 separate use cases? I see a lot of reviews listing just one use case, which is a red flag for overfitting.

This has come up in several reviews:

Perhaps we could also combine it with something advising against introducing new primitives with slightly different functionality than existing primitives, which increases the number of concepts authors need to learn. Instead, extending the existing primitives should be explored before designing new ones. Designing new primitives is typically a good idea when the existing primitives involve too many concepts that don’t transfer well to the new functionality or the existing functionality involves too many concepts that don’t transfer well to the new primitive.

A good example for that is masonry layout, where people are currently trying to decide whether it should be part of grid or a new display type. I think a framework around what the overlap of concepts between grid and masonry is (how many grid concepts transfer to masonry? how many grid concepts do not apply to masonry? how many masonry concepts do not apply to grid?) could be helpful there.

w3ctag / design-principles

New principle: Consider many & diverse use cases to avoid overfitting #450