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

131–140 of 367 posts

Re: Why can't HTML alone do includes?

#131

Post by _heimdall »

mark_and_sweep wrote: post #93
_heimdall wrote: post #59

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.

I believe XSLT 1 is still working in all major browsers today. Here's a simple HTML 5 example with two pages sharing a header template: https://gist.github.com/MarkTiedemann/0e6d36c337159a3e6d5072...

My main gripe is a decade(s?) old Firefox bug related to rendering an HTML string to the DOM.

That may be a fairly specific use case though, and largely it still works great today. I've done a few side projects with XSLT and web components for interactivity, worked great.

Re: Why can't HTML alone do includes?

#133

Post by TZubiri »

Because it's HyperText, the main idea is that you link to other content, so this is not a weird feature that is being asked for, it's just a different way of doing the whole raison d'etre of the tech. In fact the tag to link stuff is the tag. It just so happens that it makes you load the other "page", instead of transcluding content, the idea is that you load it.

It wouldn't make sense to transclude the article about the United States in the article about Wyoming (and in fact modern wikipedia shows a pop up bubble doing a partial transclusion, but would benefit in no way from basic html transclusion.)

It's a simple idea. But of course modern HTML is not at all what HTML was designed to be, but that's the canonical answer.

The elders of HTML would just tell you to make an link to whatever you wanted to transclude instead. Be it a "footer/header/table of contents" or another encylcopdic article, or whatever. Because that's how HTML works, and not the way you suggest.

Think of what would happen if it were the case, you would transclude page A, which transcludes page B, and so with page C, possibly recursively transcluding page B and so. You would transform the User Agent (browser) into a whole WWW crawler!

It's because HTML is pass by reference, not pass by copy.

Re: Why can't HTML alone do includes?

#134

Post by TZubiri »

kyledrake wrote: post #130

At least some of the blame here is the bias towards HTML being something that is dynamic code generated, as opposed to something that is statically handwritten by many people. There are features that would be good for the latter that have been removed. For example, if you need to embed HTML code examples, you can use the tag, which makes it so you don't need to encode escapes. Sadly, the HTML5 spec is trying to obsol…

It's the other way around, HTML was designed to be hand written, and the feature set was defined at that stage. If it ended up being dynamically generated, that happened after the feature set was defined.

Re: Why can't HTML alone do includes?

#135

Post by _heimdall »

SvenL wrote: post #115
_heimdall wrote: post #59

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.

I think XSLT is still a reasonable technology in itself - the lack of updated implementations is the bad part. I think modern browsers only support 1.0 (?). At least most modern programming languages should have 3.0 support.

Firefox has a very old bug related to rendering an HTML string to the DOM without escaping it, that one has bit me a few times. Nothing a tiny inline script can't fix, but its frustrating to have such a basic feature fail.

Debugging is also pretty painful, or I at least haven't found a good dev setup for it.

That said, I'm happy to reach for XSLT when it makes sense. Its pretty amazing what can be done with such an old tech, for the core use case of props and templates to HTML you really don't need react.

Re: Why can't HTML alone do includes?

#136

Post by xg15 »

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 interested in for their own reasons)

Vendor refusal also doesn't explain why they refused it, even to the point of rolling back implementations that already existed.

So I'd be interested to understand the "various reasons" in more detail.

"Security implications" also seem odd as you already are perfectly able to import HTML cross origin using script tags. Why is importing a script that does document.write() fine, but a HTML tag that does exactly the same thing hugely problematic?

(I understand the security concern that you wouldn't want to allow something like "" and get an instant clone of the Google homepage. But that issue seems trivially solvable with CORS.)

[1] https://frontendmasters.com/blog/seeking-an-answer-why-cant-...

Re: Why can't HTML alone do includes?

#138

Post by Telemakhos »

kmoser wrote: post #132

SHTML used to be a thing back in the 1990s: https://en.wiktionary.org/wiki/SHTML

Or, better, "Server Side Includes" (SSI): https://en.wikipedia.org/wiki/Server_Side_Includes

SSI is still a thing: I use it on my personal website. It isn't really part of the HTML, though: it's a server-dependent extension to HTML. It's supported by Apache and nginx, but not by every server, so you have to have control over the server stack, not just access to the documents.

Re: Why can't HTML alone do includes?

#139

Post by miragecraft »

I too lamented the loss of HTML imports and ended up coming up with my own JavaScript library for it.

https://miragecraft.com/blog/replacing-html-imports

At the end of the day it’s not something trivial to implement at the HTML spec/parser level.

For relative links, how should the page doing the import handle them?

Do nothing and let it break, convert to absolute links, or remap it as a new relative link?

Should the include be done synchronously or asynchronously?

The big benefit of traditional server side includes is that its synchronous, thus simplifying logic for in-page JavaScript, but all browsers are trying to eliminate synchronous calls for speed, it’s hard to see them agreeing to add a new synchronous bottleneck.

Should it be CORS restricted? If it is then it blocks offline use (file:// protocol) which really kills its utility.

There are a lot of hurdles to it and it’s hard to get people to agree on the exact implementation, it might be best to leave it to JavaScript libraries.

Re: Why can't HTML alone do includes?

#140

Post by dwheeler »

HTML was historically an application of SGML, and SGML could do includes. You could define a new "entity", and if you created a "system" entity, you could refer to it later and have it substituted in.

    
    ]>
    ....
    &myheader;
SGML is complex, so various efforts were made to simplify HTML, and that's one of the capabilities that was dropped along the way.
Post reply on HN