4 ms·

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 s

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.

paulddraper 1y ago
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.
- ummonk 1y ago
  No, HTML is fundamentally different because (for a static site without any JS dom manipulation) it has all the semantic content, while stylesheets, images, objects, etc. are just about presentation.
  - Aloisius 1y ago
    Iframes exist.
  - paulddraper 1y ago
    Images are content. Videos are content. Objects/iframes are content. The only one that is presentational is stylesheets.
    - ummonk 1y ago
      Images and videos are not semantic content. The alt attributes that describe them on the other hand are indeed semantic content.
      - DemocracyFTW2 1y ago
        > Images and videos are not semantic content Something in that tenet does not compute with me.
        vacuity 1y ago
        I think the distinction is "semantic on what level/perspective?". An image packaged as a binary blob is semantically opaque until it is rendered. Meanwhile, seeing <img> in the HTML or the file extension .jpg in any context that displays file extensions tells me some information right out of the gate. And note that all three of these examples are different information: the HTML tag tells me it's an image, whereas the file extension tells me it's a JPEG image, and the image tells me what the image contains. HTML is an example of some kind of separation, as it can tell you some semantic meaning of the data without telling you all of it. Distinguishing and then actually separating semantics means data can be interpreted with different semantics, and we usually choose to focus on one alternative interpretation. Then I can say that HTML alone regards some semantics (e.g. there is an image here) while disregarding others (e.g. the image is an image of a brick house).
        ummonk 1y ago
        I'm not sure what isn't computing. Presumably you know (or have looked up) the meaning of "semantic"? Images and videos are graphic, not semantic, content. To the extent they are rendering semantic content, that content should be described in the alt tag.
      - paulddraper 1y ago
        Can you describe what semantic, non-textual content would be?
    - hnick 1y ago
      Which (as I'm sure you know), also literally has 'content' :) https://developer.mozilla.org/en-US/docs/Web/CSS/content https://developer.mozilla.org/en-US/docs/Web/CSS/content
      - paulddraper 1y ago
        True :)
dimal 1y ago
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_HTML https://en.m.wikipedia.org/wiki/Transclusion#Client-side_HTM...
- PoignardAzur 1y ago
  With Early Hints (HTTP code 103), it seems especially feasible. You can start downloading the included content one round-trip after the first byte is sent.
franga2000 1y ago
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.
crazygringo 1y ago
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 invented, rather than a basic include. To save on bandwidth or something?
- mattl 1y ago
  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.
- giantrobot 1y ago
  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.
  - crazygringo 1y ago
    Oh my goodness, yes you're right, I'd forgotten entirely about those. They were horrible -- you'd hit the back button and only one of the frames would go back and then the app would be in an inconsistent state... it was a mess!
    - giantrobot 1y ago
lenkite 1y ago
Well, asciidoc - a markup language supports includes, so the "markup languages" analogy doesn't hold. https://docs.asciidoctor.org/asciidoc/latest/directives/include/ https://docs.asciidoctor.org/asciidoc/latest/directives/incl...
- deleted 1y ago
  [deleted]
- deleted 1y ago
  [deleted]
actinium226 1y ago
Markdown doesn't have this common HTML pattern of wanting to include a header/footer in all pages of a site.

paulddraper 1y ago

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.

ummonk 1y ago
No, HTML is fundamentally different because (for a static site without any JS dom manipulation) it has all the semantic content, while stylesheets, images, objects, etc. are just about presentation.
- Aloisius 1y ago
  Iframes exist.
- paulddraper 1y ago
  Images are content. Videos are content. Objects/iframes are content. The only one that is presentational is stylesheets.
  - ummonk 1y ago
    Images and videos are not semantic content. The alt attributes that describe them on the other hand are indeed semantic content.
    - DemocracyFTW2 1y ago
      > Images and videos are not semantic content Something in that tenet does not compute with me.
      - vacuity 1y ago
        I think the distinction is "semantic on what level/perspective?". An image packaged as a binary blob is semantically opaque until it is rendered. Meanwhile, seeing <img> in the HTML or the file extension .jpg in any context that displays file extensions tells me some information right out of the gate. And note that all three of these examples are different information: the HTML tag tells me it's an image, whereas the file extension tells me it's a JPEG image, and the image tells me what the image contains. HTML is an example of some kind of separation, as it can tell you some semantic meaning of the data without telling you all of it. Distinguishing and then actually separating semantics means data can be interpreted with different semantics, and we usually choose to focus on one alternative interpretation. Then I can say that HTML alone regards some semantics (e.g. there is an image here) while disregarding others (e.g. the image is an image of a brick house).
      - ummonk 1y ago
        I'm not sure what isn't computing. Presumably you know (or have looked up) the meaning of "semantic"? Images and videos are graphic, not semantic, content. To the extent they are rendering semantic content, that content should be described in the alt tag.
    - paulddraper 1y ago
      Can you describe what semantic, non-textual content would be?
  - hnick 1y ago
    Which (as I'm sure you know), also literally has 'content' :) https://developer.mozilla.org/en-US/docs/Web/CSS/content https://developer.mozilla.org/en-US/docs/Web/CSS/content
    - paulddraper 1y ago
      True :)

dimal 1y ago

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_HTML https://en.m.wikipedia.org/wiki/Transclusion#Client-side_HTM...

PoignardAzur 1y ago
With Early Hints (HTTP code 103), it seems especially feasible. You can start downloading the included content one round-trip after the first byte is sent.

franga2000 1y ago

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.

crazygringo 1y ago

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 invented, rather than a basic include. To save on bandwidth or something?

mattl 1y ago
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.
giantrobot 1y ago
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.
- crazygringo 1y ago
  Oh my goodness, yes you're right, I'd forgotten entirely about those. They were horrible -- you'd hit the back button and only one of the frames would go back and then the app would be in an inconsistent state... it was a mess!
  - giantrobot 1y ago

lenkite 1y ago

Well, asciidoc - a markup language supports includes, so the "markup languages" analogy doesn't hold. https://docs.asciidoctor.org/asciidoc/latest/directives/include/ https://docs.asciidoctor.org/asciidoc/latest/directives/incl...

deleted 1y ago
[deleted]
deleted 1y ago
[deleted]

actinium226 1y ago

Markdown doesn't have this common HTML pattern of wanting to include a header/footer in all pages of a site.