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

Four card features using Vs code

@valchiz•150
@yemmighto
A solution to the Four card feature section challenge
View live sitePreview (opens in new tab)View codeCode (opens in new tab)
Code
Select a file

Please log in to post a comment

Log in with GitHub

Community feedback

  • P
    Tomislav Šuto•260
    @RetroApe
    Posted 9 months ago

    Hi Valchiz.

    I see you did a good job matching the layout. I also noticed you used border-top to mark each card with its own color. I actually didn't think of that. I used linear-gradient for that:

    background: linear-gradient(
            var(--cyan) 2%, /*this is where you change color*/
            white 2%
        );
    

    Shadows could use some amplification. Something like

    box-shadow: 0px 10px 30px 0px hsla(180, 62%, 55%, 0.55);
    

    I would advise against setting height and width on the main element. It will automatically make your layout unresponsive. Otherwise:

    • container doesn't stay in the center of the screen when you scale the window down (because it is staying in the center of the main, which went off screen)
      • other elements also behave in similar way
    • you will essentially be making your life difficult because you will have to make more @media queries than is necessary

    When I removed width and height on main, your .p-words element started behaving strangely. I saw that you centered this element by putting 450px on the left and right side of the margin. Centering elements horizontally is usually done by entering auto on both sides of the margin.

    p-words element should have a maximum width. It will still make the element responsive if the width of the screen becomes smaller than it.

    max-width: 55ch;
    

    I used ch, which is a unit for characters. It essentially makes your paragraph have a line no bigger than 55 characters. I think this is pretty cool.

    min-width and max-width is generally better to use on most elements because it will keep your elements respond to size reduction/expansion.

    I hope I helped a little bit and didn't make my explanations confusing :)

    Best of Luck!

    Marked as helpful
  • P
    Tomislav Šuto•260
    @RetroApe
    Posted 9 months ago

    I am glad my feedback helped you.

    Usually, you never set height, at all. If you set a height on an element, it will most often make it unresponsive.

    You never set width on a <header>, <body>, or <footer>. It makes your site immediatelly unresponsive.

    I personally use Dev Tools on Chrome to check how my site functions, but people say Firefox is better.

    For Chrome:

    To open dev tools, just go to you site (or any other) and press shortcut: Ctrl + Shift + C. Use the same shortcut to hover over an element on your website and preview its width, height, padding, margins, or click it and you can check it's properties on the right.

    You can turn off properties or change values to see how your site behaves. You can also change width and height of the viewport to see how your site behaves.

    Try selecting <main> element end turn off height and width and see what happens.

    ...

    I mean, it is hard to explain these things with just words. Here, watch this video to learn how Dev Tools function. The video helped me, and it is not long like some other videos.

  • @valchiz•150
    @yemmighto
    Posted 9 months ago

    I really appreciate your feedback, I really don't know how to make use of the linear gradient part yet but will try to figure it out.

    about the height and width on main element, which make it unresponsive, where can I apply the height and width to make it responsive since I divide my work in sections.

    the max width character really help a lot and also the shadow part, it really help

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

Oops! 😬

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

Log in with GitHub