Follow us on Twitter X-Cart on Facebook Wiki
Shopping cart software Solutions for online shops and malls
 

Why are they still using tables for layout?

 
Reply
   X-Cart forums > X-Cart 4 > Dev Questions > Changing design
 
Thread Tools Search this Thread
  #31  
Old 07-13-2010, 09:05 AM
  ARW VISIONS's Avatar 
ARW VISIONS ARW VISIONS is offline
 

X-Man
  
Join Date: Jan 2007
Location: Pensacola, FL
Posts: 2,536
 

Default Re: Why are they still using tables for layout?

oh yeah, it sux! did that to keep things lined up.
__________________
xcart 5.1.2
Reply With Quote
  #32  
Old 07-13-2010, 12:07 PM
  gb2world's Avatar 
gb2world gb2world is offline
 

X-Wizard
  
Join Date: May 2006
Location: Austin, TX
Posts: 1,970
 

Default Re: Why are they still using tables for layout?

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.
__________________
X-CART (4.1.9,12/4.2.2-3/4.3.1-2/4.4.1-5)-Gold
(CDSEO, Altered-Cart On Sale, BCSE Preorder Backorder, QuickOrder, X-Payments, BCSE DPM Module)
Reply With Quote
  #33  
Old 07-13-2010, 04:09 PM
 
Sisom Sisom is offline
 

eXpert
  
Join Date: Sep 2006
Posts: 310
 

Default 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.
__________________
X-Cart Gold Version 4.3.2
Reply With Quote
  #34  
Old 07-13-2010, 04:15 PM
  ARW VISIONS's Avatar 
ARW VISIONS ARW VISIONS is offline
 

X-Man
  
Join Date: Jan 2007
Location: Pensacola, FL
Posts: 2,536
 

Default 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.
__________________
xcart 5.1.2
Reply With Quote
  #35  
Old 07-13-2010, 05:33 PM
  gb2world's Avatar 
gb2world gb2world is offline
 

X-Wizard
  
Join Date: May 2006
Location: Austin, TX
Posts: 1,970
 

Default 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.

Quote:
you couldn't put a background image around the individual product boxes
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.
__________________
X-CART (4.1.9,12/4.2.2-3/4.3.1-2/4.4.1-5)-Gold
(CDSEO, Altered-Cart On Sale, BCSE Preorder Backorder, QuickOrder, X-Payments, BCSE DPM Module)
Reply With Quote
  #36  
Old 07-14-2010, 07:13 AM
 
Sisom Sisom is offline
 

eXpert
  
Join Date: Sep 2006
Posts: 310
 

Default 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!


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
__________________
X-Cart Gold Version 4.3.2
Reply With Quote
  #37  
Old 07-14-2010, 08:44 AM
  ARW VISIONS's Avatar 
ARW VISIONS ARW VISIONS is offline
 

X-Man
  
Join Date: Jan 2007
Location: Pensacola, FL
Posts: 2,536
 

Default 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?
__________________
xcart 5.1.2
Reply With Quote
  #38  
Old 07-14-2010, 09:08 AM
 
Sisom Sisom is offline
 

eXpert
  
Join Date: Sep 2006
Posts: 310
 

Default 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.)
__________________
X-Cart Gold Version 4.3.2
Reply With Quote
  #39  
Old 07-14-2010, 09:12 AM
  ARW VISIONS's Avatar 
ARW VISIONS ARW VISIONS is offline
 

X-Man
  
Join Date: Jan 2007
Location: Pensacola, FL
Posts: 2,536
 

Default 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!!!!!!!!!!
__________________
xcart 5.1.2
Reply With Quote
  #40  
Old 07-14-2010, 09:25 AM
 
Sisom Sisom is offline
 

eXpert
  
Join Date: Sep 2006
Posts: 310
 

Default 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.
__________________
X-Cart Gold Version 4.3.2
Reply With Quote
Reply
   X-Cart forums > X-Cart 4 > Dev Questions > Changing design



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -8. The time now is 07:59 AM.

   

 
X-Cart forums © 2001-2020