Frontend Mentor Product Preview Card Component solution

Frontend Mentor Product Preview Card Component solution

In this post, we will review the Frontend Mentor Product Preview card component challenge solution we built.

Frontend Mentor is a platform that hosts challenges for front-end developers to improve their coding skills by building real projects. If you’re just interested in the solution, you can find it by clicking on the following URL: https://github.com/OnlineBlogZone/FrontendMentorProductPreviewCardComponent

If you want to learn more about Frontend Mentor, you can find their website here: https://www.frontendmentor.io.

Like the QR code component we explained in a previous post, the Product Preview Card challenge is also targeted to beginners. This challenge involves building a “card” which contains a product image on the left and product details on the right side. While still a beginner challenge, it does tackle both different and similar topics. This blog post is therefor using a similar structure.

Starting with a Vision

Every successful web development project begins with a clear vision. In this case, I had both a mobile and desktop design image that served as my guide. This is by no means a perfect way to design, usually you would want to have access to an actual design file in order to see the marges and different sizes of elements.

The first step was to envision the skeleton HTML structure based on this image. This involves identifying the major sections and their relationships within the component. Let’s break down the component’s structure.

The HTML Structure

Our Product Preview Card Component consists of two main sections, a big product photo, and the product details. Inside each section, we have various elements. The product photo section contains:

• The image element

The product details section includes:

• A heading <h1> indicating the product name
• A category label <p> to indicate the category the product belongs to
• A paragraph <p>  for the product description
• The current and the previous price
  • The current price is a <span>
  • The old price is a <s> which is the semantic element for strikethrough
• A CTA (Call-To-Action) button
  • The CTA button has an icon for presentation

Embracing Semantic Elements

I used semantic elements to give the structure meaning and clarity. Semantics are important because they help search engines and other devices with determining the importance and context of web pages.

In my HTML, the <main> element wraps the entire content, while the <section> element are is to divide the content into meaningful blocks. Additionally, the use of appropriate headings (<h1>) and paragraphs (<p>) enhances the document’s semantics and accessibility.

One important thing to note here, is that my image banner is contained within a <div> instead of a <section>. Sections require a heading to be completely semantically valid. Since the image portion of the design doesn’t include a heading or any text whatsoever, the better choice here is to use a <div>.

One could also argue that the banner image should get a role="presentation" so that screen readers ignore the image. In this specific case, where it’s about a product, it’s entirely up to you whether you think of it as eye-candy or important. For me personally, I choose to not have it as a presentational element since it gives readers a clear vision of what their product will look like.

Correctly using these headings and paragraphs is key for both search engine optimization and accessibility. Blind people who use a screen reader need these headings in order to get correct information about the content.

Another important thing to note is the use of aria-hidden="true" on the CTA button icon. The icon is eye-candy. That’s the only role it serves, so for screen readers, which only need to know the content, using aria-hidden="true" hides the icon so the screen reader won’t read them out load.

This might seem like a very minimal impact thing but since screen readers read out everything, it can very quickly become a big mess if not taken into account.

Applying the BEM Methodology

BEM stands for Block Element Modifier and is a popular naming convention for CSS classes that helps in creating maintainable and scalable code.

Block Level

I started by defining the main component as the “component” block. This represents the highest-level container for our component. Inside this block, I added sub-blocks for the “banner” and “content” sections. Each block is defined with a unique class name (e.g., “banner-container” and “content”).

Element Level

Within each block, we have elements. For example, inside the “banner-container” block, we have the “image” element. Inside the the “content” block, we have “heading,” “category,” “description,” “pricing,” and “button” elements. Each element is named with a double underscore (__) to separate it from the block name. This is true except for the “pricing” and “cta” blocks. This is because they have their own nested elements that follow the same principle again. “cta__text” for example.

Modifier Level

The BEM methodology also allows for modifiers. For modifiers you can think of something which adjusts the normal look of an element. A simple example would be buttons. You could have the following HTML:

<button class="button button--red"/>
<button class="button button--green"/>

In the example above, our shared styling which both buttons use, is in the “button” class.

Inside the button--red and button--green class we could have background-color: red; and background-color: green; respectively.

Implementing the modifier logic within the “pricing” block, we get classes like “pricing–current, and “pricing–old” to distinguish different price states. Modifiers are prefixed with double hyphens (--).

Making It Responsive

A responsive design is a crucial aspect of modern web development. To make our component responsive, I utilized media queries. For screens with a minimum width of 480px, the component changes its layout. The banner and content sections expand horizontally and adjust their sizes accordingly.

I chose 480px opposed to 1024px, which I used in Frontend Mentor Results Summary, to let tablet devices follow the desktop designs. The Product Preview Card looks great on tablets following the desktop design, which is what made me decide on using this specific breakpoint value. If it looked like it didn’t work well, I would’ve opted to use the mobile layout on tablet.

Colors and Fonts

In the CSS, I defined custom colors using CSS variables. This makes it easy to maintain a consistent color scheme throughout the component. I also imported a custom font from Google Fonts to give the text a unique style.

Conclusion

Building a frontend component like the Frontend Mentor Product Preview Card Component requires careful planning, a structured approach, and attention to detail. By starting with a clear vision and  embracing semantic HTML elements you can create a clean, maintainable, and responsive component which will make your development process more efficient.

While BEM does make code more maintainable and scalable, it is still an optional tool. There are many other ways to tackle this challenge. Using BEM is just one of them.

No matter if the exercise is easy, difficult, small or large, if you keep to a clear overview and structure it’s usually easier to reach your goal without forgetting parts of the project.