5 ms·

It is insane that HTML has no "include". None of all this would be needed if we could just do: <include src="myComponent.html>

by TekMol 7y ago

woodrowbarlow 7y ago
it was proposed and implemented, then the standards body did an about-face. https://hacks.mozilla.org/2015/06/the-state-of-web-components/ https://hacks.mozilla.org/2015/06/the-state-of-web-component... (ctrl+f "HTML Imports") "HTML Imports do lend themselves well to a simpler/more declarative workflow. [...] Imports don’t offer enough control to be taken seriously as a dependency management solution. [...] Mozilla had a working implementation behind a flag, but struggled through an incomplete specification." which to me reads a bit like: "js frameworks won't use it, and the spec didn't get enough love because everybody's only thinking about frameworks rather than vanilla-js."
- tomphoolery 7y ago
  Actually, they are waiting for module Imports to standardize and get some actual real-world usage. Once that happens, they may move onto HTML Imports. But I feel like they could probably get away with just doing `import Template from "./somefile.html"` using module resolvers.
- chrisfinazzo 7y ago
  Sigh. A web that was built on documents fragments because the JS and server-side developers think writing raw HTML and CSS is gross. Email developers would like a word with them. This isn't going away, and at some point, adding more abstractions is actually harmful. As I have little else to do at this point - Tl;dr When you work for a public library, but are closed the public, nothing happens - I'm rewriting a small microsite I made for job hunting purposes. Other than a Service Worker cache, it's markup and styles all the way down, stitched together with Make. For my blog, I've stuck with Liquid, because Jekyll - which I actually like (ducks) - will be interesting to see if this gets revived and actually lands one day.
  - woodrowbarlow 7y ago
    would you mind sharing the source or stack for your microsite? your setup sounds like something i'd enjoy using.
    - chrisfinazzo 7y ago
      Code is here - https://github.com/chrisfinazzo/reverse-job-posting https://github.com/chrisfinazzo/reverse-job-posting Started on GH Pages, but moved to Netlify which gives me a bit more fine grained control. Pardon the dust; First, I'm not a graphic designer and second this is actually an older deploy that I've "locked" so I can continue tinkering with the master branch behind the scenes. Will be a single page with just anchors to navigate when done. Everything old is new again. Homepages, kids, ask your parents about them :)
  - the_other 7y ago
    _This_ front end developer _loves_ writing HTML and CSS, regardless of my previous several years of JS, React, Angular, Backbone etc.
- goatlover 7y ago
  It's disappointing that JS Frameworks are driving the HTML spec.
- chrisweekly 7y ago
  I vaguely recall doing things with server-side includes and ".shtml" in the late '90s...
  - getpost 7y ago
    I still have a website that uses server-side includes fro the navbar and other common page elements. https://en.wikipedia.org/wiki/Server_Side_Includes https://en.wikipedia.org/wiki/Server_Side_Includes
- spankalee 7y ago
  HTML Imports was not an <include> mechanism though. It was much more akin to JS imports. HTML files would be side-effectful, then you could use the elements they defined, like <x-foo>.
101404 7y ago
That was the original web components. Much better. Then they changed it to make it worse. :(
- tasogare 7y ago
  Yeah I remember reading about web components, getting excited and building a prototype. Then when I worked again on the project shadow DOM API changed and HTML imports were removed :| At this point I highly suspects the people behind the Web shit-show (spec writers and implementors) keep things bad on purpose as a way to get job security.
AtlasBarfed 7y ago
Then why not a templating language with looping constructs until it is Turing complete? Because base HTML is a document not a document generation language. Um, until javascript. Oh well. Thus JS library references basically enable HTML includes.
- woodrowbarlow 7y ago
  a document that supports embedding other documents is still just a document.
  - e12e 7y ago
    Ah, but a document that supports including itself, that's the bomb!
tannhaeuser 7y ago
That, and much more, is implemented in SGML on which HTML is based.
pcr910303 7y ago
That wouldn't be a solution to everything, but at least it would be a starting point to defining a fully-declarative custom element solution so that custom elements can be used in a non-JS context.
stevekemp 7y ago
Back in the day we had something which was often used:
dfabulich 7y ago
There's a web component for that! https://github.com/justinfagnani/html-include-element https://github.com/justinfagnani/html-include-element <script type="module" src='https://unpkg.com/html-include-element'></script> <html-include src="./my-local-file.html"></html-include>

It is insane that HTML has no "include". None of all this would be needed if we could just do: <include src="myComponent.html>

by TekMol 7y ago

It is insane that HTML has no "include". None of all this would be needed if we could just do: <include src="myComponent.html>

woodrowbarlow 7y ago

it was proposed and implemented, then the standards body did an about-face. https://hacks.mozilla.org/2015/06/the-state-of-web-components/ https://hacks.mozilla.org/2015/06/the-state-of-web-component... (ctrl+f "HTML Imports") "HTML Imports do lend themselves well to a simpler/more declarative workflow. [...] Imports don’t offer enough control to be taken seriously as a dependency management solution. [...] Mozilla had a working implementation behind a flag, but struggled through an incomplete specification." which to me reads a bit like: "js frameworks won't use it, and the spec didn't get enough love because everybody's only thinking about frameworks rather than vanilla-js."

tomphoolery 7y ago
Actually, they are waiting for module Imports to standardize and get some actual real-world usage. Once that happens, they may move onto HTML Imports. But I feel like they could probably get away with just doing `import Template from "./somefile.html"` using module resolvers.
chrisfinazzo 7y ago
Sigh. A web that was built on documents fragments because the JS and server-side developers think writing raw HTML and CSS is gross. Email developers would like a word with them. This isn't going away, and at some point, adding more abstractions is actually harmful. As I have little else to do at this point - Tl;dr When you work for a public library, but are closed the public, nothing happens - I'm rewriting a small microsite I made for job hunting purposes. Other than a Service Worker cache, it's markup and styles all the way down, stitched together with Make. For my blog, I've stuck with Liquid, because Jekyll - which I actually like (ducks) - will be interesting to see if this gets revived and actually lands one day.
- woodrowbarlow 7y ago
  would you mind sharing the source or stack for your microsite? your setup sounds like something i'd enjoy using.
  - chrisfinazzo 7y ago
    Code is here - https://github.com/chrisfinazzo/reverse-job-posting https://github.com/chrisfinazzo/reverse-job-posting Started on GH Pages, but moved to Netlify which gives me a bit more fine grained control. Pardon the dust; First, I'm not a graphic designer and second this is actually an older deploy that I've "locked" so I can continue tinkering with the master branch behind the scenes. Will be a single page with just anchors to navigate when done. Everything old is new again. Homepages, kids, ask your parents about them :)
- the_other 7y ago
  _This_ front end developer _loves_ writing HTML and CSS, regardless of my previous several years of JS, React, Angular, Backbone etc.
goatlover 7y ago
It's disappointing that JS Frameworks are driving the HTML spec.
chrisweekly 7y ago
I vaguely recall doing things with server-side includes and ".shtml" in the late '90s...
- getpost 7y ago
  I still have a website that uses server-side includes fro the navbar and other common page elements. https://en.wikipedia.org/wiki/Server_Side_Includes https://en.wikipedia.org/wiki/Server_Side_Includes
spankalee 7y ago
HTML Imports was not an <include> mechanism though. It was much more akin to JS imports. HTML files would be side-effectful, then you could use the elements they defined, like <x-foo>.

101404 7y ago

That was the original web components. Much better. Then they changed it to make it worse. :(

tasogare 7y ago
Yeah I remember reading about web components, getting excited and building a prototype. Then when I worked again on the project shadow DOM API changed and HTML imports were removed :| At this point I highly suspects the people behind the Web shit-show (spec writers and implementors) keep things bad on purpose as a way to get job security.

AtlasBarfed 7y ago

Then why not a templating language with looping constructs until it is Turing complete? Because base HTML is a document not a document generation language. Um, until javascript. Oh well. Thus JS library references basically enable HTML includes.

woodrowbarlow 7y ago
a document that supports embedding other documents is still just a document.
- e12e 7y ago
  Ah, but a document that supports including itself, that's the bomb!

tannhaeuser 7y ago

That, and much more, is implemented in SGML on which HTML is based.

pcr910303 7y ago

That wouldn't be a solution to everything, but at least it would be a starting point to defining a fully-declarative custom element solution so that custom elements can be used in a non-JS context.

stevekemp 7y ago

Back in the day we had something which was often used:

dfabulich 7y ago

There's a web component for that! https://github.com/justinfagnani/html-include-element https://github.com/justinfagnani/html-include-element <script type="module" src='https://unpkg.com/html-include-element'></script> <html-include src="./my-local-file.html"></html-include>