Skip to content
  • Unlock Pro
  • Log in with GitHub
Solution
Submitted over 2 years ago

Responsive Product Card with CSS Grid

Muhammad Nur Ali•50
@mnalii
A solution to the Product preview card component challenge
View live sitePreview (opens in new tab)View codeCode (opens in new tab)

Solution retrospective


This is my first challenge submission. Feel free to give any feedback and advice. I am still confused converting the line-height value in figma to CSS unit as i am not quite sure what unit value in figma( for example the value in line height only showed 32 in figma, is it in 32px or another unit value? ). Also, anyone knows converting the value of paragraph spacing from figma into css properties/value ?

Code
Select a file

Please log in to post a comment

Log in with GitHub

Community feedback

  • PhoenixDev22•16,830
    @PhoenixDev22
    Posted over 2 years ago

    Hi Muhammad Nur Ali,

    Congratulation on completing your first frontend mentor challenge.

    Great work on this challenge ! I have some suggestions regarding your solution if you don't mind:

    • In my opinion, Add to cart is much likely to be a <button> with type="submit" instead of <a>, in a <form>. To know when to use one or the other in a specific situation, you must understand that every action on site falls under two different categories:

    1. Actions where users affect the website’s back-end or front-end.

    2. Actions where users won’t affect the website at all.

    Action where users affect the website itself is where you use a button. For example, sign-up and purchase actions are often buttons. The user in these situations are creating a new account and completing a monetary transaction, which are actions that affect the website’s back-end. Creating new posts or making comments are actions that change a website’s content and what the user sees.

    Actions where users won’t affect the website are where you use a link. These actions that take users from one page to another without changing anything on the website’s back or front-end.

    • In my opinion, the image is an important content. As you have used CSS for the image, it’s not accessible anymore. The only method that is truly accessible and supported by nearly all browsers is to use inline images instead of background CSS images to display non-decorative content.
    • I recommend to use <picture> tag in HTML to specify image resources. The <picture> tag contains<source>and <img> tags. This way the browser can choose the image that best fits the current view and/or device. If you have a small screen or device, it is not necessary to load a large image file. The browser will use the first<source>element with matching attribute values, and ignore any of the following elements.
    • In HTML, the <del> tag is used to identify text that has been deleted from a document but retained to show the history of modifications made to the document. Strike through is a CSS property and does not carry any semantic meaning as inserted or deleted for screen readers. For screen reader: <del>deleted indicates text removed. In this instance, the two prices are read out which can be confusing.
    • The cart svg in the button is a decorative svg. For decorative svgs , you set an aria-hidden=”true” and focusable=”false to remove that element from the accessibility tree. This can improve the experience for assistive technology users by hiding purely decorative images.
    • There are so many arguments against setting the root font-size: 62%it state that you should never change the root font size because it harms accessibility.
    • You should use object-fit: cover; to the image which sets how the image should be resized to fit its container. object-fit: cover; maintains its aspect ratio while filling the element's entire content box.
    • line-height: 2.3rem;Use a unitless line-height value to Avoid unexpected results. You can read more in mdn
    • To set letter spacing with CSS, use the em measurement unit.
    • Remember a modern css reset on every project that make all browsers display elements the same.

    Overall, great work! hopefully this feedback helps.

Join our Discord community

Join thousands of Frontend Mentor community members taking the challenges, sharing resources, helping each other, and chatting about all things front-end!

Join our Discord
Frontend Mentor logo

Stay up to datewith new challenges, featured solutions, selected articles, and our latest news

Frontend Mentor

  • Unlock Pro
  • Contact us
  • FAQs
  • Become a partner

Explore

  • Learning paths
  • Challenges
  • Solutions
  • Articles

Community

  • Discord
  • Guidelines

For companies

  • Hire developers
  • Train developers
© Frontend Mentor 2019 - 2025
  • Terms
  • Cookie Policy
  • Privacy Policy
  • License

Oops! 😬

You need to be logged in before you can do that.

Log in with GitHub

Oops! 😬

You need to be logged in before you can do that.

Log in with GitHub

How does the accessibility report work?

When a solution is submitted, we use axe-core to run an automated audit of your code.

This picks out common accessibility issues like not using semantic HTML and not having proper heading hierarchies, among others.

This automated audit is fairly surface level, so we encourage to you review the project and code in more detail with accessibility best practices in mind.

How does the CSS report work?

When a solution is submitted, we use stylelint to run an automated check on the CSS code.

We've added some of our own linting rules based on recommended best practices. These rules are prefixed with frontend-mentor/ which you'll see at the top of each issue in the report.

The report will audit 1st-party linked stylesheets, and styles within <style> tags.

How does the HTML validation report work?

When a solution is submitted, we use html-validate to run an automated check on the HTML code.

The report picks out common HTML issues such as not using headings within section elements and incorrect nesting of elements, among others.

Note that the report can pick up “invalid” attributes, which some frameworks automatically add to the HTML. These attributes are crucial for how the frameworks function, although they’re technically not valid HTML. As such, some projects can show up with many HTML validation errors, which are benign and are a necessary part of the framework.

Oops! 😬

You need to be logged in before you can do that.

Log in with GitHub