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

251–260 of 367 posts

Re: Why can't HTML alone do includes?

#251

Post by DemocracyFTW2 »

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…

hearing someone assert that

> the problem is a solved one

is a sure-fire way to know that a problem is not solved

Re: Why can't HTML alone do includes?

#252

Post by DemocracyFTW2 »

int_19h wrote: post #187
gyesxnuibh wrote: post #54

Earlier quoted context omitted.

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?

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.

> It stands for "markup language", and was inherited from SGML, which had includes

touchay!!

Re: Why can't HTML alone do includes?

#253

Post by tannhaeuser »

echelon wrote: post #217
int_19h wrote: post #183

Earlier quoted context omitted.

We also had a brief detour into XML with XHTML, and XML has XInclude, although it's not a required feature.

It's too bad we didn't go down the XHTML/semantic web route twenty years ago. Strict documents, reusable types, microformats, etc. would have put search into the hands of the masses rather than kept it in Google's unique domain. The web would have been more composible and P2P. We'd have been able to slurp first class article content, comments, contact details, factual information, addresses, etc., and built a wealth…

The "semantic" part was what eventually became W3C's RDF stuff (a pet peeve of TBL's predating even the Web). When people squeeze poetry, threaded discussion, and other emergent text forms into a vocabulary for casual academic publishing and call that "semantic HTML", that still doesn't make it semantic.

The "strict markup" part can be (and always could be) had using SGML which is just a superset of XML that also supports HTML empty elements, tag inference, attribute shortforms, etc. HTML was invented as SGML vocabulary in the first place.

Agree though that Google derailed any meaningful standardization effort for the readins you stated. Actually, it started already with CSS and the idioticy to pile yet another item-value syntax over SGML/HTML, when it already has attributes for formatting. The "semantic HTML" postulate is kind of just an after-the-fact justification for insane CSS complexity that could grow because it wasn't part of HTML proper and the scrutinity that goes with introducing new elements or attributes with it.

Re: Why can't HTML alone do includes?

#254

Post by perilunar »

jsdwarf wrote: post #110

I'd say in 80% of the cases a pure, static html include is not enough. In a menu include, you want to disable the link to the currently shown page or show a page specific breadcrumb. In a footer include, you may want a dynamic "last updated" timestamp or the current year in the copyright notice. As all these use cases required a server-side scripting language anyway, there was no push behind an html include.

> In a menu include, you want to disable the link to the currently shown page

I’ve always just styled the link to the current page differently, not disabled it, which you can do with an id on the page and a line of CSS.

Re: Why can't HTML alone do includes?

#255

Post by bawolff »

timewizard wrote: post #210
dwheeler wrote: post #140

HTML was historically an application of SGML, and SGML could do includes. You could define a new "entity", and if you created a "system" entity, you could refer to it later and have it substituted in. ]> .... &myheader; SGML is complex, so various efforts were made to simplify HTML, and that's one of the capabilities that was dropped along the way.

Well, that is an entire attack surface, on it's own. https://en.wikipedia.org/wiki/Billion_laughs_attack

https://en.wikipedia.org/wiki/XML_external_entity_attack would be the more relavent link.

Re: Why can't HTML alone do includes?

#256

Post by bawolff »

rbanffy wrote: post #225
fooker wrote: post #161

Earlier quoted context omitted.

> Why not have a simple client side method for this? Like writing a line of js?

A block of in-line JavaScript stops the renderer until it runs because its output cannot be determined before it completes.

So would any form of html inclusion.

Re: Why can't HTML alone do includes?

#257

Post by athrowaway3z »

xg15 wrote: post #136
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…

That matches with the comment [1] on the article, citing insufficient demand, no vendor enthusiasm, etc. The thing is that all those are non-reasons that don't really explain anything: Low demand is hard to believe if this feature is requested for 20 years straight and there are all kinds of shim implementations using scripts, backend engines, etc. (And low demand didn't stop other features that the vendors were inte…

That is a bit of a large ask.

There are various specs/semantics you can choose, which prescribe the implementation & required cross-cutting complexity. Security is only relevant in some of them.

To give you some idea:

- HTML load ordering is a pretty deeply held assumption. People understand JS can change those assumptions (document.write). Adding an obscure HTML tags that does so is going to be an endless parade of bugs & edge cases.

- To keep top-to-bottom fast we could define preload semantics (Dropping the linear req-reply, define client-cache update policy when the template changes, etc). Is that added complexity truly simpler than having the server combine templates?

- exists

In other words, to do the simplest thing 75% of people want, requires a few lines of code. Either client side or server side.

To fit the other 25% (even to 'deny' it) is endlessly complex in ways few if any can oversee.

Re: Why can't HTML alone do includes?

#258

Post by youngtaff »

thayne wrote: post #159
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

I’m willing to bet the runtime overhead of assembly on the client is going to be larger than the download cost of the fragments being included server or edge side and cached

Re: Why can't HTML alone do includes?

#259

Post by lkuty »

dwheeler wrote: post #140

HTML was historically an application of SGML, and SGML could do includes. You could define a new "entity", and if you created a "system" entity, you could refer to it later and have it substituted in. ]> .... &myheader; SGML is complex, so various efforts were made to simplify HTML, and that's one of the capabilities that was dropped along the way.

It existed also in DTD (Document Type Definition) used with HTML 4 and below, and XML. Came fromn SGML too I guess.

Re: Why can't HTML alone do includes?

#260

Post by iainmerrick »

JadeNB wrote: post #119
codr7 wrote: post #103

Earlier quoted context omitted.

The optimal solution would be using a template engine to generate static documents.

> The optimal solution would be using a template engine to generate static documents. This helps the creator, but not the consumer, right? That is, if I visit 100 of your static documents created with a template engine, then I'll still be downloading some identical content 100 times.

I'll still be downloading some identical content 100 times.

That doesn't seem like a significant problem at all, on the consumer side.

What is this identical content across 100 different pages? Page header, footer, sidebar? The text content of those should be small relative to the unique page content, so who cares?

Usually most of the weight is images, scripts and CSS, and those don't need to be duplicated.

If the common text content is large for some reason, put the small dynamic part in an iframe, or swap it out with javascript.

If anyone has a genuine example of a site where redundant HTML content across multiple pages caused significant bloat, I'd be interested to hear about it.

Post reply on HN