Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why can't HTML alone do includes?

frontendmasters.com

Post reply on HN
Print view View original

331–340 of 367 posts

Re: Why can't HTML alone do includes?

#331

Post by mildred593 »

safety1st wrote: post #268
echelon wrote: post #217

Earlier quoted context omitted.

It's too bad we didn't go down the XHTML/semantic web route twenty years ago. Strict documents, reusable types, microformats, etc. would have put search into the hands of the masses rather than kept it in Google's unique domain. The web would have been more composible and P2P. We'd have been able to slurp first class article content, comments, contact details, factual information, addresses, etc., and built a wealth…

I'm as big a critic of Google as anyone, but I'm always surprised at modern day takes around the lost semantic web technologies - they are missing facts or jumping to conclusions in hindsight. Here's what people should know. 1) The failure of XHTML was very much a multi-vendor, industry-wide affair; the problem was that the syntax of XML was stricter than the syntax of HTML, and the web was already littered with brok…

I remember just using PHP sessions back then on a XHTML document produced parse errors. Because PHP added the session to the query strings of links and used the raw & character instead of & for separating params in the query string. Thus causing a XML parse error.

There was a push to prevent browsers to be too lenient with the syntax in order to avoid the problem that sloppy HTML produced (inconsistent rendering across browsers)

Re: Why can't HTML alone do includes?

#332

Post by astrobe_ »

mikeg8 wrote: post #326
NorwegianDude wrote: post #324

Earlier quoted context omitted.

Then you just pre-build the page before publishing it. It's way cheaper as you do the work once, instead of every client being much slower because they have to do additional requests.

An additional requests for html isn’t slow, and now I have to have a whole “build” process for something that is basically static. Not ideal

By "whole 'build' process", do you think something like a makefile or do you think something more advanced is required?

One drawback though would be that one indeed would have to maintain dependencies, which would be error prone beyond simply adding headers and footers... I wonder if one could (ab)use CPP [1] and its -M option to do that.

[1] https://gcc.gnu.org/onlinedocs/cpp/Invocation.html

Re: Why can't HTML alone do includes?

#333

Post by j45 »

masklinn wrote: post #323
j45 wrote: post #321

Earlier quoted context omitted.

It’s not ideal, but t it does exist in pure html… and the OP didn’t seem to note it. A bit of vanilla JavaScript with WebComponents is a few lines: https://gomakethings.com/html-includes-with-web-components/ Edit: “t” was supposed to be the object tag.

> it does exist in pure html [...] JavaScript with WebComponents You seem to have a rather original definition of "pure HTML".

Typo, from the numerous fat finger typos you see above. :)

An html only option that exists is using object. Replying to the miss of the OP in case others might find it suitable.

If a tiny bit of vanilla JavaScript can be tolerated, WebComponents appear to have a broad standardized approach that is not framework dependant.

Re: Why can't HTML alone do includes?

#334

Post by lelanthran »

NorwegianDude wrote: post #324
lelanthran wrote: post #314

Earlier quoted context omitted.

> As the article says, the problem is a solved one. It's "solved" only in the sense that you need to use a programming language on the server to "solve" it. If all you are doing is static pages, it's most definitely not solved.

Then you just pre-build the page before publishing it. It's way cheaper as you do the work once, instead of every client being much slower because they have to do additional requests.

> Then you just pre-build the page before publishing it.

That's "using a programming language to solve the problem", isn't it?

> It's way cheaper as you do the work once, instead of every client being much slower because they have to do additional requests.

What work do client-side includes have to do other than fetching the page (which will get cached anyway)? It's less work to have a `` builtin than even a simple Makefile on the server.

Re: Why can't HTML alone do includes?

#335

Post by bazoom42 »

echelon wrote: post #217
int_19h wrote: post #183

Earlier quoted context omitted.

We also had a brief detour into XML with XHTML, and XML has XInclude, although it's not a required feature.

It's too bad we didn't go down the XHTML/semantic web route twenty years ago. Strict documents, reusable types, microformats, etc. would have put search into the hands of the masses rather than kept it in Google's unique domain. The web would have been more composible and P2P. We'd have been able to slurp first class article content, comments, contact details, factual information, addresses, etc., and built a wealth…

XHTML was just a more strict syntax for HTML. It didnt make it any more semantic.

Re: Why can't HTML alone do includes?

#336

Post by mildred593 »

xg15 wrote: post #136
throwup238 wrote: post #64

The feature proposal was called HTML Imports [1], created as part of the Web Components effort. > HTML Imports are a way to include and reuse HTML documents in other HTML documents There were plans for tag support and everything. If I remember correctly, Google implemented the proposed spec in Blink but everyone else balked for various reasons. Mozilla was concerned with the complexity of the implementation and its s…

That matches with the comment [1] on the article, citing insufficient demand, no vendor enthusiasm, etc. The thing is that all those are non-reasons that don't really explain anything: Low demand is hard to believe if this feature is requested for 20 years straight and there are all kinds of shim implementations using scripts, backend engines, etc. (And low demand didn't stop other features that the vendors were inte…

HTML imports could not include markup within the body, it could only be used to reference template elements for custom elements

Re: Why can't HTML alone do includes?

#337

Post by cowsandmilk »

mildred593 wrote: post #331
safety1st wrote: post #268

Earlier quoted context omitted.

I'm as big a critic of Google as anyone, but I'm always surprised at modern day takes around the lost semantic web technologies - they are missing facts or jumping to conclusions in hindsight. Here's what people should know. 1) The failure of XHTML was very much a multi-vendor, industry-wide affair; the problem was that the syntax of XML was stricter than the syntax of HTML, and the web was already littered with brok…

I remember just using PHP sessions back then on a XHTML document produced parse errors. Because PHP added the session to the query strings of links and used the raw & character instead of & for separating params in the query string. Thus causing a XML parse error. There was a push to prevent browsers to be too lenient with the syntax in order to avoid the problem that sloppy HTML produced (inconsistent rendering…

That is not true at all…

Re: Why can't HTML alone do includes?

#338

Post by mildred593 »

benstigsen wrote: post #281
tgv wrote: post #74

Earlier quoted context omitted.

I think it feels off because an HTML file can include scripts, fonts, images, videos, styles, and probably a few other things. But not HTML. It can probably be coded with a custom element ( ). I would be surprised if there wasn't a github repo with something similar.

I created something like this relatively recently. The downside is of course that it requires JavaScript. https://github.com/benstigsen/include.js

I also improved an existing custom component for this : https://amc.melanie-de-la-salette.fr/polyfill.js

Re: Why can't HTML alone do includes?

#339

Post by HumanOstrich »

PaulHoule wrote: post #300
johnisgood wrote: post #295

Earlier quoted context omitted.

But this requires JavaScript...

... but the folks behind that standard don't want to encourage browsing with Javascript off.

Why would the ES standards organization that defines JavaScript syntax encourage people not to use it?
Post reply on HN