I spend a lot of time writing HTML. It’s been a part of what I am doing every day for more than a decade. For me, HTML is more than just a few elements that you throw here and there; I invest a lot in picking the elements that I use. While I was reviewing the exercise, I stopped in front of the “Add to Cart” button. It was an <a> tag with a link. I started questioning myself; part of me hates the fact that this is a link not a button inside a form. It makes perfect sense to be a button. Of course it can be made anything. Simply attaching a listener that fires an ajax request updating the cart will work. But it doesn’t feel right. This isn’t semantically correct. Before I decide what the “Add to Cart” element should be, I decided I should write down the criteria addressing how this element should behave given all the possible circumstances.
- If there are other fields like “amount,” pressing enter (submitting the form) should behave like clicking the button.
At this point I was convinced that this should be a submit button not a link. I quickly realized that this will require each product card to have a form tag with more elements like hidden input with product id for example. In big shops, the home page sometimes hosts a lot of product cards. It even uses sliders to save the space for “Newly arrived,” “Hot offers,” “Hot in category X” and the list can go on. A single page can contain more than a hundred of product cards. All this increase the amount of the HTML tags we serve to the user and increase the page size (comparing to serving a single <a> tag per card).
There is also another problem the submit button doesn’t address and it is very common. It’s the products that need you to select attributes before adding it to your cart (like shirt size or color). It’s common that these product cards redirect the user to the full details page of the product asking him to pick the required attributes in order to add the proper item to the cart. Now I changed my mind; I don’t think it’s a problem using a link for this functionality. I decided to change the first rule I mentioned earlier; it shouldn’t have the same behavior. It just should work in a way.
The available scenarios
- Semantically, it is more accurate.
- Require more code for form tag and other elements that identify the product.
If the product cannot be added without selecting attributes, use an anchor tag linking to the full product details page.
- Requires less HTML, just a link with data attribute for product id.
How other e-commerce platforms address this issue?
I decided to review how the other popular e-commerce platforms address this issue. At robusta, we have success stories building successful big e-commerce platforms in Egypt using popular platforms like WooCommerce and Magento Enterprise Edition. I picked the popular open source e-commerce platforms available which provided a demo and a default theme. Now, bear in mind that the result of this analysis is highly based on the used theme. If you are using a different theme it is very likely that your theme uses a different markup than what I am about to show you. The default theme is important because developers use it as a boilerplate for their themes. Some platforms like Magento allow defining a parent theme and extend it to override some of its parts instead of writing everything from scratch.
This is an obligatory mention to the e-commerce dinosaur. From the minute you check the demo you get the feeling that you stepped back in time into PhpNuke. osCommerce doesn’t include an add to cart button in the listing. Adding the product to the cart is only available inside the full product details.