311–320 of 367 posts
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.
I do it in a way that doesn't stop the renderer.
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…
In addition, we used XSLT quite a bit too. It is nice being able to open your XML data files in a web browser and having it nicely formatted without any external software. All you needed was a link to the style sheet.
I would have loved for there to be a json based format, or perhaps yaml, as an alternative to the xml- based stuff we have today.
"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…
It's "solved" only in the sense that you need to use a programming language on the server to "solve" it. If all you are doing is static pages, it's most definitely not solved.
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…
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.
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
Earlier quoted context omitted.
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
Yeah, that is just a crappier version of HTML Frames [1] 1 - https://en.m.wikipedia.org/wiki/Frame_(World_Wide_Web)
Some might argue react is over abstracted or over engineered to do the same.
Interpretation and preference is different than if it’s possible
Earlier quoted context omitted.
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.
The OP doesn’t need to hint.
The name of this feature is transclusion. https://en.wikipedia.org/wiki/Transclusion It was part of Project Xanadu, and originally considered to be an important feature of hypertext. Notably, mediawiki uses transclusion extensively. It sometimes feels like the wiki is the truest form of hypertext.
In Xanadu you could transclude just an excerpt from one document into another document.
If you wanted to do this with HTML you need an answer for the CSS. In any particular case you can solve it, making judgements about which attributes should be consistent between the host document, the guest document and the guest-embedded-in-host. The general case, however, is unclear.
For a straightforward tag the guest document is engineered to live inside the CSS environment (descendant of the 3rd div child of a p that has class ".rodney") that the host puts it in.
Another straightforward answer is the Shadow DOM which, for the most part, lets the guest style itself without affecting the rest of the document. I think in that case the host can still put some styles in to patch the guest.
Earlier quoted context omitted.
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.
Sound like it's good enough for headers and footers, which is 80% of what people need.
I’d probably explore WebComponents, but wanting the height of JavaScript without JavaScript..