CSS Styling of Product Table

I am not sure I follow you but I think you are saying you don't like the layout of the product listing...I hate it too! There are no restrictions or guidelines to keep your store looking organized.

Is there CSS templates to drop in to help with this sort of thing? I am no programmer so I need something that is just drag and drop...

Mark

Yes, this is sort of important. We can't style the tables at all since there are no classes available to style in the table used.

The theme_product_view function needs a serious overhaul, table use for layout is no good.

I've also made some changes to give make the "add to cart" link more visible, replacing it with an image (a button that says ADD TO CART) and putting it in the node body instead of in the links section.

Also, the cart, "ready to checkout" has been replaced with a button. I don't why it says "ready to checkout?" as it gives the buyer a reason to reconsider. Basic salesman psychology says: once the customer is about to commit, don't give him a reason to doubt!

I have blix theme installed in a 4.6 and product node view (ie. what is output to the browser) does not use tables as far as I have seen. But I look at the source and I do see theme_product_view_collection(). In what context is that called? Is it being overridden by something in my installation, or is there a page I haven't seen...

As for the styling problem, a table does not necessarily need to be tagged to be styled. Say if a table sits in a div with the class="section", then you can use:

DIV.section TABLE {...}
DIV.section TABLE TD {...}

This is good practice.
.s

Except you should use lower-case when writing CSS and XHTML.

Regardless, tables shouldn't be used for layout. Since the rest of my site is standards compliant it bugs me the ecommerce components aren't so I'll have to rewrite parts of them.

Except you should use lower-case when writing CSS and XHTML.

My approach to style sheet mark up is based on this example from w3.org - http://www.w3.org/TR/REC-CSS2/sample.html

But I am not an expert and I'm interested in your reasoning. I typically use CSS for it's practical implications. So as long as my code is easy to maintain, and my sites are viewable in normal browsers and text-only browsers I tend leave it at that. Eg. I don't use validators.

Regardless, tables shouldn't be used for layout. Since the rest of my site is standards compliant it bugs me the ecommerce components aren't so I'll have to rewrite parts of them.

I didn't mean to give anyone the wrong idea, I agree with you on this. :-)

sime: This is not the right place to discuss writing standards-compliant code. However in response I can say that the list you referred to lists HTML 4.0 elements and HTML 4 can be coded upper-case, unlike XHTML which should be written lower-case to be compatible with XML standards. As for CSS, I am honestly not sure but I code lower-case as seems to be what most designers do. Anyway, if you want to discuss more, open a forum topic and email me and I'll post there.

Thanks for the pointer to XHTML v HTML4.

I think this thread should be closed or renamed. The original problem is essentially about styling untagged elements so perhaps "removing table layout" should be a separate issue.

I tried my proposed work-around today (#5), and it did not work out very well - so scratch anything I have said so far.

theme_product_view_collection() is what needs fixing. It is executed on the page www.example.com/products and by default it is a 3x5 table and can be configured differently in the code. It spits out the teaser into each cell.

short-term

As a short-term solution, shall I do a patch to add a class to the table? This will solve the original problem.

long-term

How do we this product list to look? solipsist, can you direct me to a "best practice" way of laying out inline elements so that they form a "grid" of sorts. Especially where the elements may vary in height - I've attached an example of my best attempt, but as you see the last column has a clustering effect. The only alternative is to fix the div height, but that is not a flexible solution.

Look forward to feedback.
Simon

Sorry, I uploaded .html but it's not viewable as that. Here is a link to view the example:
http://urbits.com/_test/inline_layout.html

Resize the browser and watch the last column.

I agree with this aproach.
And if you add something like
height : 10em; overflow : auto;
to your div css it gets rid of the stacking issue and provides a more tabular look. This probably isn't the 'correct' way but i hope it helps shows that this should probably be the way we output our products.

Of course this is all CSS so no code mangling needed to change the look for a site. Also, I'd probably wrap the divs in another div. This is common in most other drupal outputs and allows you to apply css to the group(outer border, background, who's to say :) )

I did a new example.
http://urbits.com/_test/inline_layout2.html

So if the content spills they get the scroll bar, but then they can always override that in the theme style sheet (eg. make the height 12em). Well, I agree this is a good approach, thanks nemclimdul!

Questions
1. Should I put the default style definition in cart.css?

2. Should I give each product div an id so that they are somewhat ready for dhtml manipulation. Something like id="pid_1"

My first instinct would be to say yes and yes. 2 also allows for custom styling on nodes. You could even write a nice little module to add a bit of styling to a specific item(s) like a 'new' logo or something through either css or dhtml. *adds a note to his personal wish list*

Here is a patch that changes theme_product_view_collection() so that it will display each product in a floating div. There are also some changes to cart.css to make this work.

I didn't go overboard, so there will be minimal visible difference for those who apply this patch, although they may need to modify the size of the product div. That said, I have also inserted some useful classes/ids for further use. Read on...

Modify box size

You may need to re-define the width and height of the product div. The default is 10em * 15em. Other than changing the values, you might want to make these pixels or percentages. So, either in cart.css or the theme style sheet, apply/change the following styles:

.ec_collection .product {
  /* for example... */
  width:50%;
  height:100px;
}

Additional tricks

You can define size, and other styles, by product type, eg:

.ec_collection .tangible {
  width:40px;
  height:20px;
  border:1px solid orange;
}

And for dhtml purposes as well as the styling of unusual individual products:

.ec_collection div#nid_2 {
  background:url(myfavorite.jpg) top right no-repeat;
  width:100%;
  }

Afterword
Note, this patch also chops the ?> off the end of product.module as per Drupal coding standards.

I was just investigating this issue, and I just wanted to note that the product list as shown by the snowboard-mag is not actually the /product page. They have actually created there own.

Other examples of this is fearlessliving.org which have there own online store to present their products.

In most upmarket stores they actually want to place the products exactly where they want them and not where the system puts them.

You can alway completely replace the /product page by just creating a new theme for "product_view_collection" and do what you want with it.

Actually schultkl has requested style tags so that modifications are not necessary in future jobs. He has confirmed that the snowboard site is indeed already modified.

As per my post at #11, to close this ticket, it is just a case of making a patch that adds classes to the table.

However, so far the support (well solipsist and neclimdul at least) is for the div approach. It's hard to argue against something that fills the space by default and can be altered using a style sheet rather than a hack on product.module.

Really, I believe this is heading us towards possibilities like this: http://demo.script.aculo.us/shop

This demo is very good, and I have been thinking how it could be implemented, but then again, I do not want another bluemarine theme, and I am not sure how well it is going to degrade.

Gordon.

I agree, that something like script.aculo.us would only be a contrib or theme because it is very specialised. Sorry, it was a misleading example in that sense.

Since this patch requires discussion, here's a alternative patch that simply standardizes the current table and allows the ticket to be closed. It adds a class to the table, an id to each td, and moves the styling to cart.css.

The other features could be considered as a feature request.

Thanks I have commited this to cvs