[whatwg] Client-side includes proposal

[Bill Wallace]

It is only expensive if the client needs to do the client side include each
time - however, if the page re-uses parts all the time, then parts of the
page can be cached either in a proxy or directly client side, and that can
make it faster as well as reducing server load.
Consider including 3-4 components:

<include src="static-header" />
<include src="user-specific-data" />
<include src="dynamic-daily-content" />

This type of page needs to be read at least a couple of times for each
client for it to be faster, but there are lots of clients like that.

HOWEVER - how about just using the xlink design and making it part of the
html standard (allowing HTML fragments to be included, not just XML).  That
has client side includes, and also supports client side replacement of
components based on clicking a URL/button/object.  Supporting xlink in html
consistently would allow most of the current JavaScript based applications
to be replaced with JavaScript free applications, and that would make many
of them much safer, and is reasonably efficient.

2008/8/18 Martin Ellis <martin at betgenius.com>

> I can't speak for non Windows/Linux users, but for windows users IIS
> comes supplied and supports SSI, asp.net php (via a download) etc and
> with linux you can download apache and a sluth of other http daemons, I
> see no reason for any html page to require the client to do the inline
> including of content, as stated previously in this thread the tcp
> overhead is huge and this would only make it worse in my opinion.
>
> M
>
> -----Original Message-----
> From: whatwg-bounces at lists.whatwg.org
> [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Shannon
> Sent: 18 August 2008 18:57
> To: Kristof Zelechovski
> Cc: 'WHAT working group'
> Subject: Re: [whatwg] Client-side includes proposal
>
> Kristof Zelechovski wrote:
> > Client-side includes make a document transformation, something which
> > logically belongs XSLT rather than HTML.  And what would the
> workaround for
> > legacy browsers be?
> > Chris
> >
>
> You make good points but last I checked general browser and editor
> support for XSLT was abysmal. Everyone is saying its on their "roadmaps"
>
> though so maybe it will one day be reliable enough to use.
>
> You could go:
>
> <include src="banner.ihtml">
>    <h1>Banner</h1>
> </include>
>
> But this just seems wasteful, pointless and open to abuse. I think a
> better workaround is that people with legacy browsers download each
> include file seperately and paste them together in DOS or AmigaOS or
> whatever system it is that keeps them from installing a modern browser.
>
> Of course XSLT has the same legacy issues as do many parts of HTML5. I
> know the reasoning but at some point the web will have to leave
> unmaintained software behind or face the same grim reality OpenGL is
> facing now (can't move forward because a minority want legacy support
> for 10 year old CAD applications, can't go back because competing
> protocols are in front on features).
>
> I'd like to see the option made available and its use determined by the
> market as we have always done. If a developer wants to piss-off users by
>
> writing a Flash or Silverlight-only website then the ONLY thing we can
> do is provide an equivalent feature and hope that it does less harm (by
> virtue of being a truly open standard). The average web developer's
> mentally is very different from the majority of this list, they won't
> compromise to do the "right thing". If I can do client-side includes in
> Flash and Silverlight (and I can) then why should HTML be left behind?
>
> Anyway, I don't mean for an open discussion on this as I'm sure it's
> been debated endlessly. I'm just stating my case for going ahead with
> this feature.
>
> Shannon
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080818/dc316554/attachment-0001.htm>