W3C home > Mailing lists > Public > www-html@w3.org > September 2003

client side includes/everything a link

From: Jewett, Jim J <jim.jewett@eds.com>
Date: Mon, 15 Sep 2003 10:31:55 -0400
Message-ID: <B8CDFB11BB44D411B8E600508BDF076C1A745A6D@usahm010.exmi01.exch.eds.com>
To: www-html@w3.org
Cc: "'david@dorward.me.uk'" <david@dorward.me.uk>

Hills Capital Management 1.800.474.1532 asked for a src
attribute on DIV. 

Dave Dorward asked:

> Why do you need to? The data could be included on the
> page as normal, and then manipulated using scripting.
 
On many pages, a majority of the text is boilerplate or 
navigation.  If I'm reading a dozen pages at the same site, 
the boilerpate doesn't change at all, and the navigation
doesn't change by much - but I still have to download it
a dozen times.

When I'm reading from a high-speed desktop, this isn't
such a big deal.  When I'm reading over a very old modem,
it is.  When I'm reading on my PDA, I would prefer to 
leave the navigation on a separate page, so that I won't
have to scroll through it before I get to the real content.

The only downsides I see are:

(1)  The content may be spread out over several files,
which can be a problem if I try to save it, or even to
find it again.  

This is already a problem with Server Side Includes,
and a huge annoyance with frames - so at least 
nothing gets worse.

(2)  If a DIV has both src and content, which should
display/how should they be combined?  

My inclination would be to say that the src replaces 
the content, which starts to look an awful lot like an 
object.  An object would also allow parameters.  With 
an included xhtml object, the author could use a
common navigation file, but still set the breadcrumb 
trail/expansion state separately for each parent page.

-jJ
Received on Monday, 15 September 2003 10:32:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:15:58 GMT