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

301–310 of 367 posts

Re: Why can't HTML alone do includes?

#301

Post by silvestrov »

jefftk wrote: post #95
silvestrov wrote: post #57

Earlier quoted context omitted.

The real problem with iframes is that their size is set by the parent document only. They would be a lot more useful if we could write e.g. so the height of the iframe element is set by the abc.html document instead of the parent document.

You could do this with js in the child document, if its important to keep js out of the parent.

no, not if it is cross site URL.

Then you need a postMessage to send body size to parent frame which then needs to listen for messages and resize the iframe element.

Re: Why can't HTML alone do includes?

#302

Post by jefftk »

silvestrov wrote: post #301
jefftk wrote: post #95

Earlier quoted context omitted.

You could do this with js in the child document, if its important to keep js out of the parent.

no, not if it is cross site URL. Then you need a postMessage to send body size to parent frame which then needs to listen for messages and resize the iframe element.

Totally! I thought we were talking about the same site case.

Re: Why can't HTML alone do includes?

#303

Post by tln »

HeavyStorm wrote: post #125
tln wrote: post #7

There used to be a thing for this https://caniuse.com/imports

Says "superseded by ES modules". Not really the same thing, right?

The article asks about includes but also about imports ("HTML cannot import HTML ") which this is very directly.

This feature was billed as #includes for the web [1]. No, it acts nothing like an #include. TBH I don't see why ES modules are a "replacement" here.

Personally I would like to see something like these imports come back, as a way to reuse HTML structure across pages, BUT purely declaratively (no JS needed).

#includes where partially formed HTML (ie, header.html has a open tag and footer.html has the closing tag) isn't very DOM compatible.

[1] https://web.archive.org/web/20181121181125/https://www.html5...

Re: Why can't HTML alone do includes?

#306

Post by jraph »

immibis wrote: post #275
int_19h wrote: post #250

Earlier quoted context omitted.

Me personally, I didn't even care that much about strict semantic web, but XML has the benefits of the entire ecosystem around it (like XPath and XSLT), composable extensibility in form of namespaces etc. It was very frustrating to see all that thrown out with HTML5, and the reasoning never made any sense to me (backwards compatibility with pre-XHTML pages would be best handled by defining a spec according to which t…

If XHTML was literally just HTML but with XML syntax, it would be pretty cool.

isn't it what XHTML5 is, more or less?

Re: Why can't HTML alone do includes?

#307

Post by PaulHoule »

giantrobot wrote: post #193
crazygringo wrote: post #168

Earlier quoted context omitted.

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!

You needed to hit the reset button (and hoped it worked) and never the back button! Yes, I suffered through early SAP web apps built entirely with frames and HTML forms. It was terrible. I don't love JavaScript monstrosities but XHR and dynamic HTML were a vast improvement over HTML forms and frame/iframe abuse.

Really well written web form applications were a delight in 2001 and a large improvement over conventional applications written in Windows. It helped that application data was in a SQL database, with a schema, protected by transactions, etc as opposed to a tangle of pointers that would eventually go bad and crash the app -- I made very complicated forms for demographic profiling, scientific paper submission, application submission, document search, etc. If you did not use "session" variables for application state this could at worst cause a desynchronization between the browser and the server which (1) would get resynchronized at any load or reload and (2) never get the system into a "stuck" state from the user viewpoint and (3) never lose more than a screen full of work.

Try some other architecture though and all bets were off.

Amazon's web store looked and worked mostly the same as it does now, people were very impressed with MapQuest, etc.

Applications like that can feel really fast, almost desktop application fast, if you are running them on a powerful desktop computer and viewing them on another computer or tablet over a LAN

Re: Why can't HTML alone do includes?

#308

Post by lelanthran »

johnisgood wrote: post #295
HumanOstrich wrote: post #214

Earlier quoted context omitted.

Seems like overkill to bring in a framework just for inlining some static html. If that's all you're doing, a self-replacing script tag is neat: function includeHTML(url) { const s = document.currentScript fetch(url).then(r => r.text()).then(h => { s.insertAdjacentHTML('beforebegin', h) s.remove() }) } ... includeHTML('/footer.html') The `script` element is replaced with the html from `/footer.html`.

But this requires JavaScript...

> But this requires JavaScript...

Depending on the specific objection to Javascript, this may or may not matter:

1. You object to any/all JS on a page? Yeah, then this won't work for you.

2. You object to having to write JS just to get client-side includes? This should mostly work for you.

It all depends on what the actual objection is.

Re: Why can't HTML alone do includes?

#309

Post by ummonk »

DemocracyFTW2 wrote: post #248
ummonk wrote: post #228

Earlier quoted context omitted.

Images and videos are not semantic content. The alt attributes that describe them on the other hand are indeed semantic content.

> Images and videos are not semantic content Something in that tenet does not compute with me.

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.

Re: Why can't HTML alone do includes?

#310

Post by lelanthran »

dimal wrote: post #47
econ wrote: post #36

Earlier quoted context omitted.

You can message the page dimensions to the parent. To do it x domain you can load the same url into the parent with the height in the #location hash. It won't refresh that way.

I know it’s possible to work around it, but that’s not the point. This is such a common use case that it seems worthwhile to pave the cowpath. We’ve paved a lot of cowpaths that are far less trodden than this one. This is practically a cow superhighway. We’ve built an industry around solving this problem. What if, for some basic web publishing use cases, we could replace a complex web framework with one new tag?

> We’ve built an industry around solving this problem. What if, for some basic web publishing use cases, we could replace a complex web framework with one new tag?

I actually did that replacement, with a few enhancements (maybe 100 lines of code, total?). It's in arxiv pending at the moment. In about two days it will be done and I'll post a Show HN here.

Post reply on HN