5 ms·

HTML being lenient is what made progressive enhancement possible -- right down the original <img> tag. The web would not have existed at all if HTML was strict

HTML being lenient is what made progressive enhancement possible -- right down the original <img> tag. The web would not have existed at all if HTML was strict right from the start.

arccy 1y ago
That's poor reasoning. The web now counts as strict but still extensible: you just have to clearly define how to handle unknown input. The web treats all unknowns as a div.
- wvenable 1y ago
  > you just have to clearly define how to handle unknown input. That is being lenient. Allowing any unknown input is being lenient in what you accept. Not allowing unknown input at all is being strict.
dathinab 1y ago
> 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 1y ago
  > 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 1y ago
    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 1y ago
      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?

HTML being lenient is what made progressive enhancement possible -- right down the original <img> tag. The web would not have existed at all if HTML was strict right from the start.

arccy 1y ago

That's poor reasoning. The web now counts as strict but still extensible: you just have to clearly define how to handle unknown input. The web treats all unknowns as a div.

wvenable 1y ago
> you just have to clearly define how to handle unknown input. That is being lenient. Allowing any unknown input is being lenient in what you accept. Not allowing unknown input at all is being strict.

dathinab 1y ago

> 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 1y ago
> 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 1y ago
  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 1y ago
    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?