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

61–70 of 367 posts

Re: Why can't HTML alone do includes?

#61

Post by naasking »

rchaud wrote: 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…

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

Re: Why can't HTML alone do includes?

#62

Post by cratermoon »

lelandfe wrote: post #6
axelfontaine wrote: post #2

Iframes, while not perfect, are pretty close though...

Making iframes be the right size is super awkward. I might actually use them more if they were easy to get responsive. This post does link to a technique (new to me) to extract iframe contents:

Are we solving the information-centric transclusion problem, or the design-centric asset reuse problem? An iframe is fine for the former but is not geared towards design and layout solutions.

Re: Why can't HTML alone do includes?

#63

Post by naasking »

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…

> from a language point of view, HTML is a markup language, it 'must' have no logic or processing.

Client-side includes are not "processing". HTML already has frames and iframes which do this, just in a worse way, so we'd be better off.

Re: Why can't HTML alone do includes?

#64

Post by throwup238 »

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 security implications, as well as the overlap with ES6 modules. Without vendor support, the proposal was officially discontinued.

[1] https://www.w3.org/TR/html-imports/

Re: Why can't HTML alone do includes?

#65

Post by PaulDavisThe1st »

assimpleaspossi wrote: post #40
rchaud wrote: 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…

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

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.

Re: Why can't HTML alone do includes?

#66

Post by djoldman »

> Our developer brains scream at us to ensure that we’re not copying the exact code three times, we’re creating the header once then “including” it on the three (or a thousand) other pages.

Interesting, my brain is not this way: I want to send a minimum number of files per link requested. I don't care if I include the same text because the web is generally slow and it's generally caused by a zillion files sent and a ton of JS.

Re: Why can't HTML alone do includes?

#67

Post by lelandfe »

cratermoon wrote: post #62
lelandfe wrote: post #6

Earlier quoted context omitted.

Making iframes be the right size is super awkward. I might actually use them more if they were easy to get responsive. This post does link to a technique (new to me) to extract iframe contents:

Are we solving the information-centric transclusion problem, or the design-centric asset reuse problem? An iframe is fine for the former but is not geared towards design and layout solutions.

It kinda sucks for both! Dropping in a box of text that flatly does not resize to fit its contents does not fit the definition of "fine" for me, here.

You can do some really silly maneuvers with `window.postMessage` to communicate an expected size between the parent and frame on resize, but that's expensive and fiddly.

Re: Why can't HTML alone do includes?

#68

Post by LegionMammal978 »

Linux-Fan wrote: post #50
austin-cheney wrote: post #38

So, HTML did have includes and they fell out of favor. The actual term include is an XML feature and it’s that feature the article is hoping for. HTML had an alternate approach that came into existence before XML. That approach was frames. Frames did much more than XML includes and so HTML never gained that feature. Frames lost favor due to misuse, security, accessibility, and variety of other concerns.

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.

Re: Why can't HTML alone do includes?

#70

Post by ndriscoll »

LegionMammal978 wrote: post #68
Linux-Fan wrote: post #50

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.

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, good for caching, lightweight, very high performance. Easy to fail gracefully to the logged out template. You basically get your data "API" for free since you're returning XML in your data model. I will never understand why it didn't take off.

XML includes are blocking because XSL support hasn't been updated for 25 years, but there's no reason why we couldn't have it async by now if resources were devoted to this instead of webusb etc.

Post reply on HN