Why are they still using tables for layout?
 

I've just been fiddling with the X-Cart installation that I'm customising for a client, and I decided to try displaying the Featured Products in two column mode. Suddenly, all the changes I had implemented on the one column version were lost, and then I looked in Firebug and my heart sank: tables.

Not only tables, but the craziest implementation I have ever seen.

Code:

---

<tr class="first product-name-row">
                 
            <td class="first product-cell">
              <div class="image">
                <a href="product.php?productid=17515&cat=0&page=0&featured=Y"><img src="http://www.mrdtrading.co.uk/store/images/T/kart2small.jpg" width="125" height="79" alt="Red Rooster Go Kart" /></a>
                              </div>
            </td>
                           
            <td class="highlight last product-cell">
              <div class="image">
                <a href="product.php?productid=17518&cat=0&page=0&featured=Y"><img src="http://www.mrdtrading.co.uk/store/images/T/xctD748.tmp.png" width="125" height="125" alt="Rugged Racer Mini 101" /></a>
</div>

---

So the table spans both columns, and then you have two <td> elements, one for the first product, one for the second. And repeat, all the way down the product description...

I may not have time to completely implement it with this client, but with my next job, I think I am going to completely redo this mess, and make it use CSS properly, i.e. no tables for layout. Perhaps I can get Qualiteam to hire me as their chief CSS designer! (Or rather, ONLY CSS designer, as they don't seem to understand how it works...)

I also keep seeing

Code:

---

<br /> <br />

---

and content which is only surrounded by div tags, no paragraph tags, hence their unnecessary use of the <br /> tags. How can you use CSS when you have something like:

Re: Why are they still using tables for layout?
 

Yea, they still don't get it

Re: Why are they still using tables for layout?
 

Hi Balinor, it's driving me nuts! It's like having to recode the thing from the ground up every time I start looking at a new template!

Is there a proper CSS template out there, with redesigned X-Cart templates? It would save a lot of people a lot of time if there were.

I can't understand how Qualiteam can't have one person who understands CSS properly, and it's not even complicated stuff that they're getting wrong, it's the basics, like the float property - they don't even know what it is!

Re: Why are they still using tables for layout?
 

I know...I rewrite the whole template system from scratch each time a new version comes out. I had a 'proper' table-less layout in 4.1.x and I basically reuse that one each time. The way they use float and CSS drives me absolutely insane. All they need is one CSS pro over there to do it right!

Re: Why are they still using tables for layout?
 

do you normalize the margins and padding of your <p> tags, hate the different default settings per browser.

Re: Why are they still using tables for layout?
 

Depends - the alternate stylesheets per browser usually take care of that.

Re: Why are they still using tables for layout?
 

I don't use the <p> tag all that much.

Re: Why are they still using tables for layout?
 

I have thought long and hard about re-writing the whole thing, but with some many versions being released it seems like a waste of time. maybe v5 will stick around for a while.

Re: Why are they still using tables for layout?
 

Tables are ok if they are used to display tabular info but you are right - the whole html/css in xcart is a huge mess. And that is also contributing to the huge main css file

Re: Why are they still using tables for layout?
 

I use the <p> tag all the time, to represent anything that looks like a paragraph, or anything that I want to hook CSS onto. There are so many instances in the templates where there aren't any <p> tags at all, just a container div and the text inside it.

Perhaps one of us can approach Qualiteam and see if they'll hire us for a few months' work, to fix it all!

Anyway, I'm going to have to redo the two column layout, as it is it's simply impossible to apply CSS to it - how can I put a background around one product box, when there are two side by side in the same table, they way they've done it?

I know it wasn't like that in 4.1, I have another site that uses that and I had no problems with two or even three column layouts. I'll have a look at that code and try to use it in 4.3.2, when I've done it all, I'll post it up in Completed Mods.

Re: Why are they still using tables for layout?
 

I nest Div tags.... maybe not the best practice.

When I first started x-cart and before I knew much about webmaster mode and fire bug, rouge P tags used to drive me nuts because of the extra margin and padding. Note this was several years ago.

Any ways, I developed a severe dislike for them a long time ago, and haven't used them since. :oops:

I don't let go easily!

Re: Why are they still using tables for layout?
 

It is almost funny, everytime one of these threads starts, there is no responses from QT.

A clean bare bones install, without all the added garbage would be great. 4k of lines for the main css file is nuts. Customizing any of the skins is next to impossible if you very much from the initial layout.

Re: Why are they still using tables for layout?
 

I always set out my markup like this:

<div class="whatever">
<p>Paragraph text with <em>bold or whatever</em> within it.</p>
<ul>
<li>List item 1</li>
<li>List item 2</li>
</ul>
</div><!-- END OF WHATEVER -->

Then I just use descendent selectors for everything within the div,
.whatever p
.whatever ul

etc.

I zero out all the margins and padding right at the start of the CSS file.

Re: Why are they still using tables for layout?
 

I agree with you so much! I am literally going to have to produce an entirely new CSS file, and start everything from scratch, just to get a workable 'slate' to start with.

Anyway, I have just had a look at
products_list.tpl
to compare it to the 2 column
products_t.tpl

products_list.tpl uses CSS, no tables, but products_t.tpl uses tables! So they fixed one part, and then made the worst table layout possible for two column layouts.

Once I've redone it all I'll post it up to the mods section (unless somebody else has already done something similar - fingers crossed.)

Re: Why are they still using tables for layout?
 

Yeah, I've been experimenting with different resets for alot of my work, just not x-cart yet.

If i thought 4.3 would be around a while I'd tackle the job, or 4.4 for that matter. Still don't understand all the totally different versions with v5 right around the corner.

Ash

Re: Why are they still using tables for layout?
 

I wouldn't count on v5 being right around the corner - I'd guess next year if I had to put money on it.

Re: Why are they still using tables for layout?
 

ok, so 4.4 soon? would hate to invest hours into 4.3 and then boom... it obsolete.

That's is why it's very important to have accurate dates for completion of each branch :(

Re: Why are they still using tables for layout?
 

Yea, 4.4 is in beta now, so should be out in a couple weeks - I'd focus on that one as it is a pretty big change from 4.3 from what it looks like.

Re: Why are they still using tables for layout?
 

Well, I found a simpler solution, I edited the CSS for
products_list.tpl

and changed line 2745 of main.css to:


That reduces the width of the (normally one column wide) product box, and floats it to the left, so you end up with two columns, and a LOT less work than trying to completely rewrite products_t.tpl.
You MUST give the element a height, otherwise the height may vary (for example, if the item has been reviewed, it will say "You have rated this product already", which adds height to the box) - and then you will suffer from the dreaded 'float drop', and you'll find your product boxes higglegy piggledy down the page...


All it means is that the customer can't choose to have one or three columns by editing General Settings, Appearance Options, 'Display products list in multiple columns (1-3) (leave empty to use standard format)', but that wouldn't work with my design anyway.

Re: Why are they still using tables for layout?
 

4.4 in beta means 6-9 months for what we call a true stable version.
v.5 would be 6-9 months after that for release and since it is a new platform we should allow more time for what we call a stable version.

Ashley, depending on how many projects you have in the works, it might be worth the effort. Even better would be to team up with someone to split the work load.

Re: Why are they still using tables for layout?
 

I dunno...they have been getting better about the beta testing of late. Used to be 6-9 months for a stable release, but 4.3.x was pretty workable at 4.3.1, and that wasn't that long after the beta.

Re: Why are they still using tables for layout?
 

Yeah but 4.3 wasn't that far off of 4.1 or 4.2, just a bit of ajax added. They should of had very minor fixes for those releases.
v.5 is totally different so the learning curve will be more extreme.

Re: Why are they still using tables for layout?
 

If we ever get to see it...

Re: Why are they still using tables for layout?
 

back to the original subject, are tables used becasue of the adjustable nature of products_t.tpl 1,2 or 3 column layout?

how could you count cells and adjust div width with css dynamically?

Re: Why are they still using tables for layout?
 

You don't need to count the cells with a <div> - they will wrap automatically based on the room available. Had a few clients want the number of products to increase with the width of the browser screen (dynamic layout) and divs work great.

Re: Why are they still using tables for layout?
 

I understand that, but the admin area give you an option to have 1,2 or 3 column. For the non-pro store owner this option is nice. Not everyone has a Balinor in their back pocket ;)

Re: Why are they still using tables for layout?
 

PS - we need to start a store that sells back pocket clones of Balinor!!!!

Re: Why are they still using tables for layout?
 

Once purchased will it work for free forever?

Re: Why are they still using tables for layout?
 

You can set a countdown using smarty based on the administrative setting to insert a div that does a clear:both to start a new line.

If I recall correctly - X-CART used a table for product listings on a multi-column block because they were trying to keep uniform row heights, and it was easier to use a table rather than use css because of the way they were looping through the data. If you happen to have different heights of pictures, and product descriptions and prices are different heights, then you need to resolve all that in the css to keep the rows lined up, whereas using a table, the row heights set up in a grid, so it is easier to account for all the possibilities that users might require.

Re: Why are they still using tables for layout?
 

Couldn't they use a container div to contain one, two or three product boxes (horizontally), and use Smarty to decide whether to loop once, or twice, to show two or three boxes horizontally within that container div?

The strange thing is that the way they have set up the table in 4.3.2 is a hundred times worse than it was in 4.1 - 4.1 works fine, I can put the product box in one table cell, whereas 4.3.2 uses a table cell for each part of the product box, the product title, price, etc.etc.

Re: Why are they still using tables for layout?
 

oh yeah, it sux! did that to keep things lined up.

Re: Why are they still using tables for layout?
 

You probably are not understanding why because you've only worked with cart instances that have uniform data. If you work with one where the product images are different heights, titles are all different heights, some of the products have sales applied, some do not, different mods are applied that add images, such as OnSale mod, etc. There are many options that QT's customers require on the products_t template that they must support. The problem they are solving by using a table is that all these can have different heights. It is possible to support it with css - but it also involves smarty and php with how you loop through the data.

Think of what you stated above where you mentioned "float drop" and assigning a uniform height. It is the same issue except instead of just the product box - you have to account for all the data that can possibly be displayed in products_t template and all their max heights. Think also of the impact of white space where data is small vs. large.

If you have a good understanding of the requirements on your instance of the cart with respect to the max & min heights of all the data you want to display for each product in the grid - then the css/smarty might not be so complex and you can replace the tables. It becomes a more complex issue if you have to support a lot of mods and varied heights for the data. Using a table to form a grid when you don't have height requirements is much easier. The table displays the least amount of white space and can set the height to max required. The pros of using tables can overcome the cons under the right circumstances.

Re: Why are they still using tables for layout?
 

I still don't see how it can't be done with CSS:
you use one container div, which automatically stretches to fit the height of the largest product box within it, whether there are two or three. Within each product box, you use CSS for layout. The total height of all the components doesn't matter, the container div will expand to contain all the divs within it (as long as you float them, of course, which QT don't seem familiar with!)

Have we been looking at the same templates? The one I saw meant that each row of the product box was a table cell, and if the cell on the left product box was three lines high, the corresponding cell on the right product box would also be three lines high, even if it only had one line in it - meaning the entire thing was a terrible mess, and you couldn't put a background image around the individual product boxes, etc.etc.

I don't think there would be any CSS or Smarty required for my method. I'm using it right now and it works okay - but I haven't put a container div round the two product boxes yet, and doing that would remove the need for me to set the height of the product boxes.

I don't understand what you're saying really - if I have a left hand product box that turns out to be 300px high, due to On Sale images, etc.etc., and the right hand box is only 200px high, you still want their tops to align, and you still want the next row of product boxes to start underneath the tallest of the two product boxes in the top row, so I don't see how tables does anything that simple divs do. All the tables did for me was create a god awful mess.

And my site at www.3drom.com uses divs for the product boxes (which are contained within table cells, but don't contain table cells (big difference:-))). And that uses 4.1!

Can you show me an example of what you mean, gb2world? I can't see any advantage to the way they've done it, only huge disadvantages (i.e. so huge that their way of doing it is completely unworkable.)

ps I will try to post up some simple box layouts displaying what I am talking about, tomorrow.

Re: Why are they still using tables for layout?
 

ok so you ahve a row with 3 products in it.

You use divs to float them left or right or whatever.

now div 1 total height is 200 px, div 2 total height is 250 and div 3 total height is 125

so lets say that you want to put a border around each div, well it will end up lookin like an upside down stair case. since each one will be a differnet height.

There are ways of getting around this of course, by making all content the same.

Re: Why are they still using tables for layout?
 

I didn't say it was impossible - I'm just saying if you have given the programmer a requirement to support variable heights - but still keep everything in a grid, and reduce white space - then a table is really easy, and css might be complex. I'm trying to answer your original question of why QT did it this way - their requirement is probably broader than yours.

I have replaced the tables on products_t with all css before - but only for clients that have everything fairly uniform and do not want to display too much data per product. But if I had a client who wanted to support all the data that QT has to support and wants it to be in a grid with reduced white space - I'd likely leave it in a table. When I am unsure what the client has in mind - I wait to remove the table - because it can cost them a lot in the future when upgrading or adding 3rd party mods, if they still want it to display in a grid.

In your latest question - you are talking about aligning product boxes. QT's table not only aligns the entire product box - but all the things in the product box - title, image, description, rating, on-sale stuff, etc - it is all in a grid.

You have to know your max and min heights as you move in a row across the grid to do it with css. A table has the advantage in that it can just set the height based on the biggest div that is in it. If you are stepping through the row with css, you don't know what the height of the next two divs are going to be, so you can't set it. You need to know in advance max and min heights, or put it all in a big row div. But then you don't have a div around the entire product.

Again - it can be done in css - I'm not discouraging you from doing it - I'm just trying to let you know the issues you come up against if you try and support all the mods and displays possible in products_t and then also support mods from 3rd parties, and keep a grid display.

This is true. If this is your requirement - then you'll have to change the design. But if your requirement is to line everything up in a grid, then the changes you are proposing make that more difficult. There are always going to be customers with different requirements, and when they conflict, there will be differing opinions on what is more important.

To get an idea - try having a few titles that are really long and a few that are short, throw in a few thumbs of different heights. Turn on sales for some and not others - do as much stuff like that and cover as much of what QT is supporting as you can. Just keep it as a test page as you are developing the css to replace the table. I suspect you can do it - but it will be complex if you also require that these can be of any height - and you do not want a lot of white space. If you throw in your background-image requirement - then I think it will get really hard, but I could be wrong.

Re: Why are they still using tables for layout?
 

Do you have any examples of what you are talking about? I still can't visualise how it would be an improvement to use tables.

I've just been working on the layout of the featured products section on the homepage of the site I am customising, and I've had no problems using CSS to make the individual product boxes do what I want - i.e. line up, etc.

I use
clear:left
float: left

and no matter how high the description is, the boxes will clear each other correctly (but thank God that QT actually have the 'highlight' class for every other box, without that it wouldn't work!).

I use this CSS:

.products-list .item {
position: relative;
margin: 0px 0px 25px 10px;
padding: 10px;
clear: left;
float: left;
width: 330px;
height: 300px;
border-bottom: 1px dotted red;
}
.products-list .highlight {
margin: 0 0 0 15px;
clear: none;
border: 1px dotted red;
border-top: none;
border-right: none;
}

(The 'highlight' style didn't exist in the CSS (unless I missed it), but the class is generated (I think) by Smarty, for all even numbered product boxes. (Please correct me if I'm wrong.)

So the right hand box (I use a two column display) has
clear: none
and thus won't try to drop down to the next line (as the product boxes can have two classes applied to them).
I can then apply a different sized left (or right) margin, to the left and right columns, and also put a background image on the entire product box, or, just as importantly, on part of it, if I set up a div within the product box. I can't do that in tables.

But then, I am a die-hard CSSer, and I can't imagine trying to set up anything of this nature, using tables! :lol:

I have added an extra long title to the second featured product, and four lines in the brief description, and it still works fine.
Notice how the section which begins with "Our price" still goes where it's supposed to - that's because it was easy to just add another div (with the class of "details2" in this case), and I then have yet another block to play with, which is impossible using tables.

http://www.mrdtrading.co.uk/store/home.php?shopkey=martin

Re: Why are they still using tables for layout?
 

you have explicitly defined width and height, but I ahve had many store owners put a 400px high image as their product images (not a good idea I know).

So what happens then?

Re: Why are they still using tables for layout?
 

Well, I had to define the width, otherwise there would only be one column. I turned off the height with Firebug, it worked fine.

If your client uses an image 400px in height, my solution would work just as well as the tables solution, but obviously clients aren't going to use a 400px high thumbnail! (And anyway, X-Cart will force it to be 125px high, or whatever you have set it to in Appearance Options).

I still don't understand what gb2world is describing, for example, if the product box in the left column has one line in the description, and the product box in the right column has five lines, then by using the QT table, the left hand description will have loads of unnecessary white space underneath it. (Obviously you would tell the client to use two lines maximum, or whatever, to keep things consistent - this is the whole point of the featured product boxes, is it not! Not to display the entire description, but a couple of simple lines describing the product.)

Re: Why are they still using tables for layout?
 

You can tell the client all day long what to do, that doesn't mean they will listen!!!!!!!!!! :)

Re: Why are they still using tables for layout?
 

Ah well, in that case they will have to put up with a broken webpage!
You can't fit a quart into a pint pot. :lol: