Forum Moderators: open
What about small tables of just 2 rows (4 pics each = 8 pics per table)
And completing with more tables?
Does that help? I mean users would be viewing first pics fast and the rest of page (hidden by the vertical scroll) would be loading?
Am I right?
What about using Server side include for the rest of tables? and leaving only 1 talbe at top with 4 or 8 pics?
Any tips?
In the other hand page is composed of thumbnails pics (4,5 kb each) and links...
Links will load fast (text) I think and pics later... but will that stop the page load? I mean users would be viewing at least the text description and first pics...
Feedback please?
Thanks a lot!
IE4 and IE5 used to wait until the entire tables, and contents (images) loaded before they started drawing the table to the screen. (not tested IE6.) So splitting the table in segments of about a screens height each (2 maybe 3 rows per table) would mean that the top table loads in and displays then the user can view those images while the rest of the page loads. Also of note, you should explicitly specify the width and height of each image in you html or IE will wait for the entire page to load before drawing anything. Specify the table sites can also increase the render speed slightly (but not much)
For Opera and Mozilla based browsers, the table will be drawn and then redrawn as images load. They won't wait for the entire table. So splitting the table will have little effect on them.
Using SSI to call the tables only adds more calls to the server. While we are talking milli seconds, it is still extra time. The SSI will not effect the browser rendering as the browser would still get the same data as if no SSI was used. Putting the table in SSI may be a good idea for site maintenance if the images are to be changed.
As for the text links. Opera and Moz will write the text and the link while still waiting for the images. So that will help. If a users knows where to go, they can at least click the links. Alt text and titles on the images will also help as the tool tip will display even if the image has not.
You could reduce the html load of the page by not using tables at all. Using css. Wrap each image+description into a <div> then use float:left to place the image divs next to each other and then a clear:left of every forth div to start a new row. Would reduce the html size considerable.
Ultimately, the speed of page display is dependent on the Kb of data. You have 40 pics at 5kb each. That's 200Kb just for the images. That will take quite some time to load in. Even if you squashed the graphics down a bit, you would still be looking at a very large load size. Also, 40 thumbs on a page can look very cluttered. The best way of solving the problem would be to spread the thumbs over several pages. I'd suggest 5 page of 8 thumbs each.
Also wonder if for a 4 kb jpg image "progressive" has some effect or just takes some bites extra...
In the othre hand I just expect that user see first 8 pics in a reasonable time (10 secs?), I don't care if they must wait for the other pics because they are down in the page and must scroll.
The first 8 pics provides me enough time and content richness to make the user wait for the rest.
Can layers live into tables? (A table with <div> into a <td>?)
No, layers must not go into tables. A <td> is an inline element where as a <div> is a block element. You can nest block instead block and inline inside inline and even inline inside blocks but never blocks inside inline. If that makes sense.
Also, <div>s are not layers. The <div> tag simply represents a division of blocks of content. Splitting content up into seperate elements. Dreamweaver does refer to some <div>s as layers. These are div's that have had position, left, top, height, width and z-index styles added to them to take them out of the general flow of the document. Because they are outside the normal flow, they can be positioned over, in fornt of or behind other elements in the page as if they were on different layers. But just the plain old <div> tag on it's own doesn't break the document flow and so is in the same layer as the rest of the page.
The <div> could form the exact same function as your <table>, <tr> and <td> tags do. They simple mark up the divisions between your image and description elements. You can then style those divisions how you like. The advantage of using <div> over tables is that you only have a <div> and a </div> for each image group. Where as in tables you have <table> then a <tr> and </tr> for each row and a <td> </td> for each cell. It's slightly more markup than you need. We are only talking about a few Kb though.
composed of thumbnails pics (4,5 kb each)
You'll save the most time by optimizing your thumbnails further rather than adjusting your HTML. Thumbnails do not need to be high-definition images, so you should reduce the quality to bring them down to 1kb to 2kb in size. With 40 images, the size saving would be amount to much more than you could ever do with HTML alone - although splitting the table is a good idea too to make the layout render faster.
You're probably doing this already, but don't forget the specify the width and height attributes so the browser will leave the space for the thumbnail before it loads, and make sure that each thumbnail has an appropriate alt tag so that a good description will appear before the image loads.
ALA had an article that you may find useful.
http*//www.alistapart.com/articles/practicalcss/
...jpg image "progressive" has some effect or just takes some bites extra
Progressive is "supposed to" render the fuzzy, first pass version of the image more quickly. But IE got it wrong in their first implementation of progressive jpg and they never fixed it.
What Explorer does with a progressive is wait until ALL the data is there and then render the image in one shot. So you don't even get the top to bottom fill in. What should have been an advantage for slower connections was turned into a disadvantage!
File size for a progressive jpg is often a bit SMALLER than the file size for an identical image saved as a standard jpeg format at the same compression level. That's not very intuitive, but I do enough graphics work to see it happen over and over again. If only IE had it right, you could actually cut a small bit of file size.
you should reduce the quality to bring them down to 1kb to 2kb in size
never blocks inside inline
That's essentially true, but here the issue is that <td> isn't your garden variety inline element. In fact, I believe it has its own type -- "table-cell" -- which can hold many kinds of block or inline data.
For instance, <h1> and <p> elements are both block level and they both will validate inside a <td> element. Forms are another example. How about nesting a table (definitely a "block" element") within a <td>. And yes, divs can also be valid within a table cell.
No, layers must not go into tables. A <td> is an inline element where as a <div> is a block element. You can nest block instead block and inline inside inline and even inline inside blocks but never blocks inside inline. If that makes sense.
Technically this is not correct.. otherwise you couldn't put a <p>, <h1>, etc.. inside a <td> as a <p> element is a block level element too..
Unfortunately W3 seems to be down for the tech specs and reference .. but I think <td> is what will be referred to as an inline-block
<added>Tedster, quicker on the draw!</added>
Will follow with reference when I can access site.
But in actual fact I don't think it would be "quicker" to put divs inside tables it would just be extra mark-up.. I would either just use CSS/divs full stop or I would have 10 seperate tables..
Suzy
