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

151–160 of 367 posts

Re: Why can't HTML alone do includes?

#151

Post by omoikane »

somethingsome wrote: post #42

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…

> an infinite loop of includes

We can probably copy the specs for and deal with it the same way:

https://www.w3.org/TR/WD-frames-970331#:~:text=Infinite%20Re...

    Any frame that attempts to assign as its SRC a URL used by any of its ancestors is treated as if it has no SRC URL at all (basically a blank frame).
> How to ensure that all other browsers implement it in the same way?

Browsers that don't implement the specs will eventually break:

https://bugzilla.mozilla.org/show_bug.cgi?id=8065

Re: Why can't HTML alone do includes?

#152

Post by giantrobot »

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…

Frames were widely abused by early web apps to do dynamic interfaces before XHR was invented/widely supported. The "app" had a bunch of sub-frames with all the links and forms carefully pointing to different frames in the frameset.

A link in a sidebar frame would open a link in the "editor" frame which loaded a page with a normal HTML form. Submitting the form reloaded it in that same frame. Often the form would have multiple submit buttons, one to save edits in progress and another to submit the completed form and move to the next step. The current app state was maintained server side and validation was often handled there save for some basic formatting client side JavaScript could handle.

This setup allowed even the most primitive frame-supporting browsers to use CRUD web apps. IIRC early web frameworks like WebObjects leaned into that model of web app.

Re: Why can't HTML alone do includes?

#153

Post by mattl »

gyesxnuibh wrote: post #54
cantSpellSober wrote: post #51

Earlier quoted context omitted.

Well said this is many students' intro to PHP. Why not ` ` though? Some content is already loaded asynchronously such as images, content below the fold etc. > HTML is really just a markup syntax, not a programming language flamebait detected :) It's a declarative language, interpreted by each browser engine separately.

What's the ML in HTML stand for? I think that's probably the crux of the argument. Are we gonna evolve it past its name?

> What's the ML in HTML stand for?

I always assumed it stood for my initials.

Re: Why can't HTML alone do includes?

#154

Post by thayne »

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…

To be fair, it was pretty complicated. IIRC, using it required using Javascript to instantiate the template after importing it, rather than just having something like .

Re: Why can't HTML alone do includes?

#155

Post by mattl »

sreekotay wrote: post #114
alecsm wrote: post #109

Earlier quoted context omitted.

But you need a server for that to work.

you need a server for HTML to work, as practical matter. But yes. There IS a workaround to that too, if you're REALLY determined, but you have to format your HTML a giant JS comment block (lol really :)) [edit: I'm sure there are still some file:// workflows for docs - and yes this doesn't address that]

You don't need a server for HTML to work, I can just hand you a USB stick/floppy disk/MO disk for your NeXT with HTML files on it.

Re: Why can't HTML alone do includes?

#157

Post by Devasta »

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.

Re: Why can't HTML alone do includes?

#158

Post by simultsop »

It's a pity, of all web resources advancements, js, css, runtimes, web engines. HTML was the most stagnant aspect of it, despite the "HTML5" effing hype. My guess is they did not want to empower HTML and threaten SSR's, or solutions. I believe the bigest concern of not making a step is the damned backward compatibility. Some just wont budge to move.

Re: Why can't HTML alone do includes?

#159

Post by thayne »

simonjgreen wrote: post #150

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…

One benefit of doing it on the client is the client can cache the result of an include. So for example, instead of having to download the content of a header and footer for every page, it is just downloaded once and re-usef for future pages
Post reply on HN