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

3 column preview card component

accessibility, bem
Musicalaudio•160
@Musicalaudio
A solution to the 3-column preview card component challenge
View live sitePreview (opens in new tab)View codeCode (opens in new tab)
Code
Loading...

Please log in to post a comment

Log in with GitHub

Community feedback

  • P
    Jeff Guleserian•500
    @jguleserian
    Posted over 2 years ago

    Musicalaudio,

    I loved the organization of your HTML, in fact, I organized my in a similar way. I noticed from your screenshot that the overall styling does not match up with the model, so I dived into both of your CSS stylesheets. I also took a look at your README file, but it was still in its template form.

    Looking at your reset CSS, I noted that it was very thorough, in fact, it defined a lot of things that were superfluous for this project. I guessed that the stylesheet is a standard template you use or borrowed from somewhere else. I admit that many of those settings are foreign to me, so in my observations below, keep in mind that I may have missed or misunderstood something in either of your 2 stylesheets.

    1. I saw some properties, such as "place-content," that I did not know were CSS properties or used with CSS grid.
    2. I noticed that you set the <main> to display as a grid, but no further delineation as to what would regulate the height or width, either in the definition of columns/rows, not in the individual items. I suspect this is what left the container dimensions to form to the content and not the content conforming to the container dimensions.
    3. I couldn't see a global reset of your "rem," so I assumed that you kept it to the standard 16px and created two variables to deal with the two font sizes: var(--fs-base) and var(--fs-h2). While this worked for the fonts, it still seems like it would be more difficult for the rest of the measurements, like for padding, margins, gaps, etc. I wonder if resetting the rem to, say, 10px, in the <html> or <body> would make all measurements standard and easier to calculate throughout.
    4. I didn't see the font on the button change to color of the background during the hover effect.
    5. I liked the way you tried so many things, such as the easing in/out during the hover transitions and the systematic and thorough way you created the variables.
    6. Your html was easy to understand and had effective structure.

    Anyway, keep up the good work. I don't know if my comments are helpful or not, or if they even understood some of what you did, so take the ones that help and discard the ones that don't. Thanks for posting your solution and letting me take a look.

    Happy new year!

  • P
    Jeff Guleserian•500
    @jguleserian
    Posted over 2 years ago

    @Musicalaudio Thanks for the follow up! It's dialogues like this that help me learn so thanks for giving me your rationale. I find it interesting that, after giving you this feedback, someone also critiqued me on using the font-size reset (62.5% rule). I was concerned because in one of my courses, this was seen as a common or best practice. I was given a couple of sources to look at, including the one you supplied. Anyway, I did some research on my own and found that the critique of this rule, like many things, also has its own critics. What I found out was that if done correctly, most, if not all of the objections disappear, and one receives all the benefits of the rule (easier to read and write the code with less wacky conversions) without the detriments. Here is how the rule could be done to avoid issues:

    1. Set the font size to 62.5% in the <html>, then...
    2. Set the font size to back to 1.6rem in the <body>

    What results is:

    • standard font size returns to 16px and finicky plug-ins, etc. still function properly
    • the initial html content (before you style it) looks like it would have if you didn't use the rule
    • any time you deviate from the default, eight er size a container, img, etc., you can use the easy (and understandable) conversion with rem
    • the unit "em" will also remain consistent as it did before However, the only objection that I can see that is insurmountable is that if you are working on a team and that team does not use this rule, then you would have to adapt. However, I really don't see this as an issue since the reverse would also be true, i.e., that you have to adapt the other way if they DID use the rule. I'm still a neophyte, so I don't really know the industry that well, so if you get any additional insight or have any other thoughts, I would love to hear them. Meanwhile, I will probably continue to use the rule for now and see if I run into any problems. If so, I will be sure to post something. Happy coding, my Friend! Thanks again for the response. Jeff

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