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

141–150 of 367 posts

Re: Why can't HTML alone do includes?

#141

Post by wizzwizz4 »

econ wrote: post #89
dimal wrote: post #47

Earlier quoted context omitted.

I know it’s possible to work around it, but that’s not the point. This is such a common use case that it seems worthwhile to pave the cowpath. We’ve paved a lot of cowpaths that are far less trodden than this one. This is practically a cow superhighway. We’ve built an industry around solving this problem. What if, for some basic web publishing use cases, we could replace a complex web framework with one new tag?

I couldn't agree more.

https://www.w3.org/TR/xhtml2/introduction.html

> XHTML 2 takes a completely different approach, by taking the premise that all images have a long description and treating the image and the text as equivalents. In XHTML 2 any element may have a @src attribute, which specifies a resource (such as an image) to load instead of the element.

Re: Why can't HTML alone do includes?

#142

Post by giantrobot »

JadeNB wrote: post #119
codr7 wrote: post #103

Earlier quoted context omitted.

The optimal solution would be using a template engine to generate static documents.

> The optimal solution would be using a template engine to generate static documents. This helps the creator, but not the consumer, right? That is, if I visit 100 of your static documents created with a template engine, then I'll still be downloading some identical content 100 times.

XSLT solved this problem. But it had poor tool support (DreamWeaver etc) and a bunch of anti-XML sentiment I assume as blowback from capital-E Enterprise stacks going insane with XML for everything.

XSLT did exactly what HTML includes could do and more. The user agent could cache stylesheets or if it wanted override a linked stylesheet (like with CSS) and transform the raw data any way it wanted.

Re: Why can't HTML alone do includes?

#145

Post by rorylaitila »

I'm a full stack developer. I do server side rendering. I agree that this is a 'solved problem' for that case. However there are many times I don't want to run a server or a static site generator. I manage a lot of projects. I don't want more build steps than necessary. I just want to put some HTML on the net with some basic includes, without JavaScript. But currently I would go the web component route and accept the extra JS.

Re: Why can't HTML alone do includes?

#146

Post by giantrobot »

api wrote: post #85
dimal wrote: post #17

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…

The web seems like it was deliberately designed to make any form of composability impossible. It’s one of the worst things about it as a platform. I’m sure some purist argument has driven this somewhere.

I look back longingly at the promise of XML services in the early days of Web 2.0. Before the term just meant JavaScript everywhere.

All sorts of data could be linked together to display or remix by user agents.

Re: Why can't HTML alone do includes?

#148

Post by mattl »

crazygringo wrote: post #92
luotuoshangdui wrote: post #72

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.

I think this is the most likely answer. 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 inve…

A lot of early HTML was about taking the output of a different system such as a mainframe and putting that output into HTML.

Lots of gateways between systems.

Re: Why can't HTML alone do includes?

#149

Post by uallo »

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…

HTML Imports went in a similar direction but they do not do what the blog post is about. HTML should be imported and displayed in a specific place of the document. HTML Imports could not do this without JavaScript.

See https://github.com/whatwg/html/issues/2791#issuecomment-3112... for details.

Re: Why can't HTML alone do includes?

#150

Post by simonjgreen »

I know it’s not straight HTML, but SSI (server side includes) helped with this and back in the day made for some incredibly powerful caching solutions. You could write out chunks of your site statically and periodically refresh them in the server side, while benefitting from serving static content to your users. (This was in the pre varnish era, and before everyone was using memcached)

I personally used this to great success on a couple of Premier League football club websites around the mid 2000s.

Post reply on HN