alt Hacker NewsWhy can't HTML alone do includes?
Comments
I would guess back in the days having extra requests was expensive, thus discouraged. Later there were attempts via xinclude, but by then PHP and similar took over or people tolerated frames.
I desperately want to back to crafting sites by hand and not reach for react/vue as a default. I do a lot of static and tempory sites that do very little
Like MHTML/MHT/MIME HTML files? Browsers could load *.mht files that included everything. IE, Firefox, Chrome all used to support it.
just on point at all why includ this stuff to load more at once... the hole web stuff works since cgi implementations at web services on asyncronity to load just what u actually need... like now most of them are fetch or xhr calls... I mean it makes just sence for onepager to keep the markup a bit more structured... but why u want to make static rendered homepages those days?
at all ...why includ this stuff to load more at once... the hole web stuff works since cgi implementations at web services on asyncronity to load just what u actually need... like now most of them are fetch or xhr calls... I mean it makes just sence for onepager to keep the markup a bit more structured... but why u want to make static rendered homepages those days?
Now you can include HTML in HTML, see https://include.franzai.com/ - a quick Chrome Polyfill based on the discussion here. MIT License
Github: https://github.com/franzenzenhofer/html-include-polyfill-ext...
Do remote entity references still work in XHTML? XML had its issues but did have a decent toolbox of powerful if not insecure primitives.
We know why HTML alone can't do includes! In https://github.com/whatwg/html/issues/2791 the standards committee discussed this. The issue has been open for years.
The first naysayer was @dominic: https://github.com/whatwg/html/issues/2791#issuecomment-3113...
> I don't think we should do this. The user experience is much better if such inclusion is done server-side ahead of time, instead of at runtime. Otherwise, you can emulate it with JavaScript, if you value developer convenience more than user experience.
The "user experience" problem he's describing is a performance problem, adding an extra round-trip to the server to fetch the included HTML. If you request "/blog/article.html", and the article includes "/blog/header.html", you'll have to do another request to the server to fetch the header.
It would also prevent streaming parsing and rendering, where the browser can parse and render HTML bit-by-bit as it streams in from the server.
Before you say, "so, what's the big deal with adding another round trip and breaking the streaming parser?" go ahead and read through the hundreds of comments on that thread. "What's the big deal" has not convinced browser devs for at least eight years, so, pick another argument.
I think there is a narrow opening, where some noble volunteer would spec out a streaming document-fragment parser.
It would involve a lot of complicated technical specification detail. I know a thing or two about browser implementation and specification writing, and designing a streaming document-fragment parser is far, far beyond my ken.
But, if you care about this, that's where you'd start. Good luck!
P.S. There is another option available to you: it is kinda possible to do client-side includes using a service worker. A service worker is a client-side proxy server that the browser will talk to when requesting documents; the service worker can fetch document fragments and merge them together (even streaming fragments!) with just a bit of JS.
But that option kinda sucks as a developer experience, because the service worker doesn't work the first time a user visits your site, so you'd have to implement server-side includes and also serve up document fragments, just for second-time visitors who already have the header cached.
Still, if all you want is to return a fast cached header while the body of your page loads, service workers are a fantastic solution to that problem.
For HTML-in-HTML natively I use iframes and still remember how to use Frames & framesets.
The simplest answer is that HTML wasn't designed as a presentation language, but a hypertext document language. CSS and Javascripts were add-ons after the fact. Images weren't even in the first version. Once usage of the web grew beyond the initial vision, solutions like server-side includes and server-side languages that rendered HTML were sufficient.
Honest answer: because any serious efforts to improve HTML died 20 years ago, and the web as it's envisaged today is not an infinite library of the worlds knowledge but instead a JavaScript based and platform.
Asking for things that the W3C had specced out in 2006 for XML tech is just not reasonable if it doesn't facilitate clicks.
When I read all the arguments against, I think: “Perfect is the enemy of good.”
HTML does have frames and iframes, which can accomplish some of the same goals.
the web platform is the tech stack version of the human concept of "failing upward". It sucks but will only get more and more vital in the modern tech scene as time goes by.
This has always worked for me. Pretty much the ask? https://gist.github.com/sreekotay/08f9dfcd7553abb8f1bb17375d...
Because how would the browser decide it's in a fetch loop?
This seems to be forgetting the need to render other site's content. That's the main reason for iframes to be used, as people need to render ads, email previews, games, and so forth, without potentially breaking the rest of the page.
The "extremely awkward" aspect they complain about is a side effect of needing to handle that case.
You could add some nicer way to include content for the same domain, but I suspect having two highly similar HTML features would be fairly awkward in practice, as you'd have to create a whole new set of security rules for it.
Seems like this would help with caching, too.
we had no problem using <object> for headers and footers
in the meantime, you can use <html-include> https://www.npmjs.com/package/html-include-element
just use react or nextjs or whatever and move on jeez
I think this is a genuinely good question that I was also wondering some time ago.
And it is a genuinely good question!
I think the answer of PD says feels the truest.
JS/CSS with all its bureaucracy are nothing compared to HTML it seems. Maybe people don't find nothing wrong with Html, maybe if they do, they just reach out for js/css and try to fix html (ahem frontend frameworks).
That being said, I have just regurgitated what PD says has said and I give him full credit of that but I am also genuinely confused as to why I have heard that JS / CSS are bureaucratic (I remember that there was this fireship video of types being added in JS and I think I had watched it atleast 1 year ago (can be wrong) but I haven't heard anything for it and I see a lot of JS proposals just stuck from my observation
And yet HTML is such level of bureaucratic that the answer to why HTML doesn't have a feature is because of its bureaucracy. Maybe someone can explain the history of it and why?
iFrames have a src and includes other html.. We used to make sites with it way back.
iframe is html
[dead]
FTA
> We’ve got <iframe>, which technically is a pure HTML solution, but
And then on the following paragraph..
> But none of the solutions is HTML
> None of these are a straightforward HTML tag
Not sure what the point is. Maybe just complaining
I guess for the similar reason that Markdown does not have any "include" ability -- it is a feature not useful enough yet with too many issues to deal with. They are really intended to be used as "single" documents.
You could start with something like this:
customElements.define('html-import', class extends HTMLElement {
connectedCallback() {
const href = this.getAttribute('href')
const fetch = new XMLHttpRequest()
fetch.responseType = 'document'
fetch.addEventListener('readystatechange', (function onfetch(e) {
if (fetch.readyState !== XMLHttpRequest.DONE) return
const document = fetch.response.querySelector('body') ?? fetch.response
this.replaceWith(document)
}).bind(this))
fetch.open('GET', href)
fetch.send()
}
})
Chris is an absolute legend in this space and I’m so glad he’s bringing this up. I feel like he might actually have pull here and start good discussions that might have actual solutions.