2 ms·

> how can we find a way to permit the "good" uses of Javascript while prohibiting all of the "bad"? I always thought HTML could've been gradually extended wit

> how can we find a way to permit the "good" uses of Javascript while prohibiting all of the "bad"? I always thought HTML could've been gradually extended with new elements for capturing and replacing UI techniques which Javascript is essential for, but that hasn't happened. Instead, HTML is stuck with what was envisioned in 2008 or earlier (coming from a hierarchical document structure for casual academic publishing), and everything else in the browser (CSS, Javascript) evolved to work around it. Today, we have CSS with it's absurd ninja powers to completely change and reinterpret the HTML DOM with a secondary document structure in the name of "semantic" HTML, locked to a 1990's idea of how a generic document should look like. It seems the evolution of HTML as a markup language suffered from being organizationally fossilized, after W3C ventured into an unrealistic XHTML2 moonshot, thus giving HTML language extensions a bad name, and the proponents of CSS believing their own "separation of concerns" story after the fact when it just started out as a hack to overcome HTML's limitations (it being in the hands of W3C and W3C focussing on a ten-year roll to replace HTML with XHTML and other XML vocabularies). HTML/SGML always had all the power you could want to define new vocabulary, even ways to define new elements in terms of fragments/combinations of existing ones for vocabulary evolution. To be fair, though, during most of the web's existence, a visual language had to evolve as there simply was no blueprint available for how we'd use hypertext on a massive scale, especially with mobile devices. Unfortunately, the mechanisms HTML5 today has for vocabulary evolution (ie. custom elements and maybe template elements and web components) all require tons of Javascript as well. FWIW, there's GNU's LibreJS initiative to block all but F/OSS or "trivial" JavaScript, but I don't believe it has had any impact (and it focuses solely on the licensing aspect).

spankalee 6y ago
One way web components can evolve to help this is with declarative custom elements, a feature many of the people who've worked on web components have wanted to pursue. The idea is that you could define a custom element, with style and DOM encapsulation, purely in markup with either no script at all, or script only for progressive enhancement. There are still a few features that need to be finalized and proposed, like Template Instantiation [1] to allow for expressions in HTML. When put together it would look something like this: <custom-element name="x-summary" attributes="href"> <template> <style> ::slotted(h1) { color: blue; } </style> <article> <a href="{{ href }}"><slot name="title"</a> <slot></slot> </article> </template> </custom-element> Which you can then use like: <x-summary href="http://..."> <h1 slot="title">Hello</h1> <p>This article is about...</p> </x-summary> Combine this with HTML modules[2] so you can import these definitions and you could build reusable widgets without script, and some UAs could evolve their script settings to allow HTML modules but not JavaScript modules for a more locked down experience. From there I'd hope we could find a way to use worklets to allow components to use script, but limit them to only the component's shadow DOM, not the global DOM, and not have default access to APIs like XHR and fetch, or other APIs used for fingerprinting. [1]: https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md https://github.com/w3c/webcomponents/blob/gh-pages/proposals... [2]: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/HTMLModules/explainer.md https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/maste...

spankalee 6y ago

One way web components can evolve to help this is with declarative custom elements, a feature many of the people who've worked on web components have wanted to pursue. The idea is that you could define a custom element, with style and DOM encapsulation, purely in markup with either no script at all, or script only for progressive enhancement. There are still a few features that need to be finalized and proposed, like Template Instantiation [1] to allow for expressions in HTML. When put together it would look something like this: <custom-element name="x-summary" attributes="href"> <template> <style> ::slotted(h1) { color: blue; } </style> <article> <a href="{{ href }}"><slot name="title"</a> <slot></slot> </article> </template> </custom-element> Which you can then use like: <x-summary href="http://..."> <h1 slot="title">Hello</h1> <p>This article is about...</p> </x-summary> Combine this with HTML modules[2] so you can import these definitions and you could build reusable widgets without script, and some UAs could evolve their script settings to allow HTML modules but not JavaScript modules for a more locked down experience. From there I'd hope we could find a way to use worklets to allow components to use script, but limit them to only the component's shadow DOM, not the global DOM, and not have default access to APIs like XHR and fetch, or other APIs used for fingerprinting. [1]: https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md https://github.com/w3c/webcomponents/blob/gh-pages/proposals... [2]: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/HTMLModules/explainer.md https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/maste...