5 ms·

"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

by rchaud 1y ago

"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. There really isn't any need to make includes available through just HTML. HTML is a presentation format and doesn't do anything interesting without CSS and JS anyway.

assimpleaspossi 1y ago
Agree with what you said, however, HTML is a document description language and not a presentation format. CSS is for presentation (assuming you meant styling).
- PaulDavisThe1st 1y ago
  They didn't mean styling. HTML is a markup language that identifies the functional role of bits of text. In that sense, it is there to provide information about how to present the text, and is thus a presentation format. It is also a document description language, because almost all document description languages are also a presentation format.
cantSpellSober 1y ago
Well said this is many students' intro to PHP. Why not `<include src=header.html/>` 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.
- gyesxnuibh 1y ago
  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?
  - cantSpellSober 1y ago
    That's why I joked about flamebait, it's hypertext though, aren't anchors essentially a goToURL() click handler in some ways? Template partials seem like a basic part of this system. > considered to be server-side Good point! Wouldn't fetching a template partial happen the same way (like fetching an image?)
  - Aloisius 1y ago
    If the issue is that "include" somehow makes it sound like it's not markup, the solution seems obvious. Just use the src attribute on other tags: <html src="/some/page.html">, <div src="/some/div.html">, <span src="/some/span.html">, etc. Or create a new tag that's a noun like fragment, page, document, subdoc or something. Surely that's no less markup than svg, img, script, video, iframe, and what not.
    - deleted 1y ago
      [deleted]
  - mattl 1y ago
    > What's the ML in HTML stand for? I always assumed it stood for my initials.
  - int_19h 1y ago
    It stands for "markup language", and was inherited from SGML, which had includes. Strictly speaking, so did early HTML (since it was just an SGML subset), it's just that browsers didn't bother implementing it, for the most part. So it's not that it didn't evolve, but rather it devolved. Nor is this something unique to SGML. XML is also a "markup language", yet XInclude is a thing.
    - DemocracyFTW2 1y ago
      > It stands for "markup language", and was inherited from SGML, which had includes touchay!!
naasking 1y ago
> "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. That's not an argument that client-side includes shouldn't happen. In fact HTML already has worse versions of this via frames and iframes. A client-side equivalent of a server-side include fits naturally into what people do with HTML.
tgv 1y ago
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 (<include src=.../>). I would be surprised if there wasn't a github repo with something similar.
- benstigsen 1y ago
  I created something like this relatively recently. The downside is of course that it requires JavaScript. https://github.com/benstigsen/include.js https://github.com/benstigsen/include.js
  - mildred593 1y ago
    I also improved an existing custom component for this : https://amc.melanie-de-la-salette.fr/polyfill.js https://amc.melanie-de-la-salette.fr/polyfill.js
amadeuspagel 1y ago
This argument applies just as much to CSS and JS. Why do they include "includes" when you can just bundle on the server?
- adregan 1y ago
  For caching and sharing resources across the whole site, I suppose.
  - john_the_writer 1y ago
    But that would apply to <header> and <footer> and <nav> too. We could cache them.
c-smile 1y ago
> "Includes" functionality is considered to be server-side Exactly! Include makes perfect sense on server-side. But client-side include means that the client should be able to modify original DOM at unknown moment of time. Options are 1. at HTML parse time (before even DOM is generated). This requires synchronous request to server for the inclusion. Not desirable. 2. after DOM creation: <include src=""> (or whatever) needs to appear in the DOM, chunk loaded asynchronously and then the <include> DOM element(sic!) needs to be replaced(or how?) by external fragment. This disables any existing DOM structure validation mechanism. Having said that... I've implemented <include> in my Sciter engine using strategy #1. It works there as HTML in Sciter usually comes from local app resources / file system where price of issuing additional "get chunk" request is negligible. See: https://docs.sciter.com/docs/HTML/html-include https://docs.sciter.com/docs/HTML/html-include
DemocracyFTW2 1y ago
hearing someone assert that > the problem is a solved one is a sure-fire way to know that a problem is not solved
lelanthran 1y ago
> 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.
- NorwegianDude 1y ago
  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.
  - mikeg8 1y ago
    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
    - astrobe_ 1y ago
      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 https://gcc.gnu.org/onlinedocs/cpp/Invocation.html
    - NorwegianDude 1y ago
      Well, that very much depends on your definition of slow, doesn't it? An additional request is another round trip. That can be very slow. Average TTFB on the internet in the US is ~0.7 seconds. It's much faster to send it as part of the same request as you then don't have to wait for the browser to discover it, request it, wait for the response and then add it. A build process does not have to be complicated, at all. If you can write HTML then using something that can simply read the HTML includes you wish existed and swap it with the specified filename is trivial. Ofc, the idea has many other issues, like how to handle dependencies of the included HTML, how to handle conflicts, what oath to use and many more.

by rchaud 1y ago

assimpleaspossi 1y ago

Agree with what you said, however, HTML is a document description language and not a presentation format. CSS is for presentation (assuming you meant styling).

PaulDavisThe1st 1y ago
They didn't mean styling. HTML is a markup language that identifies the functional role of bits of text. In that sense, it is there to provide information about how to present the text, and is thus a presentation format. It is also a document description language, because almost all document description languages are also a presentation format.

cantSpellSober 1y ago

Well said this is many students' intro to PHP. Why not `<include src=header.html/>` 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.

gyesxnuibh 1y ago
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?
- cantSpellSober 1y ago
  That's why I joked about flamebait, it's hypertext though, aren't anchors essentially a goToURL() click handler in some ways? Template partials seem like a basic part of this system. > considered to be server-side Good point! Wouldn't fetching a template partial happen the same way (like fetching an image?)
- Aloisius 1y ago
  If the issue is that "include" somehow makes it sound like it's not markup, the solution seems obvious. Just use the src attribute on other tags: <html src="/some/page.html">, <div src="/some/div.html">, <span src="/some/span.html">, etc. Or create a new tag that's a noun like fragment, page, document, subdoc or something. Surely that's no less markup than svg, img, script, video, iframe, and what not.
  - deleted 1y ago
    [deleted]
- mattl 1y ago
  > What's the ML in HTML stand for? I always assumed it stood for my initials.
- int_19h 1y ago
  It stands for "markup language", and was inherited from SGML, which had includes. Strictly speaking, so did early HTML (since it was just an SGML subset), it's just that browsers didn't bother implementing it, for the most part. So it's not that it didn't evolve, but rather it devolved. Nor is this something unique to SGML. XML is also a "markup language", yet XInclude is a thing.
  - DemocracyFTW2 1y ago
    > It stands for "markup language", and was inherited from SGML, which had includes touchay!!

naasking 1y ago

> "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. That's not an argument that client-side includes shouldn't happen. In fact HTML already has worse versions of this via frames and iframes. A client-side equivalent of a server-side include fits naturally into what people do with HTML.

tgv 1y ago

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 (<include src=.../>). I would be surprised if there wasn't a github repo with something similar.

benstigsen 1y ago
I created something like this relatively recently. The downside is of course that it requires JavaScript. https://github.com/benstigsen/include.js https://github.com/benstigsen/include.js
- mildred593 1y ago
  I also improved an existing custom component for this : https://amc.melanie-de-la-salette.fr/polyfill.js https://amc.melanie-de-la-salette.fr/polyfill.js

amadeuspagel 1y ago

This argument applies just as much to CSS and JS. Why do they include "includes" when you can just bundle on the server?

adregan 1y ago
For caching and sharing resources across the whole site, I suppose.
- john_the_writer 1y ago
  But that would apply to <header> and <footer> and <nav> too. We could cache them.

c-smile 1y ago

> "Includes" functionality is considered to be server-side Exactly! Include makes perfect sense on server-side. But client-side include means that the client should be able to modify original DOM at unknown moment of time. Options are 1. at HTML parse time (before even DOM is generated). This requires synchronous request to server for the inclusion. Not desirable. 2. after DOM creation: <include src=""> (or whatever) needs to appear in the DOM, chunk loaded asynchronously and then the <include> DOM element(sic!) needs to be replaced(or how?) by external fragment. This disables any existing DOM structure validation mechanism. Having said that... I've implemented <include> in my Sciter engine using strategy #1. It works there as HTML in Sciter usually comes from local app resources / file system where price of issuing additional "get chunk" request is negligible. See: https://docs.sciter.com/docs/HTML/html-include https://docs.sciter.com/docs/HTML/html-include

DemocracyFTW2 1y ago

hearing someone assert that > the problem is a solved one is a sure-fire way to know that a problem is not solved

lelanthran 1y ago

> 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.

NorwegianDude 1y ago
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.
- mikeg8 1y ago
  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
  - astrobe_ 1y ago
    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 https://gcc.gnu.org/onlinedocs/cpp/Invocation.html
  - NorwegianDude 1y ago
    Well, that very much depends on your definition of slow, doesn't it? An additional request is another round trip. That can be very slow. Average TTFB on the internet in the US is ~0.7 seconds. It's much faster to send it as part of the same request as you then don't have to wait for the browser to discover it, request it, wait for the response and then add it. A build process does not have to be complicated, at all. If you can write HTML then using something that can simply read the HTML includes you wish existed and swap it with the specified filename is trivial. Ofc, the idea has many other issues, like how to handle dependencies of the included HTML, how to handle conflicts, what oath to use and many more.