W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2012

Re: [whatwg] Including

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 14 Nov 2012 00:09:18 +0000 (UTC)
To: Mark Nottingham <mnot@mnot.net>
Message-ID: <Pine.LNX.4.64.1211140004060.15000@ps20323.dreamhostps.com>
Cc: whatwg@whatwg.org
On Wed, 14 Nov 2012, Mark Nottingham wrote:
> On 14/11/2012, at 4:37 AM, Ian Hickson <ian@hixie.ch> wrote:
> > On Tue, 13 Nov 2012, Mark Nottingham wrote:
> > 
> > (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)?

No, it doesn't reliably work in today's browsers, even.


> >> 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).

If it's intended to be implemented by user agents, then it should just be 
part of HTML (either specced in the HTML spec, or a separate spec, e.g. 
the way that the HTML Editing APIs are specified in a separate spec). No 
need for prefixes or anything.


> 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.

If it's only intended for scripts in the page, then data-* attributes are 
the intended framework for the solution.


> 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.

If it's not exposed to the client, then it should just be a language on 
top of HTML, like PHP or SSIs, which is irrelevant to HTML clients.


> >> 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.

If it works, then I'd just leave it.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 14 November 2012 00:32:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:11 GMT