Skip to content
  • Unlock Pro
  • Log in with GitHub
Solution
Submitted 4 months ago

Responsive Testimonials using Grid and media queries

Gabriel Rodriguez Perez•160
@glrodriperez98
A solution to the Testimonials grid section challenge
View live sitePreview (opens in new tab)View codeCode (opens in new tab)

Solution retrospective


What are you most proud of, and what would you do differently next time?

I'm most proud of how I used CSS Grid with nth-child selectors to precisely position each testimonial card across multiple breakpoints. It was really satisfying to see the layout adapt fluidly across devices, from mobile to widescreen. I'm also proud of how I used em units for breakpoints to improve accessibility and scalability of the layout.

If I were to do this challenge again, I would spend more time organizing and reusing utility classes to reduce redundancy in my CSS. I might also experiment with using clamp() for more fluid typography and spacing. I played with it last challenge but want to dive further into the concept.

What challenges did you encounter, and how did you overcome them?

One of the biggest challenges was getting the grid layout to match the design at different screen widths, especially for the tablet and desktop breakpoints. Using grid-template-areas at first felt limiting, so I leaned into manual grid positioning with nth-child, which gave me finer control.

I also had trouble applying a semi-transparent box-shadow using HSL with CSS variables. I learned that to interpolate (a new word for me!) an alpha value into an HSL color, the custom property must be defined without the hsl() wrapper, just the raw values. While I simply used the :root value I created instead, I'm going to try this with the next challenge that uses box-shadow.

What specific areas of your project would you like help with?

I'd appreciate feedback on:

My use of em units for media queries...are there best practices for choosing the base value?

Whether my grid positioning using nth-child is maintainable or if there’s a cleaner way to handle this for large-scale layouts.

How I could improve my utility class naming or structure for scalability and clarity.

Code
Select a file

Please log in to post a comment

Log in with GitHub

Community feedback

  • Christian Gabriel Lara López•80
    @chrislara01
    Posted 3 months ago

    Great work! Here are some tips that I think that could improve your solution:

    • Line height: Looking at the text, looks that you could use some more line height using this exact CSS property line-height to separate the lines of the paragraph element in the testimonial cards.
    • Box Shadow: Since box shadows often are very subtle I tent to use rgba(0, 0, 0, 0.1) or where the first values are the RGB part indicating a black color and the last as a opacity value, being 1 full opacity and 0 transparent. To match the design seems like there is a lot of displacement in both right and bottom values and blur radius that I think that are missing. You could also play with smaller offset values and using the spread radius (fourth parameter).

    On feedback:

    • Using em values for media queries is a very standard and used approach so this was a great use of them!
    • Your approach to the grid positioning was great! Often times may look complicated but sometimes it has to be.
    • Your approach to utility class naming was great!

    This was an excellent solution! Hope this helps!

  • P
    j3dd3rs•90
    @j3dd3rs
    Posted 4 months ago

    Your design looks good! Well done on applying the different layouts using the media queries.

    Looking at your CSS, you can reduce the need for listing every single element and removing the margin with your universal selector (* {) instead.

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

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 all CSS, SCSS and Less files in your repository.

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.

How does the JavaScript validation report work?

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

The report picks out common JavaScript issues such as not using semicolons and using var instead of let or const, among others.

The report will audit all JS and JSX files in your repository. We currently do not support Typescript or other frontend frameworks.

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