Comment by rusk
2 years ago
You’d have to get people to use it. Like any established warty system, the warts provide just enough of a moat for established practitioners to keep it just the way it is.
2 years ago
You’d have to get people to use it. Like any established warty system, the warts provide just enough of a moat for established practitioners to keep it just the way it is.
The thing is, you could use doctypes like a racket #lang to precisely opt into the new format. Same with the type attribute on style, script and link elements. I’ve always found it a bit sad that we haven’t really taken advantage of the built-in extension points of HTML and related technologies because they’re designed pretty well for breaking changes without breaking compatibility.
Still the same problem. You’ve to get people to use the extensions. You mentioned a few “back in the day” examples and nobody uses these. CSS got the push and gained critical mass initially and that’s that. There’s been plenty of improvements since of course and if you can disregard legacy platforms it all gets a lot easier but that’s where the experts you want to sway define their value.
Browsers update quickly enough now that you can adopt new features relatively aggressively for desktop sites. Wasm might even let us ship these extensions to the script and style tags through a separate distribution channel, enabling better adoption of alternate languages in the browser.
Finally, CSS itself is starting to get some more programmability via the Houdini APIs.
1 reply →
This sounds interesting - what do you mean by the "built-in extension points"?
I already listed them: doctypes, the lang/type attribute for script/style/link tags, and custom elements/attributes.
Back in the day, you could use alternate scripting languages in IE: VBScript shipped by default, but there was also the ability to install an ActiveX extension to enable Python and some others in the script tag.