Whoever the idiot was who came up with piling inline CSS and JS into the already heavy SGML syntax of HTML should've considered his career choices. It would've be perfectly adequate to require script and CSS to be put into external "resources" linked via src/href, especially since the spec proposals operated under the assumption there would be multiple script and styling languages going forward (like, hey, if we have one markup and styling language, why not have two or multiple?). When in fact the rules were quite simple: in SGML, text rendered to the reader goes into content, everything else, including formatting properties, goes into atttibutes. The reason for introducing this inlining misfeature was probably the desire to avoid network roundtrip, which would've later been made bogusly obsolete by Google's withdrawn HTTP/2 push spec, but also the bizarre idea anyone except webdev bloggers would be editing HTML+CSS by hand. To think there was a committee overviewing such blunders as "W3C recommendations" - actually, they screwed up again with CSS when they allowed unencoded inline data URLs such as used for SVG backgrounds and the like. The alarm bells should've been ringing at the latest the moment they seriously considered storing markup within CSS like with the abovementioned misfeature but also with the "content:" CSS property. You know, as in "recommendation" which is how W3C final stage specs were called.
All of those are features, not bugs and I'm glad they are there. Uploading and dealing with 1 file is much nicer than dealing with several.
> much nicer than dealing with several.
"My momentary convenience trumps the man-millenia of effort required to protect billions of people from script injection attacks."
Not just his convenience. Man-millenia of convenience, if you will ;) I too love the fact that many things can be single index.html's, no need of a zip file then. It's double-click to view. One of the best things about the web platform.
Edit: and "effort", please. The spec has a simple and clear note:
> The easiest and safest way to avoid the rather strange restrictions described in this section is to always escape an ASCII case-insensitive match for "<!--" as "\x3C!--", "<script" as "\x3Cscript", and "</script" as "\x3C/script" when these sequences appear in literals in scripts (e.g. in strings, regular expressions, or comments), and to avoid writing code that uses such constructs in expressions. Doing so avoids the pitfalls that the restrictions in this section are prone to triggering.
Backwards compatibility is easily and completely worth this small amount of effort. It's a one-liner in most languages.
The easiest and safest way to avoid the rather strange restrictions described is to not make use of inline script in a way that makes those restrictions neccessary, though. And a "recommendation" should reflect that (from back when HTML recommendations were actually published rather than random Google shills writing whatever on github). The suggested workaround is also not without criticism (eg [1]).
[1]: https://uploadcare.com/blog/vulnerability-in-html-design/
> It would've be perfectly adequate to require script and CSS to be put into external "resources" linked via src/href
Bullshit - Navigator and IE didn't have HTTP/2. I'm guessing you didn't use dialup where your external CSS or JavaScript regularly failed to load. You didn't add extra dependencies because IE would only had two concurrent connections to load files.
It's easy to criticize past mistakes from your armchair: but I suggest you try and be a little more fair towards the people that made decisions especially when overall HTML has been a resounding success.
I suggest you try and check what the people you're accusing of armchair attitudes in fact were and are doing to solve problems.
Have you done even a single thing in the markup community?
Sorry - I shouldn't be so flippant.
Engineers hate bad compromises, and the core of engineering is making good compromises. Creating anything makes you your own critic.
Time makes a fool of everyone.