Chris is an absolute legend in this space and I’m so glad he’s bringing this up. I feel like he might actually have pull here and start good discussions that might have actual solutions.
Why can't HTML alone do includes?
221–230 of 367 posts
Re: Why can't HTML alone do includes?
#222Earlier 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…
I kinda agree with you but I'd argue the "death" of microformats is unrelated to the death of XHTML (tho schema.org is still around).
You could still use e.g. hReview today, but nobody does. In the end the problem of microformats was that "I want my content to be used outside my web property" is something nobody wants, beyond search engines that are supposed to drive traffic to you.
The fediverse is the only chance of reviving that concept because it basically keeps attribution around.
Re: Why can't HTML alone do includes?
#223Earlier 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.
Compression Dictionary Transport [0] seems like something that can potentially address this. If you squint, this looks almost like XSLT.
[0] https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Com...
Re: Why can't HTML alone do includes?
#224This 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…
> Woo hoo! Keeping it DRY (before I knew DRY was a thing)
I still remember the script I wrote to replace thousands (literally) slightly different headers and footers in some large websites of the 90s. How liberating to finally have that.
Re: Why can't HTML alone do includes?
#225This 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?
A block of in-line JavaScript stops the renderer until it runs because its output cannot be determined before it completes.
Re: Why can't HTML alone do includes?
#226Earlier 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…
I don't think there was ever a sustainable route to a semantic web that would work for the masses.
People wanted to write and publish. Only a small portion of people/institutions would have had the resources or appetite to tag factual information on their pages. Most people would have ignored the semantic taxonomies (or just wouldn't have published at all). I guess a small and insular semantic web is better than no semantic web, but I doubt there was a scenario where the web would have been as rich as it actually became, but was also rigidly organized.
Re: Why can't HTML alone do includes?
#227HTML 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: https://www.w3schools.com/tags/tag_object.asp
used like this is just a poor iframe in a much shakier spot in the standards, mostly for backwards compatibility.
Like iframe, it "includes" a full subdocument as a block element, which isn't quite what the OP is hinting at.
Re: Why can't HTML alone do includes?
#228Earlier 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.
Images and videos are not semantic content. The alt attributes that describe them on the other hand are indeed semantic content.
Re: Why can't HTML alone do includes?
#229The 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…
JS-first developers want something that works the same way client-side and server-side, and the mainstream front-end dev community shifted to JS-first, for better or worse
Re: Why can't HTML alone do includes?
#230Earlier 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 thing I liked the most about XHTML was how it enforced strict notation.
Elements had to be used in their pure form, and CSS was for all visual presentation.
It really helped me understand and be better at web development - getting the tick from the XHTML validator was always an achievement for complicated webpages.