Live data from Hacker News

Why can't HTML alone do includes?

frontendmasters.com

71–80 of 367 posts

Re: Why can't HTML alone do includes?

#71
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…

I mean in 1996s netscape you could do this (I run the server for a website that still uses this):

    
    
      
        
        
      
    
  
The thing that always bugged me about frames is that they are too clever. I don't want to reload only the frame html when I rightclick and reload. Sure the idea was to cache those separately, but come on — frames and caching are meant to solve two different problems and by munching them together they somewhat sucked at solving either.

To me includes for HTML should work in the dumbest way possible. And that means: Take the text from the include and paste it where the include was and give the browser the resulting text.

If you want to cache a nav section separately because it appears the same on every page lets add a cache attribute that solves the problem independently:

  
    
  
  
To tell the browser it should load the inner html or the src of that element from cache if it has it.

Now you could convince me thst the include should allow for more, but it being dumb is a feature not a bug.

Re: Why can't HTML alone do includes?

#72
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…

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.

Re: Why can't HTML alone do includes?

#73

Earlier quoted context omitted.

Unlike Framesets I think XML includes were never really supported in many browsers (or even any major browsers)? I still like to use them occasionally but it incurs a "compilation" step to evaluate them prior to handing the result of this compilation to the users/browsers.

As it happens, the major browsers still can do XML 'includes' to some extent, since by some miracle they haven't torn out their support for XSLT 1.0. E.g. this outputs "FizzBuzz" on Firefox: Fizz Buzz You can even use XSLT for HTML5 output, if you're careful. But YMMV with which XML processors will support stylesheets.

Nice, didn't think of that approach and It should work very well for the purposes of static headers and footers.

Re: Why can't HTML alone do includes?

#74
post #34

"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…

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.

Re: Why can't HTML alone do includes?

#75

Earlier quoted context omitted.

As it happens, the major browsers still can do XML 'includes' to some extent, since by some miracle they haven't torn out their support for XSLT 1.0. E.g. this outputs "FizzBuzz" on Firefox: Fizz Buzz You can even use XSLT for HTML5 output, if you're careful. But YMMV with which XML processors will support stylesheets.

Yep, and this can be used to e.g. make a basically static site template and then do an include for `userdata.xml` to decorate your page with the logged in user's info (e.g. on HN, adding your username in the top right, highlighting your comments and showing the edit/delete buttons, etc.). You can for example include into a variable ` ` and then use it in xpath expressions like `$myinfo/user/@id`. Extremely simple, go…

> if resources were devoted to this

You'd better not jinx it: XSL support seems like just the sort of thing browser devs would want to tear out in the name of reducing attack surface. They already dislike the better-known SVG and never add any new features to it. I often worry that the status quo persists only because they haven't really thought about it in the last 20 years.

Re: Why can't HTML alone do includes?

#76
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…

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.

Re: Why can't HTML alone do includes?

#78
post #34

"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?

Re: Why can't HTML alone do includes?

#79
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…

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.

This isn’t programming. It’s transclusion[0]. Essentially, iframes and images are already forms of transclusion, so why not transclude html and have the iframe expand to fit the content?

As I wrote that, I realized there could be cumulative layout shift, so that’s an argument against. To avoid that, the browser would have to download all transcluded content before rendering. In the past, this would have been a dealbreaker, but maybe it’s more feasible now with http multiplexing.

[0] https://en.m.wikipedia.org/wiki/Transclusion#Client-side_HTM...

Re: Why can't HTML alone do includes?

#80
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…

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.

Including another document is much closer to a markup operation than a programming operation. We already include styles, scripts, images, videos, fonts...why not document fragments?

Markdown can't do most of those, so it makes more sense why it doesn't have includes, but I'd still argue it definitely should. I generally dislike LaTeX, but about the only thing I liked about it when writing my thesis was that I could have each chapter in its own file and just include all of them in the main file.

Post reply on HN