The discussion on seamless iframes reminded me of something I've felt
was missing from HTML - an equivalent client functionality to
server-side includes as provided by PHP, Coldfusion and SSI. In
server-side includes the document generated from parts appears as a
single entity rather than nested frames. In other words the source code
seen by the UA is indistiguishable from a non-frames HTML page in every way.
iframes are good for some things but they can be really messy when
you're trying to build a single seamless page with shared styles and
scripts from multiple files. It makes code reuse a real pain without
relying on a server-side dynamic language. The seamless iframes proposal
doesn't really address this well because you'll have more than one HTML
and BODY element causing strange behaviour or complex exceptions with
seamless CSS.
The other issue with iframes is that for many page snippets the concept
of a title, meta tags and other headers don't make sense or simply
repeat what was in the main document. More often than not the <head>
section is meaningless yet must still be included for the frame to be
"well-formed" or indexed by spiders.
The proposal would work like this:
--- Master Document ---
<html>
<head>
<title>Include Example</title>
<meta name="includes" content="allow">
<include src="global_head.ihtml">
</head>
<body>
<include src="header.ihtml">
<include src="http://www.pagelets.com/foo.ihtml";>
<include src="footer.ihtml">
</body>
</html>
--- Header.html ---
<div id="header">
<h1>Header</h1>
</div>
With this proposal seamless CSS would work perfectly because child
selectors won't see an intervening <body> element between sections.
Includes should allow any html segments except the initial <doctype> and
<head> (for reasons explained below) and should allow start and end tags
to be split across includes. Only tags themselves may not contain an
include (eg, <body <include src="body_attributes.ihtml">>). Many
server-side includes allow this but it breaks the syntax of HTML/XML.
Includes must respect their own HTTP headers but inherit all other
properties, styles and scripts from the surrounding page. If an include
is not set to expire immediately the browser should reuse it from
memory, otherwise it should retreive it once for each include. Each
behaviour has its own merits depending on the application.
The standard would recommend (but not require) includes to use an .ihtml
extension. This will make it easier for authors, UAs and logging systems
to distinguish partial and complete pages (ie, not count includes
towards page views in a stats package).
UAs or UA extensions like the Mozilla-based "Web Developer" should allow
the user to view the actual source and the "final" source (with all
includes substituted).
HTTP 1.1 pipelining should remove any performance concerns that includes
would have over traditional SSI since the retrieval process only
requires the sending of a few more bytes of request and response
headers. In some ways it is actually better because UAs and proxies can
cache the static includes and only fetch the dynamic parts.
The only real issue with this proposal is security for untrusted content
like myspace profiles. Traditional sanitisers would be unfamiliar with
<include> and may allow it through, providing a backdoor for malicious
code. For this reason it is necessary that includes be opt-in. The
simplest mechanism is to use a meta tag in the head of the master document:
<meta name="includes" content="allow">
I would consider any content system that allowed untrusted users to
write their own head tags to be incurable insecure; however this
requirement should ensure that the majority do not suddenly experience a
wave of new exploits in HTML5 browsers.
Shannon
