just on point at all why includ this stuff to load more at once... the hole web stuff works since cgi implementations at web services on asyncronity to load just what u actually need... like now most of them are fetch or xhr calls... I mean it makes just sence for onepager to keep the markup a bit more structured... but why u want to make static rendered homepages those days?
Why can't HTML alone do includes?
241–250 of 367 posts
Re: Why can't HTML alone do includes?
#242at all ...why includ this stuff to load more at once... the hole web stuff works since cgi implementations at web services on asyncronity to load just what u actually need... like now most of them are fetch or xhr calls... I mean it makes just sence for onepager to keep the markup a bit more structured... but why u want to make static rendered homepages those days?
Re: Why can't HTML alone do includes?
#243Earlier quoted context omitted.
I mean in 1996s netscape you could do this (I run the server for a website that still uses this): The thing that always bugged me about frames is that they are too clever. I don't want to reload only the frame html when I rightclick and reload. Sure the idea was to cache those separately, but come on — frames and caching are meant to solve two different problems and by munching them together they somewhat sucked at s…
Nitpick: the HTML4 spec was released in December 1997, and HTML4.01 only in December 1999 so it probably wouldn't have run in 1996s Netscape.
The doctype doesn’t matter in this context. Netscape Navigator 2 supported frames in 1995 and would render that page.
Re: Why can't HTML alone do includes?
#244This was the rabbit hole that I started down in the late 90s and still haven’t come out of. I was the webmaster of the Analog Science Fiction website and I was building tons of static pages, each with the same header and side bar. It drove me nuts. So I did some research and found out about Apache server side includes. Woo hoo! Keeping it DRY (before I knew DRY was a thing). Yeah, we’ve been solving this over and ove…
> Why not have a simple client side method for this? Like writing a line of js?
The difference between "a line of JS" and a standardized declarative solution is of course that a meek "line of $turing_complete_language" can not, in the general case, be known and trusted to do what it purports to do, and nothing else; you've basically enabled any kind of computation, and any kind of behavior. With an include tag or attribute that's different; it's behavior is described by standards, and (except for knowing what content we might be pulling in) we can 100% tell the effects from static analysis, that is, without executing the code. With "a line of JS" the only way, in the general case, to know what it does is to run it (an infinite number of times). Also, because it's not standardized, it's much harder to save to disk, to index and to archive it.
Re: Why can't HTML alone do includes?
#245Earlier quoted context omitted.
I mean in 1996s netscape you could do this (I run the server for a website that still uses this): The thing that always bugged me about frames is that they are too clever. I don't want to reload only the frame html when I rightclick and reload. Sure the idea was to cache those separately, but come on — frames and caching are meant to solve two different problems and by munching them together they somewhat sucked at s…
Nitpick: the HTML4 spec was released in December 1997, and HTML4.01 only in December 1999 so it probably wouldn't have run in 1996s Netscape.
Back then it was common for Netscape to have features that (years) later became standard HTML.
Re: Why can't HTML alone do includes?
#246My guess: no-one needs it. Originally, iframe were the solution, like the posts mentions. By the time iframes became unfashionable, nobody was writing HTML with their bare hands anymore. Since then, people use a myriad of other tools and, as also mentioned, they all have a way to fix this. So the only group who would benefit from a better iframe is the group of people who don't use any tools and write their HTML with…
No, originally frameset[0] and frame[1] were the solution to this problem. I remember building a website in the late 1990s with frameset. iframe came later, and basically allowed you to do frames without the frameset. Anyway, frameset is also the reason every browser's user agent starts with "Mozilla". [0] https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... [1] https://developer.mozilla.org/en-US/docs/Web…
Originally my footers and navbars were included with server side includes
Re: Why can't HTML alone do includes?
#247The 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…
Maybe something that adds to this low demand is that:
1. Web pages that are developed from the viewpoint of the user having JS, makes it trivial to implement something that provides the same results.
2. Web pages that are developed for user agents that don't run js, probably want to have some interaction, so already have a server runtime that can provide this feature.
2b. And if it doesn't have any user interaction, its probably a static content site, and nobody is writing content in HTML, so there already is a build step that provides this feature.
Re: Why can't HTML alone do includes?
#248Earlier quoted context omitted.
Images are content. Videos are content. Objects/iframes are content. The only one that is presentational is stylesheets.
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.
Re: Why can't HTML alone do includes?
#249HTML 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.
We also had a brief detour into XML with XHTML, and XML has XInclude, although it's not a required feature.
The XML subset of SGML still includes most forms of entity usage SGML has, including external general entities as described by grandparent. XInclude can include any fragment not just a complete document, but apart from that was redundant, and what remains of XInclude in HTML today () doesnt't make use of fragments and also does away with the xinclude and other namespaces. For reusing fragments OTOH, SVG has the more specific construct. XInclude also really worked bad in the presence of XML Schema.
Re: Why can't HTML alone do includes?
#250Earlier 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…
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 they should be converted to XHTML).