XInclude is not intended to be used in HTML, but rather in XML and I actually found it useful when dealing with XML on the server side, and one time including data into a NAnt script :)

If the browser supports XHtml I can’t see why it should not also support XInclude since it comes from the same family. There seems to be some support in IE7, and I guess thats because of the XSL-support in that browser.

Well, that’s my two cents anyway.

Using PHP or ASP only requires one additional line of code to include another page such as a header or footer. You don’t have to master an entire programming language at all.

It definitely worked in IE5.5 and IE6, although it looked ugly as heck.

I’m surprised you and Alon are talking about how it messes up Google. I had always understood that the page was served whole – the browsing agent wouldn’t be aware that some of the code was sent by SSI include. Google would just see the final page, as your browser would, with the included code, erm, included with all the rest of the code.

Why do I think it works better to use SSI?

* Neatness – because SSI drops a page fragment into the document flow, you can style it seamlessly with the rest of the page. Object elements have to have the size specified, which often results in scrollbars and ugly borders.

* Capability – SSI allows you to insert any document fragment, it doesn’t have to be a stand-alone object or set of elements, it could end mid-element if that serves your needs better! Object elements don’t give you that flexibility.

* Search resilient – because the included fragment is only ever served as part of the parent page, search engines treat it as though it was part of that page. With object elements, you have the risk that spiders won’t read or index pages/fragments linked through the object element, won’t treat them as part of the main page (for ranking and context purposes), and will return them as results in their own right, which means that surfers can be directed to a fragment page that probably doesn’t answer their question and may not work as a self-contained page.

* Accessibility – because SSI is all done server-side, all the user agent sees is the completed page, so if your coding is up to scratch, it’s accessible straight away. Object elements are not supported by all user agents – some old browsers and, I suspect, mobile phones and assistive technologies, don’t read object elements, so you have to include alternative content and remember to change it as needed, which is a headache to maintain, and adds to the bytes transferred. There is also the worry that, even if the user agent does render the object elements, features such as tabbing to links and fields may not work as intended or in the correct order.

From reading the [iframe seamless] bit on HTML5, it sounds like they are just reinventing what we’ve already got with SSI, but relying on user agents to treat the included content in the manner specified (do we really want to do that?), whereas with SSI it is guaranteed. The only advantage I can see to using any form of [object] or [iframe] element is to allow cacheing of the included file, but is that really all that important these days?

“Everything else works better”: I don’t agree with that (especially not neatness), and I’ve given my arguments “pro seemless” in the article.

But even without that it could be immensely useful for prototyping things, or why not an intranet? Things that won’t necessarily need to be crawled.

I stopped using [object] when I got my head round SSI, which is a much more effective way of achieving the end result. OK, so it doesn’t allow cacheing, but everything else works better – it looks neater, fewer HTTP requests, fewer bytes if the user only looks at one page, easier to maintain, and solves the problem of search engines calling up the object data page as a stand-alone.

No decent web developer writes HTML without includes or variables anyway, so to make it a part of the spec only seems reasonable to me.