There are multiple ways to accomplish this. One could be using mootools are jquery. That is currently what I use on our website: http://www.medsupplier.c...dick-atria-3100-ekg.aspx

"Overview" and "Specs" are tabbed from the Long Description and "reviews" is added as the next tab by itself (I have yet to theme it). Its really easy to do.

It really depends on what you want tabbed as well. I choose only to tab content.

We have a tabbed control available for that purpose.

Here is an example,

http://www.jimslimstools...-2pc-Cordless-Combo-Kit-(Hammer-Drill-and-Recip-Saw)__DC2PAKCA.aspx

It's probably just a CSS change to make the content show when JavaScript is disabled. Even if you can't see it, the search engines still can; the text is still on the page. I wouldn't worry about users not having JavaScript enabled; if they don't, they can't buy anything on your store anyway. :)

Most merchants seem to use BV's one-page checkout, and that one does not work well without JavaScript since the shipping rates are calculated via AJAX as you enter your address. If the customer clicks the Place Order button after entering their address, the rates will be calculated, but that's a pretty unlikely action for a customer to take without seeing the order total. My guess is that the BVC2004 checkout works better with JavaScript disabled.

Best thing to do is open up firefox and grab the "Noscript" plugin. Browse stores and test with it enabled (which means jscript disabled).

Ok, I can see the issue now. However, this can probably be solved very easily by making a link to a "review order" page that only appears when javascript is disabled. The 2-3% of people browsing the web with javascript disabled are well aware that they will run into sites with limitations (as well as sites that don't work altogether).


BTW - I noticed the other checkouts in the project, but I still haven't found the place where you can switch between them....any ideas?







Thanks for the tip.





I am looking into using XML and XSLT to form the product HTML (and thus the tabs), rather than putting HTML tags in the database (which I tried and discovered it is not a good thing). I am using XML and XSLT in my current store and it works very well, but it is limited in that you cannot put ASP.NET functionality into the content (I am looking into working around this limitation, too).
Here are some examples of what I did on our current store. Everything between the "Add To Cart" button and the "Did You Know..." section is in XML and as you can see, the types and structure of the information within can vary widely. Eventually, I plan to migrate to a tabbed interface on these pages, too.
http://www.shuttercontractor.com/products/louver-shutters/vinyl-shutters/custom-made-shutters/mid-america-L1.aspx
http://www.shuttercontractor.com/products/exterior-shutter-accessories/mid-america-14-round-arch-top-custom-louver.aspx
http://www.shuttercontractor.com/p/stylecraft-sc-custom-louvered-shutters-traditional.aspx
XML is very flexible and different sections that apply to different products can be added easily and made optional so they can be omitted from products that they don't apply to, and using XSLT helps to seperate the content from the markup so you can change the markup without having to edit a single database record. I am thinking about taking it a step further this time and storing the XML on the web server rather than in the database so the content can be compared and changed more easily using the Find and Replace functionality in Visual Studio. Then the only thing that needs to be in the product record is the file name of the XML file.
However, I already put the tabbing functionality into the new store as you can see here: http://www.foldingchairdepot.com:8080/p/Cosco-Steel-Folding-Chair---Set-of-4---Black-Color__cos-1471005X.aspx. Now it is just a matter of solving the content storage issue, and that part is done.

Actually, if you think it through it is much better to load a local file on the web server than it is to do a network hop and pull the content from the database. Whether you use an XML control to do the transform or manually code it, the transformation all happens on the web server so the XML file doesn't actually have to be downloaded to the browser. The overhead is the same as loading any other local text file + the overhead it takes the XML engine to do the transform.


As for cross-selling and OOTB features, there is plenty of room for them to co-exist with the XML driven tabs, since using Simple Tabs the only requirement to create a tab is the following:





So from a .NET perspective, the code must create a header tag and a div tag, but the code that creates each tab could be from different controls, hand-coded markup, injected html, or even from an XSLT. If tab order is critical, there is always the option of creating more than one XSLT and loading different content into different tabs that stagger the ones created with .NET.


Admittedly, XSLT files are more difficult to create than they are to maintain over time, but since I already have a working sample I can use it as a template to create the new file(s). I know from experience that trying to maintain html markup along with the content in the database can be difficult and can limit your ability to change the product page later.