On 14/11/2012, at 4:37 AM, Ian Hickson <i...@hixie.ch> wrote: > On Tue, 13 Nov 2012, Mark Nottingham wrote: >> >> I've maintained a little library for a while that does inclusion: >> https://github.com/mnot/hinclude >> http://mnot.github.com/hinclude/ >> >> It's used in a few different places, and is now part of Symfony >> <http://symfony.com>, apparently. >> >> Besides the obvious issue of "should HTML5 have an inclusion tag?", >> something else has come up. > > (For what it's worth, inclusion in HTML is done using <iframe seamless>.)
Ah. Does that work with older browsers (from the 2005 era onwards)? >> This was pretty widely tested to be interoperable way back, but AIUI >> that option is going away (whatever that means) in HTML5. > > Nothing is changing in terms of how it is to be interpreted by browsers. Ack; thx. > It's definitely not a recommended syntax, though, as it results in such > divergent DOMs depending on whether it's used in HTML or XML. I see. > (Another dodgy part of this feature, from a conformance perspective, is > the include files themselves. They seem to be in a proprietary format > derived from HTML, not HTML, which has all kinds of implications on where > hinclude can be used and where it can't and what would happen with > handling any errors in the includes, and so forth. Also, the script > completely ignores the Content-Type of these files.) Yes. >> It's been suggested <https://github.com/mnot/hinclude/issues/13> that a >> data-* attribute on div could be used here, but reading the description >> there, I'm not so sure: >> >> "[T]hese attributes are intended for use by the site's own scripts, and >> are not a generic extension mechanism for publicly-usable metadata." >> >> <http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#embedding-custom-non-visible-data-with-the-data-*-attributes> >> >> hinclude is intended to be visible to software beyond the site's own >> scripts. > > What else is it intended to be used by? Mumble. The intent was that browsers would be able to process it directly without the JS, and that (for example) search engine spiders would be able to recognise and process it (since it's uniquely identified by the namespace). However, that was in ~2005; now, it's obvious that JS is pretty much required for browsing, and search engines just use a headless browser. Some people might also want to process it server-side or in intermediaries (a la ESI - <http://en.wikipedia.org/wiki/Edge_Side_Includes>), which is used surprisingly often. >> So, what's the appropriate thing to do here? Keep on using hx:include >> (after all, it works)? use data-include or similar? Or? > > Appropriate in what sense? Well, it works now, so I'm happy to leave it as is. However, if there were an argument to move to a different syntax that improved interoperability / forward compatibility, I'd probably add a mode where it worked that way too. Cheers, -- Mark Nottingham http://www.mnot.net/
