<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Ian Hickson wrote:
<blockquote
cite="mid:Pine.LNX.4.62.0808180729210.9667@hixie.dreamhostps.com"
type="cite">
<pre wrap="">On Mon, 18 Aug 2008, Shannon wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
What advantage does this have over server-side includes?
The <iframe doc="" seamless> idea has the advantage of not blocking
rendering, which a client-side parsing-level include would. I don't really
see what the advantage of a client-side parsing-level include would be.
</pre>
</blockquote>
Cost. SSI of any description generally puts you on a "business" hosting
plan with a cost increase of up to 10x. Client-side includes only
require static page serving which can also be beneficial where the
server is a device (like a router interface).<br>
<br>
Availability. As far as I can tell SSI is only available on Apache and
later versions of IIS. This may be a market majority but when you
consider the number of devices and "home servers" coming onto the
market with basic web interfaces the actual availability of SSI may be
lower than you'd expect.<br>
<br>
Security. Availability is reduced even further by ISP and organisations
that flat-out refuse to support SSI due to security and support
concerns.<br>
<br>
Reuse. SSI follows no agreed set of rules and therefore may require
code changes when changing hosting provider. Some systems provide
extensions that authors may assume is part of a standard, but aren't.
We have an opportunity to define a simpler and more reliable interface
that is independant of any server configuration.<br>
<br>
Speed. Concerns about speed are generally only valid for the first page
on the first visit to a site. Subsequent pages can be much faster than
SSI and even static html since common banners and footers can be cached
seperately - requiring only a unique content download. This is less
trivial than it sounds since global drop-down menus, ad frames,
tracking code, overlays and embedded JS and CSS often account for a
vast majority of the source code.<br>
<br>
Flexibility. It's hard to tell because the seamless proposal is vague
but from what I can tell there are a lot of things a "seamless" iframe
is not seamless about. For instance can absolutely positioned items be
positioned relative to the enclosing document? Do child and adjacent
selectors work across the iframe boundary? Will IE give up its
behaviour of placing iframes above the document regardless of z-index?
Includes don't have any of these issues because they are treated as
part of the document, not as a special case.<br>
<br>
Even with these advantages I do not believe it is an either/or case.
"seamless" iframes serve a purpose too and I do not want to see them
dropped from the spec. I would however like to see more clarity in the
spec as to how they interact with scripts and styles (especially
adjacency selectors) in the master document and neighbouring seamless
frames.<br>
<br>
<blockquote
cite="mid:Pine.LNX.4.62.0808180729210.9667@hixie.dreamhostps.com"
type="cite">HTTP 1.1 pipelining should remove any performance concerns
that includes <br>
<blockquote type="cite">
<pre wrap="">would have over traditional SSI since the retrieval process only
requires the sending of a few more bytes of request and response
headers.
</pre>
</blockquote>
<pre wrap=""><!---->
A TCP round-trip is very expensive. A client-side parsing-level include
would mean that the parser would have to stop while a complete round-trip
is performed. There's really no way to get around that short of making it
a higher-level construct like <iframe seamless>.
</pre>
</blockquote>
There is actually an easy solution for this, though it is less flexible
than my original proposal. The solution is to require each include to
be balanced (equal number of open and close tags) so the surrounding
block is guaranteed to be a single node. Anything left open is
forcefully closed (as when reaching </body> with open blocks). In
other words:<br>
<br>
<div id="content" style="min-height:500px"><br>
<include src="content.ihtml"><br>
</div><!-- always closes content --><br>
<br>
Since we know "content" is a closed block we can draw in a transparent
placeholder and continue rendering the outer document as we do with
img, video, iframes and embed. Once the true dimensions are known the
renderer can repaint as it does with table cells and other "auto"
sizing. This will often improve the readability of documents on slower
connections since the top third of source code is usually concerned
with banners, menus, search-bars and other cruft not directly relevant
to the content the user wants to view and this is exactly the stuff you
would want to put in an include to begin with. If it renders last then
all the better.<br>
<br>
Shannon<br>
</body>
</html>