I desperately want to back to crafting sites by hand and not reach for react/vue as a default. I do a lot of static and tempory sites that do very little
Astro is all the goodness of components but for static sites.
Why can't HTML alone do includes?
191–200 of 367 posts
Re: Why can't HTML alone do includes?
#192Earlier 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.
True for any server side solution, yes.
On the other hand it means less work for the client, which is a pretty big deal on mobile.
Re: Why can't HTML alone do includes?
#193Earlier quoted context omitted.
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…
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.
Re: Why can't HTML alone do includes?
#194Earlier quoted context omitted.
> 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.
XSLT solved this problem. But it had poor tool support (DreamWeaver etc) and a bunch of anti-XML sentiment I assume as blowback from capital-E Enterprise stacks going insane with XML for everything. XSLT did exactly what HTML includes could do and more. The user agent could cache stylesheets or if it wanted override a linked stylesheet (like with CSS) and transform the raw data any way it wanted.
The Umbraco CMS was amazing during the time that it used and supported XSLT.
While it evaluated the xslt serverside it was a really neat and simple approach.
Re: Why can't HTML alone do includes?
#195Earlier quoted context omitted.
Why would the performance be any better with another tag?
A frame is a separate rendering context—it's (almost) as heavyweight as a new tab. The author wants to insert content from another file directly into the existing DOM, merging the two documents completely.
Negligible twenty years ago. But yes, if there's an improvement it should be merged automatically into the same document.
Re: Why can't HTML alone do includes?
#196This has always worked for me. Pretty much the ask? https://gist.github.com/sreekotay/08f9dfcd7553abb8f1bb17375d...
That's the first thing listed in the article? "Javascript to go fetch the HTML and insert it". What they're after is something that's _just_ HTML and not another language.
The tag appears to include/embed other html pages.
An embedded HTML page:
Re: Why can't HTML alone do includes?
#197HTML 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.
Neat reference, going to look into that.
The tag appears to include/embed other html pages.
An embedded HTML page:
Re: Why can't HTML alone do includes?
#198Earlier quoted context omitted.
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.
Images are content. Videos are content. Objects/iframes are content. The only one that is presentational is stylesheets.
Which (as I'm sure you know), also literally has 'content' :)
Re: Why can't HTML alone do includes?
#199Earlier quoted context omitted.
> 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.
I understand your point, but I still think it is bad from the point of view of language paradigms[1]. Iframes should have not been created in the first place.. You are changing the purpose of the language while it was not made for it. (yes in my view I interpret includes as a basic procedure) [1] http://www.info.ucl.ac.be/people/PVR/paradigmsDIAGRAMeng201....
There is nothing procedural about includes. In fact, it first appeared before HTML even became popular in Xanadu, called transclusion:
Re: Why can't HTML alone do includes?
#200Earlier quoted context omitted.
My main gripe is a decade(s?) old Firefox bug related to rendering an HTML string to the DOM. That may be a fairly specific use case though, and largely it still works great today. I've done a few side projects with XSLT and web components for interactivity, worked great.
What bug specifically?
Couldn't find a good link earlier, guess I didn't have quite the right keywords for search.
Here we go, looks like its 17 years old now: