Quote:
|
whereas 4.3.2 uses a table cell for each part of the product box, the product title, price, etc.etc.
|
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.