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.