Frames and a navigation bar & CSS

Discussion in 'HTML' started by Spacen Jasset, Jul 22, 2004.

  1. One of the reasons that frames were inveted is to enable a navigation bar -
    that is - the main page content changes whereas naviagtion information
    remains static and is not dupicated into every html file.

    So why it is apparently not possible to do the same using CSS?

    It doesn't seem possible to use div tags for the static natigation content
    with object or iframe tags becase one gets scroll bars if the content it to
    big for the object / iframe.

    If there is a way please do tell. All the "professional" websites I have
    seen have duplicated navigation in each and every page - instered by server
    side scripting ( or includes ), but this isn't a good solution now is it. -
    Especially if support for this isnt available.
    Spacen Jasset, Jul 22, 2004
    #1
    1. Advertising

  2. Spacen Jasset

    SpaceGirl Guest

    Spacen Jasset wrote:

    > One of the reasons that frames were inveted is to enable a navigation bar -
    > that is - the main page content changes whereas naviagtion information
    > remains static and is not dupicated into every html file.
    >
    > So why it is apparently not possible to do the same using CSS?
    >
    > It doesn't seem possible to use div tags for the static natigation content
    > with object or iframe tags becase one gets scroll bars if the content it to
    > big for the object / iframe.
    >
    > If there is a way please do tell. All the "professional" websites I have
    > seen have duplicated navigation in each and every page - instered by server
    > side scripting ( or includes ), but this isn't a good solution now is it. -
    > Especially if support for this isnt available.
    >
    >


    Why isn't it a good solution? Why rely on the client doing it when we
    already know that all clients seem to render pages in different way.
    Also, what about search engines? They cannot cope with framed sites very
    well. Also, what happens when a user bookmarks your website? They only
    get to bookmark the frameset, rather than a page within the frame set.

    Server Side Includes work 100% of the time in ALL browsers, even the
    very oldest, because the browser itself doesn't even REALISE that it is
    getting a page that has been put together from smaller modules - all the
    browser ever sees is the completed HTML. Same goes for server side
    scripting... the client browser never sees any of this script as it is
    run at the server and stripped out before it even goes near the browser...

    The only excuse I can think of for a designer not doing it this way is
    that they haven't taken on board a server side language, and dont know
    how to use SSIs...

    --


    x theSpaceGirl (miranda)

    # lead designer @ http://www.dhnewmedia.com #
    # remove NO SPAM to email, or use form on website #
    SpaceGirl, Jul 23, 2004
    #2
    1. Advertising

  3. Spacen Jasset

    Mark Parnell Guest

    On Thu, 22 Jul 2004 23:58:07 +0100, Spacen Jasset
    <> declared in alt.html:

    > One of the reasons that frames were inveted is to enable a navigation bar -
    > that is - the main page content changes whereas naviagtion information
    > remains static and is not dupicated into every html file.


    Don't know about the reasons they were created, but that's certainly why
    a lot of authors use them these days.

    > So why it is apparently not possible to do the same using CSS?


    The fact that it is not duplicated on every page has nothing to do with
    CSS. As for the not scrolling, it _is_ possible with CSS. In fact, it is
    very easy. Unfortunately most of the web uses an ancient browser that
    doesn't support position: fixed;

    > It doesn't seem possible to use div tags for the static natigation content
    > with object or iframe tags becase one gets scroll bars if the content it to
    > big for the object / iframe.


    So don't use <object> or <iframe>.

    > If there is a way please do tell. All the "professional" websites I have
    > seen have duplicated navigation in each and every page - instered by server
    > side scripting ( or includes ), but this isn't a good solution now is it. -


    Why not? It's an ideal solution. You only have one file which contains
    your menu (or whatever) and the server automatically includes it in
    every file. You only have to update one file if you want to change it.

    > Especially if support for this isnt available.


    Any half-decent host supports SSI these days. Even if they don't, you
    can always use pre-processing (which reduces the load on the server
    slightly, too).
    http://www.allmyfaqs.com/faq.pl?Include_one_file_in_another

    --
    Mark Parnell
    http://www.clarkecomputers.com.au
    "Never drink rum&coke whilst reading usenet" - rf 2004
    Mark Parnell, Jul 23, 2004
    #3
  4. "SpaceGirl" <> wrote in message
    news:...

    ....

    > The only excuse I can think of for a designer not doing it this way is
    > that they haven't taken on board a server side language, and dont know
    > how to use SSIs...


    ....

    No, it's becuase I don want to use SSI for something that should be simple.
    And why exactly don't the HTML / CSS specs incorporate such features, it's
    mind bogling. So instead a web server spits out the same contents page over
    and over.

    Why can't <object> or <iframe> elements resize to thier content? like main
    frameset tags do?

    Anyway - I take it there isn't a client side way around this?
    Spacen Jasset, Jul 23, 2004
    #4
  5. Spacen Jasset

    Webcastmaker Guest

    In article <41004638$0$6440$>,
    says...
    > One of the reasons that frames were inveted...
    > All the "professional" websites I have seen...

    <snip>

    Man this just screams of troll.
    --
    WebcastMaker
    The easiest and most affordable way to create
    Web casts, or put presentations on the Web.
    www.webentations.com
    Webcastmaker, Jul 23, 2004
    #5
  6. "Webcastmaker" <> wrote in message
    news:...
    > In article <41004638$0$6440$>,
    > says...
    > > One of the reasons that frames were inveted...
    > > All the "professional" websites I have seen...

    > <snip>
    >
    > Man this just screams of troll.
    > --
    > WebcastMaker
    > The easiest and most affordable way to create
    > Web casts, or put presentations on the Web.
    > www.webentations.com


    Nah, it is just frustration.
    Spacen Jasset, Jul 23, 2004
    #6
  7. Spacen Jasset

    Kris Guest

    In article <41004e59$0$6451$>,
    "Spacen Jasset" <> wrote:

    > > The only excuse I can think of for a designer not doing it this way is
    > > that they haven't taken on board a server side language, and dont know
    > > how to use SSIs...

    >
    > ...
    >
    > No, it's becuase I don want to use SSI for something that should be simple.


    SSI is simple. Your fear of webservers is making it difficult.

    > And why exactly don't the HTML / CSS specs incorporate such features, it's
    > mind bogling.


    Because there is not point in trying to surpass the qualities of SSI.
    Client side inclusion can never be so good.

    > So instead a web server spits out the same contents page over
    > and over.


    That is it's purpose.

    > Why can't <object> or <iframe> elements resize to thier content? like main
    > frameset tags do?


    Because markup has nothing to do with presentation.

    > Anyway - I take it there isn't a client side way around this?


    No. Battle your fear.

    --
    Kris
    <> (nl), <http://www.cinnamon.nl/>
    "De voordelen van toegankelijk bouwen": <http://www.struikelblok.nl/>
    Kris, Jul 23, 2004
    #7
  8. Spacen Jasset

    Spartanicus Guest

    Kris <> wrote:

    >> And why exactly don't the HTML / CSS specs incorporate such features, it's
    >> mind bogling.

    >
    >Because there is not point in trying to surpass the qualities of SSI.
    >Client side inclusion can never be so good.


    Client side include would actually have some benefits, a big plus would
    be the cacheability of included code.

    The real reason why there currently isn't such a thing is that it would
    break backward compatibility with existing UAs. Inclusion of such a
    feature can therefore only be considered in a language that in itself is
    designed to be not backward compatible.

    --
    Spartanicus
    Spartanicus, Jul 23, 2004
    #8
  9. "Kris" <> wrote in message
    news:4all.nl...
    > In article <41004e59$0$6451$>,
    > "Spacen Jasset" <> wrote:
    >
    > > > The only excuse I can think of for a designer not doing it this way is
    > > > that they haven't taken on board a server side language, and dont know
    > > > how to use SSIs...

    > >
    > > ...
    > >
    > > No, it's becuase I don want to use SSI for something that should be

    simple.
    >
    > SSI is simple. Your fear of webservers is making it difficult.
    >
    > > And why exactly don't the HTML / CSS specs incorporate such features,

    it's
    > > mind bogling.

    >
    > Because there is not point in trying to surpass the qualities of SSI.
    > Client side inclusion can never be so good.
    >
    > > So instead a web server spits out the same contents page over
    > > and over.

    >
    > That is it's purpose.
    >
    > > Why can't <object> or <iframe> elements resize to thier content? like

    main
    > > frameset tags do?

    >
    > Because markup has nothing to do with presentation.
    >
    > > Anyway - I take it there isn't a client side way around this?

    >
    > No. Battle your fear.
    >

    Fear? Erm. No I don't know what plannet your on, but the ability to properly
    include web pages in other web pages on the client can only be a be
    plus...what we have now is a hack.
    Spacen Jasset, Jul 24, 2004
    #9
  10. "Spartanicus" <> wrote in message
    news:...
    > Kris <> wrote:
    >
    > >> And why exactly don't the HTML / CSS specs incorporate such features,

    it's
    > >> mind bogling.

    > >
    > >Because there is not point in trying to surpass the qualities of SSI.
    > >Client side inclusion can never be so good.

    >
    > Client side include would actually have some benefits, a big plus would
    > be the cacheability of included code.
    >
    > The real reason why there currently isn't such a thing is that it would
    > break backward compatibility with existing UAs. Inclusion of such a
    > feature can therefore only be considered in a language that in itself is
    > designed to be not backward compatible.
    >
    > --
    > Spartanicus


    We're at HTML 4.01 now. The whole point of issuing a new draft and standard
    is to add new features. Frames have been around for ages, and it surprises
    me that there does not appear to be any new functionality to help with fil e
    inclusion.

    Using SSI's to include navigation content is -- I assume noone's ideal
    method, rarther, one of the only methods. It has it's own drawbacks. People
    still use modems to browse the net, and more commonly xhtml moblie enabled
    phones, which don't benefit from having the same content resent each time a
    content page is changed.

    Anyway...there we are.
    Spacen Jasset, Jul 24, 2004
    #10
  11. Spacen Jasset

    SpaceGirl Guest

    Spacen Jasset wrote:
    > "Spartanicus" <> wrote in message
    > news:...
    >
    >>Kris <> wrote:
    >>
    >>
    >>>>And why exactly don't the HTML / CSS specs incorporate such features,

    >
    > it's
    >
    >>>>mind bogling.
    >>>
    >>>Because there is not point in trying to surpass the qualities of SSI.
    >>>Client side inclusion can never be so good.

    >>
    >>Client side include would actually have some benefits, a big plus would
    >>be the cacheability of included code.
    >>
    >>The real reason why there currently isn't such a thing is that it would
    >>break backward compatibility with existing UAs. Inclusion of such a
    >>feature can therefore only be considered in a language that in itself is
    >>designed to be not backward compatible.
    >>
    >>--
    >>Spartanicus

    >
    >
    > We're at HTML 4.01 now. The whole point of issuing a new draft and standard
    > is to add new features. Frames have been around for ages, and it surprises
    > me that there does not appear to be any new functionality to help with fil e
    > inclusion.
    >
    > Using SSI's to include navigation content is -- I assume noone's ideal
    > method, rarther, one of the only methods. It has it's own drawbacks. People
    > still use modems to browse the net, and more commonly xhtml moblie enabled
    > phones, which don't benefit from having the same content resent each time a
    > content page is changed.
    >
    > Anyway...there we are.
    >
    >


    SSI is often smaller than using frames... so... explain your reasoning.

    --


    x theSpaceGirl (miranda)

    # lead designer @ http://www.dhnewmedia.com #
    # remove NO SPAM to email, or use form on website #
    SpaceGirl, Jul 24, 2004
    #11
  12. Spacen Jasset

    Spartanicus Guest

    "Spacen Jasset" <> wrote:

    >> Client side include would actually have some benefits, a big plus would
    >> be the cacheability of included code.
    >>
    >> The real reason why there currently isn't such a thing is that it would
    >> break backward compatibility with existing UAs. Inclusion of such a
    >> feature can therefore only be considered in a language that in itself is
    >> designed to be not backward compatible.

    >
    >We're at HTML 4.01 now. The whole point of issuing a new draft and standard
    >is to add new features.


    [...]

    >Frames have been around for ages


    And a mild example of what happens when stuff is introduced without
    considering the drawbacks. Frames are fundamentally flawed, and we are
    still suffering the ill effects of this mistake. Had HTML 4 introduced
    CSI things would have been much worse. A fundamental feature of HTML is
    that when an older UA encounters an element it doesn't understand it
    will ignore the element and *render the content*, that last bit is
    essential. CSI would cause mayhem as it would make content unavailable,
    every parser would have to be updated, SEs, the lot.

    --
    Spartanicus
    Spartanicus, Jul 25, 2004
    #12
  13. Spacen Jasset

    Kris Guest

    In article <4102d7c5$0$6446$>,
    "Spacen Jasset" <> wrote:

    > > > Anyway - I take it there isn't a client side way around this?

    > >
    > > No. Battle your fear.
    > >

    > Fear?


    Because you appear to me one of the kind that expects HTML is all one
    needs to author web pages.

    > Erm. No I don't know what plannet your on, but the ability to properly
    > include web pages in other web pages on the client can only be a be
    > plus...what we have now is a hack.


    SSI is not a hack

    --
    Kris
    <> (nl)
    Kris, Jul 25, 2004
    #13
  14. "SpaceGirl" <> wrote in message
    news:...
    > Spacen Jasset wrote:
    > > "Spartanicus" <> wrote in message
    > >

    news:...
    > >
    > >>Kris <> wrote:
    > >>
    > >>
    > >>>>And why exactly don't the HTML / CSS specs incorporate such features,

    > >
    > > it's
    > >
    > >>>>mind bogling.
    > >>>
    > >>>Because there is not point in trying to surpass the qualities of SSI.
    > >>>Client side inclusion can never be so good.
    > >>
    > >>Client side include would actually have some benefits, a big plus would
    > >>be the cacheability of included code.
    > >>
    > >>The real reason why there currently isn't such a thing is that it would
    > >>break backward compatibility with existing UAs. Inclusion of such a
    > >>feature can therefore only be considered in a language that in itself is
    > >>designed to be not backward compatible.
    > >>
    > >>--
    > >>Spartanicus

    > >
    > >
    > > We're at HTML 4.01 now. The whole point of issuing a new draft and

    standard
    > > is to add new features. Frames have been around for ages, and it

    surprises
    > > me that there does not appear to be any new functionality to help with

    fil e
    > > inclusion.
    > >
    > > Using SSI's to include navigation content is -- I assume noone's ideal
    > > method, rarther, one of the only methods. It has it's own drawbacks.

    People
    > > still use modems to browse the net, and more commonly xhtml moblie

    enabled
    > > phones, which don't benefit from having the same content resent each

    time a
    > > content page is changed.
    > >
    > > Anyway...there we are.
    > >
    > >

    >
    > SSI is often smaller than using frames... so... explain your reasoning.
    >


    SSI causes more traffic on the server and cilent by a factor of N * X Where
    N is the size of your included content and X are the number of pages that
    are requested that include the content.

    I am not saying frames are better, we know the problems; what I was hoping
    for was a good replacement. For instance <object data="page"
    sizetocontent="true" /> Where sizetocontent would size the object to it's
    content.

    The other problem is that different web servers handle SSI's in different
    ways, for example it might be configured to only process SSI's from pages
    endinging .shtml, where as some don't. So you have fiddle about to get
    things working.
    Spacen Jasset, Jul 25, 2004
    #14
  15. "Spartanicus" <> wrote in message
    news:...
    > "Spacen Jasset" <> wrote:
    >
    > >> Client side include would actually have some benefits, a big plus would
    > >> be the cacheability of included code.
    > >>
    > >> The real reason why there currently isn't such a thing is that it would
    > >> break backward compatibility with existing UAs. Inclusion of such a
    > >> feature can therefore only be considered in a language that in itself

    is
    > >> designed to be not backward compatible.

    > >
    > >We're at HTML 4.01 now. The whole point of issuing a new draft and

    standard
    > >is to add new features.

    >
    > [...]
    >
    > >Frames have been around for ages

    >
    > And a mild example of what happens when stuff is introduced without
    > considering the drawbacks. Frames are fundamentally flawed, and we are
    > still suffering the ill effects of this mistake. Had HTML 4 introduced
    > CSI things would have been much worse. A fundamental feature of HTML is
    > that when an older UA encounters an element it doesn't understand it
    > will ignore the element and *render the content*, that last bit is
    > essential. CSI would cause mayhem as it would make content unavailable,
    > every parser would have to be updated, SEs, the lot.
    >


    Well I don't see that as a good argument. Any thing that is added to HTML
    means that older clients may not be able to use it. <object data= > is just
    one example. By adding another "resizetocontent" attribute to the object
    element it woud't prevent browsers rendering content.

    Besides many browsers still fail to render CSS properly and yet still new
    features have been added. So HTML/CSS doesn't stand very still anyway does
    it?
    Spacen Jasset, Jul 25, 2004
    #15
  16. "Kris" <> wrote in message
    news:4all.nl...
    > In article <4102d7c5$0$6446$>,
    > "Spacen Jasset" <> wrote:
    >
    > > > > Anyway - I take it there isn't a client side way around this?
    > > >
    > > > No. Battle your fear.
    > > >

    > > Fear?

    >
    > Because you appear to me one of the kind that expects HTML is all one
    > needs to author web pages.


    Well yes, why not.

    > > Erm. No I don't know what plannet your on, but the ability to properly
    > > include web pages in other web pages on the client can only be a be
    > > plus...what we have now is a hack.

    >
    > SSI is not a hack


    It I think it is for this type of thing because it's used to get around the
    problem of having multiple duplicate fragments of html in many html files.
    It's not efficient either. The content has already been sent to the client
    when the first page loads.

    I am surprised that noone really agrees with me on this because it would
    make web designers lives easier ( you could then test pages from a local
    file system aswell - instead of having to go through a web server. - plus
    the other advantages already mentioned ) The only single drawback is support
    for it. But why wasn't it added after problems with frames came to light?

    I think I've imposed my logic on everyone enough now so I'll desist.
    Spacen Jasset, Jul 25, 2004
    #16
  17. Spacen Jasset

    rf Guest

    Spacen Jasset wrote
    > SpaceGirl wrote


    > > SSI is often smaller than using frames... so... explain your reasoning.
    > >

    >
    > SSI causes more traffic on the server and cilent by a factor of N * X

    Where
    > N is the size of your included content and X are the number of pages that
    > are requested that include the content.


    Do you have any idea at all how the internet works internally? Sorry to be
    blunt but you are missing quite a few vital facts.

    Traffic:

    A page with SSI on it (lets forget about images for the moment) requires one
    hit on the server. That is, two set of HTTP headers and TPC/IP packet
    overhead, one up, one down.

    A typical frame page requires four hits on the server, one for the frameset
    and one for each frame (assuming header, nav, content). This uses eight sets
    of headers etc. These are not small, haven't looked closely but I'd imagine
    a couple or three hundred bytes at least. Yes, the returns appreciate after
    the frameset is loaded but the first hits on the server are a bastard.

    Server:

    A page with SSI on it requires one transaction schedule. That is,
    marshalling the incoming request, queing it if the server is busy, actioning
    it and getting the results out the door. The time spent by the server to
    actually assemble the SSId page is a small proportion of this whole. The
    execution path length in the TCP/IP stack alone would be greater.

    Of course the server has to read the page from its local storage BUT, after
    the first hit the included bit is in the servers file system cache.

    A hit on a framed page requires 4 of these. 4 times the processing. Once
    again appreciating returns but that first hit is a bastard.

    Network.

    A page with SSI on it requires one round trip to the server. From where I am
    a trip to a server in the U S of A costs me 400 milliseconds. So, my UA
    sends off a request and waits... For 400ms... This is *not* a small amount
    of time when one is looking at a screen waiting for something to happen.

    A framed requires 4 trips to the server. 1600ms. 1.6 seconds overhead, over
    and above the usual transport times.

    Content.

    SSI delivers one page, with one set of <!doctype, <head> etc. Frames deliver
    four of this overhead.

    The bottom line.

    It is *quite* expensive to set up a transaction with the server. The actual
    processing of that transaction is minimal, compared to the turn around time
    over the net.

    We went through this a while ago with regard to slicing up images, under the
    misapprehension that a sliced image downloads quicker. An experiment
    revealed that slicing an image into 9 bits resulted in an end user loss of
    performance by a factor of 10.

    Frames, while not quite so bad, are still bad from a network point of view.
    Any savings made by sending out a slightly smaller package (once the
    frameset has been set up on the browser) are far far outweighed by the vast
    overhead of setting up that frameset to start with.

    Any savings made by not sending the "included" stuff, usually a text menu
    bar, are usually far outweighed by the size of the content in the "content"
    frame. Why bother saving a couple of hundred bytes of menu when a single
    click on that menu spews down tens of thousands of bytes of <img>?
    </rant> :)

    > I am not saying frames are better, we know the problems; what I was hoping
    > for was a good replacement. For instance <object data="page"
    > sizetocontent="true" /> Where sizetocontent would size the object to it's
    > content.


    Don't worry about it. Just use SSI and be done with it. If you are really
    worried about performance issues simply up the compression on your logo
    jpeg. You'll be better off.

    > The other problem is that different web servers handle SSI's in different
    > ways, for example it might be configured to only process SSI's from pages
    > endinging .shtml, where as some don't. So you have fiddle about to get
    > things working.


    So? Once you have worked out how your server works you are done with that
    bit. You simply do it that way from now on.

    --
    Cheers
    Richard.
    rf, Jul 25, 2004
    #17
  18. Spacen Jasset

    Spartanicus Guest

    "Spacen Jasset" <> wrote:

    >> >Frames have been around for ages

    >>
    >> And a mild example of what happens when stuff is introduced without
    >> considering the drawbacks. Frames are fundamentally flawed, and we are
    >> still suffering the ill effects of this mistake. Had HTML 4 introduced
    >> CSI things would have been much worse. A fundamental feature of HTML is
    >> that when an older UA encounters an element it doesn't understand it
    >> will ignore the element and *render the content*, that last bit is
    >> essential. CSI would cause mayhem as it would make content unavailable,
    >> every parser would have to be updated, SEs, the lot.

    >
    >Well I don't see that as a good argument. Any thing that is added to HTML
    >means that older clients may not be able to use it. <object data= > is just
    >one example.


    Used correctly it's no problem at all:

    <object data="http://example.com/example.htm" type="text/html">
    <a href="example.htm">Example</a>
    </object>

    Remember that embedded HTML is displayed in a separate viewport inside
    the existing document and that the embedded code is a completely
    independent document in it's own right.

    Now let's assume that HTML 4 would have introduced something like this:

    <include data="http://example.com/example.txt" type="text/plain">
    <a href="example.txt">Example</a>
    </include>

    whereby example.txt contains a code *fragment*, this code makes no sense
    whatsoever outside of the context of the original document, resulting in
    a broken www for older clients. This is simply unacceptable in a
    language designed to be backward compatible as HTML 4 was.

    >Besides many browsers still fail to render CSS properly and yet still new
    >features have been added. So HTML/CSS doesn't stand very still anyway does
    >it?


    CSS is presentational, entirely optional and new CSS features have no
    effect on the availability of content. Google Bot doesn't do CSS and it
    seems to be doing ok without it.

    --
    Spartanicus
    Spartanicus, Jul 25, 2004
    #18
  19. Spacen Jasset

    Philip Ronan Guest

    On 25/7/04 12:10 pm, rf wrote:

    > A typical frame page requires four hits on the server, one for the frameset
    > and one for each frame (assuming header, nav, content). This uses eight sets
    > of headers etc. These are not small, haven't looked closely but I'd imagine
    > a couple or three hundred bytes at least. Yes, the returns appreciate after
    > the frameset is loaded but the first hits on the server are a bastard.


    If the frameset contains static files without SSIs, then they can actually
    be retrieved in one go with a persistent connection. So the frameset could
    be delivered in just two round trips to the server.

    --
    Philip Ronan

    (Please remove the "z"s if replying by email)
    Philip Ronan, Jul 25, 2004
    #19
  20. Spacen Jasset

    rf Guest

    Philip Ronan wrote

    > > A typical frame page requires four hits on the server, one for the

    frameset
    > > and one for each frame (assuming header, nav, content). This uses eight

    sets
    > > of headers etc. These are not small, haven't looked closely but I'd

    imagine
    > > a couple or three hundred bytes at least. Yes, the returns appreciate

    after
    > > the frameset is loaded but the first hits on the server are a bastard.

    >
    > If the frameset contains static files without SSIs,


    How does the presence or absence of SSIs affect this particular scenario?
    The SSI is done at the server. The UA knows nothing about what happens at
    the server.

    > then they can actually
    > be retrieved in one go with a persistent connection. So the frameset could
    > be delivered in just two round trips to the server.


    Could. But do the UAs do this? No. Do the servers support retrieving
    multiple HTML pages in one (your second) transaction? No. HTTP is designed
    to serve up one "page" per connection. It is stateless by definition and by
    specification. One connection to the server, one page served.

    --
    Cheers
    Richard.
    rf, Jul 25, 2004
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Matt
    Replies:
    0
    Views:
    3,539
  2. John Hann
    Replies:
    0
    Views:
    6,071
    John Hann
    Aug 21, 2004
  3. Matt
    Replies:
    9
    Views:
    70,829
  4. Eswa
    Replies:
    0
    Views:
    368
  5. Matt
    Replies:
    9
    Views:
    541
    kaeli
    Aug 23, 2004
Loading...

Share This Page