5 ms·

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.mozill

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>.

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>.