[dathinab]

> progressive enhancement possible

no not at all extensible isn't the same as lenient

having a Content-Type header where you can put in new media types (e.g. for images) once browsers support it is extensibility

sniffing the media type instead of strictly relying on the Content-Type header is leniency and had been the source of a lot of security vulnerabilities over the years

or having new top level JS object exposing new APIs is extensibility but allowing overriding the prototypes of fundamental JS objects (i.e. Array.prototype) turned out to be a terrible idea associated with multiple security issues (like idk. ~10 years ago, hence why it now is read only)

same for SAML, its use of XML made it extensible, but they way it leniently encoded XML for signing happened to be a security nightmare

or OAuth2 which is very extensible, but it being too lenient in what you can combine how was the source of many early security incidents and is still source of incompatibilities today (but OAuth2 is anyway a mess)

[wvenable]

> no not at all extensible isn't the same as lenient

I never said it was. But lenient provides for extensibility that isn't planned for. The entire evolution of the web is based on that. Standards that were too strict or too inflexible have been long forgotten by history.

That's not to say that isn't the source of security vulnerabilities and bugs but that doesn't negate the point.

[dathinab]

that is just not true

web is mostly based on standards which always have been supper lenient, messy und had massive gaps of unclearity mainly because it was more "lets somehow standarize what browsers already do" then anything else

through I guess you could say that the degree to which you can polyfill JS is more lenient then many thing is good and that did help with extensibility,

[wvenable]

You say that's not true but then you don't contradict what I'm saying. How were browsers able to do anything, while maintaining backwards compatibility, that needed standardizing later?