Skip to content
  • Unlock Pro
  • Log in with GitHub
Solution
Submitted over 1 year ago

Four card feature section - No framework - Only CSS

P
Thomas Dimnet•250
@tdimnet
A solution to the Four card feature 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?

Hey, thank you for reading this!

I started to use clamp css function. For a long time, I also used pixels and pourcentages instead of REM. I'm not fully happy about my skills even though it looks okay. I'm probably going to follow one or two courses before reworking on my projects.

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

Most of the time, my challenge are related to choosing the right unit and how to display the more pixel perfect with the less amount of CSS.

I read a few stuff on web.dev: it's a great ressource but I'd like to find other ressources.

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

By giving me advice about my use of CSS unit. Should I use for example ch instead of pourcentages, em, or rem?

Thank you for passing by, Tom.

Code
Select a file

Please log in to post a comment

Log in with GitHub

Community feedback

  • Neil•140
    @neildeo
    Posted over 1 year ago

    Hi Tom, think you've done a great job here and shouldn't be too hard on yourself! The design looks great at desktop and mobile sizes (although you might want to change it at intermediate sizes as the cards look a bit strange on screens of ~1000px, but that's a matter of opinion...).

    Regarding your question about units, I can give some advice but only as another newbie! My understanding is that for any text element or container of a text element, it's best practice to use rem. This is because individual users can edit the text size in their browser by changing the pixel/point value of 1rem. So text on your page needs to be sized in rem, so that users can customise its size to their preference. As a consequence, any block element containing text should also be sized in rem so that your layout looks consistent regardless of the font size selected by the user. Don't forget that you can set the pixel value of 1rem in the :root selector (it defaults to 16px I think): so you can set your whole page up just using pixels, and then at the end go through and convert those all to rem by just dividing by the value of 1rem!

    While the text itself should be sized using rem, I like to use the em unit for top padding and margins (NOT inline!), as by setting a single value of em (for example in the body CSS selector), the spacing looks good (i.e. big headings have more space around them than small paragraphs). I like to use ch for setting a width to a container which holds text which I know I want to take up a certain number of lines (in fact, usually a min or max width, so the container can be automatically responsive within certain screen sizes). Percentages are useful when you know how big you want something to be relative to its parent, e.g. you have an image which you want to take up half the width of its container. I also think it's absolutely fine to set image dimensions in pixels: the raw file probably has an intrinsic pixel width, and they are usually decorative elements anyway, so it doesn't matter too much if the user can't enlarge them. But you may want to consider how they affect your layout: in order to keep the layout consistent, if everything else is sized with relative units (rem, em, ch, ...) then the images also need to use these units to stay in sync with the rest of the page.

    As for resources, I really recommend Kevin Powell's videos on YouTube, especially this one on responsive design. Hopefully it will help you understand how to make use of natural CSS behaviours to easily make responsive pages with minimal code! I really recommend his other videos too, they've been incredibly useful in my journey of learning HTML and CSS.

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