Live data from Hacker News

Why can't HTML alone do includes?

frontendmasters.com

361–367 of 367 posts

Re: Why can't HTML alone do includes?

#361
post #196

Earlier quoted context omitted.

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: https://www.w3schools.com/tags/tag_object.asp

hunh - THAT's cool. Learn something new every day.

That said - it does appear encapsulated, much like an iframe - css doesn't take, etc. so though more "pure" HTML I'd argue doesn't fulfill the spirit of "include"?

Re: Why can't HTML alone do includes?

#362
post #313

Kind of serious question. Do we have any alternatives to html? If not, why? It’s essentially all html. Yes, browser will render svg/pdf/md and so on, but as far as I can tell, it’s not what I consider "real web" (links to other documents, support for styling, shared resources, scripting, and so on ). I would have loved for there to be a json based format, or perhaps yaml, as an alternative to the xml- based stuff we…

>links to other documents, support for styling, shared resources, scripting, and so on

SVG supports all those things. SVG's use element can do exactly what the OP is talking about. You can put HTML in SVG and SVG in HTML. SVG is just markup exactly like HTML. SVG supports JavaScript and stylesheets. SVG can put text on a curve and other stylish things that boring boxy HTML cannot accomplish.

https://www.w3.org/2002/Talks/www2002-svgtut-ih/hwtut.pdf

Read it. Ch 11 shows you how use can import chunks of other SVG. Ch 12 is JavaScript. You can inline it in your html and style it with CSS just like any of the other tags in html. Once you know SVG, you can hand generate more compact images than anything created by something like Inkscape which just uses path elements for everything. For example, you can do a UPC barcode with a single SVG line element using a wide stroke and a stroke-dasharray. See chapter 8.

Re: Why can't HTML alone do includes?

#364
post #89

Earlier quoted context omitted.

I couldn't agree more.

https://www.w3.org/TR/xhtml2/introduction.html > XHTML 2 takes a completely different approach, by taking the premise that all images have a long description and treating the image and the text as equivalents. In XHTML 2 any element may have a @src attribute, which specifies a resource (such as an image) to load instead of the element.

The content of the div can be used to support legacy browsers. It can have a link, iframe, a message or an outdated version of the content/menu/header/footer etc

Re: Why can't HTML alone do includes?

#365
post #47

Earlier quoted context omitted.

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.

Taps foot....

Re: Why can't HTML alone do includes?

#366

Earlier quoted context omitted.

I'm as big a critic of Google as anyone, but I'm always surprised at modern day takes around the lost semantic web technologies - they are missing facts or jumping to conclusions in hindsight. Here's what people should know. 1) The failure of XHTML was very much a multi-vendor, industry-wide affair; the problem was that the syntax of XML was stricter than the syntax of HTML, and the web was already littered with brok…

I remember just using PHP sessions back then on a XHTML document produced parse errors. Because PHP added the session to the query strings of links and used the raw & character instead of & for separating params in the query string. Thus causing a XML parse error. There was a push to prevent browsers to be too lenient with the syntax in order to avoid the problem that sloppy HTML produced (inconsistent rendering…

It's not that there was a push for the browsers to be lenient - I worked on a browser team. We didn't want the leniency. We hated it. We wanted a strict parser. I was a pro XHTML guy - I was eventually argued into submission with a very simple and great point: "If we can't parse the whole Web and our competitors can, people will stop using us."

Like, there was no choice in the matter - it was give the market what it wants, or die. Any "push" came from observing user needs and how many people we'd break and drive away with strictness.

Competition mandated compatibility. Engineers might want purity, but users don't want a browser that barfs on malformed pages. Remember that one of HTML's basic principles was to be more lax about syntax than XML. The Web had committed to being syntax-relaxed from day 1. Not caring about markup correctness helped the Web win.

It took me a while to see why it had to be this way, but I was eventually convinced, XHTML would have departed from both what the Web was designed to be and what users wanted it to be.

Re: Why can't HTML alone do includes?

#367
post #171
post #137

You can get JS-free, client-side include functionality if you're willing to wrap your HTML in XML. Here is a demo: https://github.com/Evidlo/xsl-website

That's interesting, thanks. How well supported is XSLT in modern browsers? What would be the drawbacks of using this approach for a modern website?

Its fully supported in every current browser. Some things that suck are that XML is stricter than HTML and every XML needs to include the templates file at the first line
Post reply on HN