- From: Christian Wolfgang Hujer <Christian.Hujer@itcqis.com>
- Date: Tue, 1 Jan 2002 10:20:44 +0100
- To: "Jeff Barber" <jeff.barber@oracle.com>, <www-html@w3.org>
Hello Jeff, > -----Original Message----- > Hi, > > I have an idea that might have been previously discussed but I can't find > reference to it. > > While browsing the web a lot of pages contain references to many > images (it > is not unusual to see 30+). There are lots of methods of > compressing images > which help speed page display times, however the main problem (apart from > size) is network round trip. That's not true, and also the thoughts behind this idea are very intelligent I think this is no good idea. 1. Most browsers understand compressed Data. They send an HTTP Request Header like "Accept-Encoding: gzip,deflate,compress". If you use an intelligent web server like Apache just additionally save a gzipped version of you files. For example, compress your file "index.html" to a file named "index.html.gz" with a command like "cat index.html | gzip -f -9 >index.html.gz" and you will reduce the file size of this html page to an average of approx. 30% of its original, depending on the size of the file (larger files have more redundancy and thus get compressed better). Nearly all browsers, namely Internet Explorer, Navigator, Opera, Konqueror, Mozilla, lynx, w3m and many many more will get the compressed version and transparently decompress it. > Each time an image is requested the browser has to go back to the server. No. 2. Most browsers use HTTP/1.1 as application layer protocol. HTTP/1.1 has support of "Keep-Alive"-Connections. This special form of HTTP connections allows transmission of more then just a single file, it supports a sequence, a chain, of HTTP Requests and HTTP Responses. Usually your browser establishes an HTTP/1.1 Keep-Alive Connection and transfers most resources of a page in a single TCP connection. > I would have thought that a simple solution to this would have been to > combine all of the images into a single file, this would only involve a > single network round trip, for argument sake the tag could be <IMAGEARRAY > NAME="array1" SRC=".......">. Then else where in the document instead of > <IMAGE> tags you could have new tag called <LOCALIMAGE SRC="array1" > IMAGE="3"> the browser could then render the image on screen from a single > source. > > What say you ? 3.1 HTML has absolutely no technical tasks. HTML is a descriptive language for Hypertext. It is not the task of HTML to solve network traffic issues or problems of archaic file systems like FAT. 3.2 Introducing new HTML elements, especially those that require changes in browsers, at present are no good idea. As long as even the currently most popular web browser, Internet Explorer, is even in its newest version, 6.0, not capable of displaying straight-forward web pages written following the W3C Recommendation of HTML 4.0 from 1997, we have to give time to Microsoft and other browser vendors to implement current standards. 3.3 Generally it's not a good idea to introduce new stuff to HTML which in now way is backwards compatible. I also didn't and do not like the idea of frames. Greetings and a happy happy and peaceful year to Jeff and all others on the list! Christian
Received on Tuesday, 1 January 2002 04:23:07 UTC