91–100 of 367 posts
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.res…
This was the rabbit hole that I started down in the late 90s and still haven’t come out of. I was the webmaster of the Analog Science Fiction website and I was building tons of static pages, each with the same header and side bar. It drove me nuts. So I did some research and found out about Apache server side includes. Woo hoo! Keeping it DRY (before I knew DRY was a thing). Yeah, we’ve been solving this over and ove…
HTML is a markup language, not a programming language. It's like asking why Markdown can't handle includes. Some Markdown editors support them (just like some server-side tools do for HTML), but not all.
I'm not defending it, because when I started web development this was one of the first problems I ran into as well -- how the heck do you include a common header.
But the original concept of HTML was standalone documents, not websites with reusable components like headers and footers and navbars.
That being said, I still don't understand why then the frames monstrosity was invented, rather than a basic include. To save on bandwidth or something?
If I really need HTML includes for some reason, I'd reach for XSLT. I know its old, and barely maintained at best, but that was the layer intentionally added to add programming language features to the markup language that is HTML.
"Includes" functionality is considered to be server-side, i.e. handled outside of the web browser. HTML is client-side, and really just a markup syntax, not a programming language. As the article says, the problem is a solved one. The "includes" issue is how every web design student learns about PHP. In most CMSes, "includes" become "template partials" and are one of the first things explained in the documentation. T…
This argument applies just as much to CSS and JS. Why do they include "includes" when you can just bundle on the server?
> We’ve got , which technically is a pure HTML solution, but they are bad for overall performance, accessibility, and generally extremely awkward here What does this mean? This is a pure HTML solution, not just "technically" but in reality. (And before iframe there were frames and frameset). Just because the author doesn't like them don't make them non-existent.
The real problem with iframes is that their size is set by the parent document only. They would be a lot more useful if we could write e.g. so the height of the iframe element is set by the abc.html document instead of the parent document.
This was the rabbit hole that I started down in the late 90s and still haven’t come out of. I was the webmaster of the Analog Science Fiction website and I was building tons of static pages, each with the same header and side bar. It drove me nuts. So I did some research and found out about Apache server side includes. Woo hoo! Keeping it DRY (before I knew DRY was a thing). Yeah, we’ve been solving this over and ove…
HTML is a markup language, not a programming language. It's like asking why Markdown can't handle includes. Some Markdown editors support them (just like some server-side tools do for HTML), but not all.
https://docs.asciidoctor.org/asciidoc/latest/directives/incl...
Earlier quoted context omitted.
HTML is a markup language, not a programming language. It's like asking why Markdown can't handle includes. Some Markdown editors support them (just like some server-side tools do for HTML), but not all.
That’s the Hyper part of HTML, and what makes it special. It’s made to pull in external resources (as opposed to other document formats like PDF). Scripts, stylesheets, images, objects, favicons, etc. HTML is thematically similar.
Earlier quoted context omitted.
Iframe is stuck in a rectangular box. It's not really suitable for things like site wide headers, footers and menus.
While I get your point, headers and footers and menus tend to all live within rectangular boxes.
I'm not an expert on this but IMO, from a language point of view, HTML is a markup language, it 'must' have no logic or processing. It is there to structure the information not to dynamically change it. Nor even to display it nicely. The logic is performed elsewhere. If you were to have includes directly in HTML, it means that browsers must implement logic for HTML. So it is not 'just' a parser anymore. Imagine for e…
Earlier quoted context omitted.
HTML is a markup language, not a programming language. It's like asking why Markdown can't handle includes. Some Markdown editors support them (just like some server-side tools do for HTML), but not all.
Well, asciidoc - a markup language supports includes, so the "markup languages" analogy doesn't hold. https://docs.asciidoctor.org/asciidoc/latest/directives/incl...