Oh, you overstate it. You could always do that stuff in DSL's in languages like LISP while maintaining the power. That would've been helpful to prevent what HTML and CSS's lack of expressiveness resulted in: a whole mess of tech for client, server, and transport to make up for what they couldn't do. Languages like Curl or Opa were both more powerful and more understandable than that collective mess.
Hence, why we want powerful and versatile languages with optional reductions via DSL's.
Writing and using a DSL in LISP seems to be the definition of reducing your power in a case you find it useful. I'm not sure what nuance you're drawing.
Changing requirements and the browsers wars made the web a mess, not this design decision. If the web is a set of linked documents available for public consumption, do we really need to encrypt it? I would say yes (because information about STD treatment may be public, but your interest isn't), but it would be understandable to leave it in clear-text. But what about a worldwide commerce platform? Oops, we'd better layer on TLS.
"If the web is a set of linked documents available for public consumption, do we really need to encrypt it? I would say yes (because information about STD treatment may be public, but your interest isn't), but it would be understandable to leave it in clear-text. But what about a worldwide commerce platform? Oops, we'd better layer on TLS."
That's a tangent topic I'm not really focusing on. I'm talking about the presentation, efficient transport/updating, storage, and so on of content & data accessed via the web. Aka web sites and web applications. I'm saying Turing complete HTML doesn't cut it by far which is supported by the fact that hardly anyone uses it: server-side includes and Javascript at a minimum going back to 90's. Leading to...
"Writing and using a DSL in LISP seems to be the definition of reducing your power in a case you find it useful. I'm not sure what nuance you're drawing."
It reduces power for that DSL specifically. This gives us the advantages of reduced power. However, every other requirement can then leverage either DSL's or the powerful language to solve them. Or, like Opa, one can just use a powerful language with good attention to safety. In any case, you get a language that solves your current problem, solves your [likely] next problem, solves them well, is efficient, is compatible with HTML or whatever, and is consistent across the stack.
Sounds better than the hodge-podge of crap that mainstream, web apps are made off. The mess certainly wasn't created by HTML's design but HTML's & its partners aren't suited to dealing with the mess most effectively. Right tool for the job, ya know.
Hence, why we want powerful and versatile languages with optional reductions via DSL's.