RE: client side includes

>MM writes:
>
>Not one meaningful arguement[sic] that has been put forth for
client side includes seems to have
>any reason other than to accomodate[sic] lazy developers or lame
server configurations at the
>expense of all the existing UAs and the users that paid for
them.

Here's a good reason: Dynamic HTML. SSI is static... once the
page is loaded, SSI can't do anything more to change the page.
With CSI, you can make the page fully dynamic.

Suppose you set your site up with DIV containers for your layout
(not a tables or frames layout). You only use tables for actual
tabular data, as per the W3C specification.

How does one fetch external data (data that is within the domain
of the website in question, but is not embedded or included in
the web page in question.) into those DIV containers to create
DHTML effects? In a Frames layout, it's easy, you change the SRC
attribute of a frame. In Tables, it's easy, too. But with DIV's,
you can't do it. DIV's don't have a SRC attribute (which I think
would be the easiest method of implementing CSI (Client Side
Includes)... giving DIV's a SRC attribute).

So, web developers have resorted to either reading external HTML
files into a javascript array, then writing that into the DIV; or
by using the iFrame buffer trick (reading a file into a hidden
iFrame, then copying the iFrame contents using either innerHTML
or a deep CloneNode.) That's clunky, unreliable, and a real pain
to get to work cross browser.

If DIV's had a SRC attribute, you could easily use javascript (or
possibly even CSS) to change that SRC attribute. It would be a
simple one-line bit of code that could be melded into the
traditional 'a href=' link with the onclick event. This would
allow search engines / screen readers / text-only browsers to
follow the 'a href=' part to the actual HTML file that is to be
requested, while compatible UA's would simply change the DIV SRC,
the DIV would fetch the external HTML file, and display it.
Imagine the flexibility that one could have by doing this with
nested DIV's.

The other advantages:
it would work with traditional HTML (versus XML, XHTML, etc),
which is what the majority of web pages are still programmed in.

It would only require an upgrade or patch to existing browsers to
get them to work (people upgrade and patch their browsers all the
time to fix security leaks, why not for functionality
fixes/upgrades?).

It allows for accessibility (screen readers/text-only browsers
will follow the 'a href=' portion of a properly built link).

It allows for search engine indexing (SE Bots would follow the 'a
href=' in the link.)

Older browsers that support DIV's can be patched, as well, to
give them DIV SRC functionality. (Although I support the Browser
Upgrade Initiative myself, and don't support any browsers that
don't support at least DOM1 (and I'm not in the minority here...
a growing number of webmasters are moving away from supporting
older browsers because it's too much headache for such a small
number of users). Sometimes, to move ahead, you have to leave
something behind. I choose to leave behind the small minority of
users who, for whatever reason, choose not to partake of free
upgrades to free browsers.) Note that I DO fully support
accessibility initiatives, which is why I built our site using
DIV containers in the first place, rather than Frames or Tables.


We're using the iFrame buffer trick on our website right now, and
it's been the biggest source of problems in regards to getting
the code to work cross-browser (NS just doesn't seem to want to
play). I've wished and hoped for a long time that the W3C would
give us some way of allowing DIV's to update their content from
external data. I believe that by implementing a DIV SRC
attribute, it would open up a whole new era of DHTML
functionality on the internet. As for security concerns, it would
be a simple matter to constrain the DIV SRC attribute so that it
can only load external data from the same domain that the DIV
originated from.

Every webmaster that I've spoken to so far concerning our site
has expressed interest in using DHTML inside a modern DIV layout
site, but has balked at the prospect of writing complicated
cross-browser compatible code to implement either the javascript
array solution or the hidden iFrame solution. By not allowing
external data to be easily fetched into web pages using DIV
containers as its layout (vs. tables or frames), you force web
developers to continue using frames or tables to get the effect
they desire, which holds back advancements in internet
utilization.

Please, give us a SRC attribute for the DIV container! Give us
CSI!


Darren Brothers
Registered Futures Specialist

Hills Capital Management
171 Devonshire Way
San Francisco, CA 94131

800.474.1532 Tel (Toll-Free)
415.759.1532 Tel
415.759.7650 Tel
415.759.1519 Fax

DBrothers@HillsCapital.com
Info@HillsCapital.com

http://www.HillsCapital.com/