4 ms·

Yes, it's awful that HTML is now dependent on js... how did we let that happen?? I'm thinking mostly of HTML5 web components, which, unless I missed something,

Yes, it's awful that HTML is now dependent on js... how did we let that happen?? I'm thinking mostly of HTML5 web components, which, unless I missed something, are completely useless without js. All I wanted was a way for HTML to import other HTML. This seems to be the central issue that we've been hacking around for decades with SSI, template languages, and js. It's so basic -- everybody wants a header and a footer and maybe a menu on each page. Should be an HTML feature.

teaearlgraycold 3y ago
iframes?
- otabdeveloper4 3y ago
  Yes, except without the frame. (Restrict cross-origin requests if you worry about security.)
- bilekas 3y ago
  Are iframes still fully supported across all browsers though?
gochi 3y ago
You're basically suggesting implementing JS within HTML, which htmx exists on a technicality, but not sure that's something we should be pushing at all. We're just spreading JS problems to HTML which is a perfectly fine language.
- bobthepanda 3y ago
  Also, JSX is pretty much literally this. But yes, HTML was clearly designed for producing output markup; but in reality the people who want to generate markup want to handle nested data, if/else, and loops, because that is better than copy pasting a bunch of markup everywhere and occasionally fat-fingering something.
- johnmw 3y ago
  I'm not sure I follow? I think the GP was just talking about the ability to import other HTML fragments without JS? Something like: <fragment href="site-menu.html"/> Which would load my shared site wide menu html into the parent div. I'm not sure why JS would be needed here? (i.e in the same way html <select> elements are interactive without needing "JS"). Going a little more out there, what about cross domain imports for easy web component consumption? <fragment href="https://weather-widget.org?location=london" /> I can't see how this would be less secure than current cross domain JS imports? It used to be sorta possible with HTML Imports but that spec got dropped [1]. [1] https://www.w3.org/TR/html-imports/ https://www.w3.org/TR/html-imports/
  - mrpf1ster 3y ago
    Is this not just an iframe?
    - wruza 3y ago
      Iframes are opaque for css, form fields and for js in some sense.
slmjkdbtl 3y ago
You can just make a function that generates HTML string like h("div", { class: "container" }, [ h("p", {}, "oh hi!"), ...projects.map(renderProject), ]) the end result will have no JS if all you want is reuse HTML parts, much better than template languages imo (no additional syntax, has loops / functions / variables out of the box)
rado 3y ago
Declarative web components with Shadow DOM are now supported everywhere and require no JS.
- spankalee 3y ago
  That's not true. Declarative shadow DOM is supported in Safari, Chrome, and Edge, but that is not the same as declarative custom elements, which don't have a spec yet.
- foobarbecue 3y ago
  Fantastic. Thanks for telling me about this.
spankalee 3y ago
Web components are custom HTML elements, which typically combine state behavior and state-based rendering. How do you expect to do that without JS, at least without porting a non-trivial subset of a JS-like programming language into HTML?
lenkite 3y ago
Once upon a time we had HTML Imports which were lovely. But it made browser vendors nervous since folks could do stuff without Javascript. And what would then happen to all their tracking ? So, they unanimously purged the feature. <link rel="import" href="/partials/browser-vendors-hate-this.html" />
- youngtaff 3y ago
  The problem with imports is they were render blocking Don’t need JS to do tracking, and browsers can track without needs any marketing tags at all
  - lenkite 3y ago
    Not a big deal. There are already render blocking resources today. Could be ameliorated with an async attribute if needed. Obviously browsers that directly track users will lead a stinking public cloud and litigation. Vendors prefer their customers do the tracking for them. And make the ecosystem unable to function without tracking.
lyjackal 3y ago
For what it’s worth, Astro is a static site generator that only relies on JavaScript at build time, and has optional integration with the usual js frameworks. In many ways that’s what it does solve (just importing html)

teaearlgraycold 3y ago

iframes?

otabdeveloper4 3y ago
Yes, except without the frame. (Restrict cross-origin requests if you worry about security.)
bilekas 3y ago
Are iframes still fully supported across all browsers though?

gochi 3y ago

You're basically suggesting implementing JS within HTML, which htmx exists on a technicality, but not sure that's something we should be pushing at all. We're just spreading JS problems to HTML which is a perfectly fine language.

bobthepanda 3y ago
Also, JSX is pretty much literally this. But yes, HTML was clearly designed for producing output markup; but in reality the people who want to generate markup want to handle nested data, if/else, and loops, because that is better than copy pasting a bunch of markup everywhere and occasionally fat-fingering something.
johnmw 3y ago
I'm not sure I follow? I think the GP was just talking about the ability to import other HTML fragments without JS? Something like: <fragment href="site-menu.html"/> Which would load my shared site wide menu html into the parent div. I'm not sure why JS would be needed here? (i.e in the same way html <select> elements are interactive without needing "JS"). Going a little more out there, what about cross domain imports for easy web component consumption? <fragment href="https://weather-widget.org?location=london" /> I can't see how this would be less secure than current cross domain JS imports? It used to be sorta possible with HTML Imports but that spec got dropped [1]. [1] https://www.w3.org/TR/html-imports/ https://www.w3.org/TR/html-imports/
- mrpf1ster 3y ago
  Is this not just an iframe?
  - wruza 3y ago
    Iframes are opaque for css, form fields and for js in some sense.

slmjkdbtl 3y ago

You can just make a function that generates HTML string like h("div", { class: "container" }, [ h("p", {}, "oh hi!"), ...projects.map(renderProject), ]) the end result will have no JS if all you want is reuse HTML parts, much better than template languages imo (no additional syntax, has loops / functions / variables out of the box)

rado 3y ago

Declarative web components with Shadow DOM are now supported everywhere and require no JS.

spankalee 3y ago
That's not true. Declarative shadow DOM is supported in Safari, Chrome, and Edge, but that is not the same as declarative custom elements, which don't have a spec yet.
foobarbecue 3y ago
Fantastic. Thanks for telling me about this.

spankalee 3y ago

Web components are custom HTML elements, which typically combine state behavior and state-based rendering. How do you expect to do that without JS, at least without porting a non-trivial subset of a JS-like programming language into HTML?

lenkite 3y ago

Once upon a time we had HTML Imports which were lovely. But it made browser vendors nervous since folks could do stuff without Javascript. And what would then happen to all their tracking ? So, they unanimously purged the feature. <link rel="import" href="/partials/browser-vendors-hate-this.html" />

youngtaff 3y ago
The problem with imports is they were render blocking Don’t need JS to do tracking, and browsers can track without needs any marketing tags at all
- lenkite 3y ago
  Not a big deal. There are already render blocking resources today. Could be ameliorated with an async attribute if needed. Obviously browsers that directly track users will lead a stinking public cloud and litigation. Vendors prefer their customers do the tracking for them. And make the ecosystem unable to function without tracking.

lyjackal 3y ago

For what it’s worth, Astro is a static site generator that only relies on JavaScript at build time, and has optional integration with the usual js frameworks. In many ways that’s what it does solve (just importing html)