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

Responsive blog preview card made with css flexbox and media query

accessibility
P
Ishmael Sunday•250
@okayishmael
A solution to the Blog preview card 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?
  • Usually the blog card is line up with others. So I included s css scale transform for the card to increase in size when user hovers over the card to triggers that its interactive.

  • Knowing media query is big deal for me. Most of the the world's conversations are done via mobile phones. Being able prepare web app the is mobile friendly is huge.This means I am able to deliver content to people on the go all around the world.


@media (min-width: 500px){
    body{
        display: flex;
        justify-content: center;
        align-items: center;
        flex-direction: column;
        height: 100vh;
    }
    
    .container{
        width: 384px;
        margin-bottom: 1.25rem;

        &:hover{
            transition-duration: 0.5s;
            transform: scale(1.01);
        }
    }
    
}

I was also able to the follow for the first time:

  • configure git with user name and email
  • initialize repository
  • stage add and commit files
  • create a branch to edit card button link
  • merge the branch to the main repository
  • publish files
  • create gh page for live site
What challenges did you encounter, and how did you overcome them?

Configurating git with my username and email.

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

N/A

Code
Select a file

Please log in to post a comment

Log in with GitHub

Community feedback

  • P
    Kamran Kiani•2,780
    @kaamiik
    Posted 6 months ago

    Some notes:

    1. The .article-btn I think is a tag that not clickable because based on the design You do not have hover effects so It should be p tag. If you see this as a tag that is clickable you should use an a tag instead of button. Because It takes you to a new page.

    1. The first image is decorative and the second is an avatar and do not need alt and your alt should be empty like alt="".

    1. Your .attribution is a footer and should be outside the main as a sibling.

    1. Elements that have hover effect are interactive. So because you have hover effects for your h1 then It needs to be a or button. Now you have to choose between a and button. If the element take you to a new page It should be an a tag and If do an action like submit a form or add to cart then It should be a button. In your challenge you have h1 and inside the h1 you have to wrap it into a interactive element too.

    1. Try to use a proper CSS reset at the start of your CSS style. Andy Bell and Josh Comeau both have a good one. You can simply search on the internet to find them.

    1. Use min-height: 100vh; instead of height:100vh;. height: 100vh strictly limits the height to the viewport size, potentially causing overflow issues if the content is larger than the viewport. On the other hand, min-height: 100vh allows your element to grow in height if the content exceeds the viewport size.

    1. max-width: 90%; in percentage is wrong. It should be in rem unit. No need to min-width.

    1. Never limit your width and height in a container or element or tag that contains text inside. When you limit the width and height of elements containing text, you risk the text being cut off, overflowing, or becoming unreadable, especially on smaller screens or when the text dynamically changes. It's generally better to allow the container to adjust its size based on its content or set a flexible size that can adapt to different screen sizes and text lengths. You only need max-width here because it prevents elements from stretching beyond a certain point, keeping them visually appealing across different screen sizes. It ensures your design remains adaptive and doesn't get too wide on larger screens.

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