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

Blog preview card made with semantic HTML and CSS

Outstandinggirl13•70
@Outstandinggirl13
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?

Learning Progress:

  • Worked with a high-quality Figma design file, which helped me achieve near pixel perfect accuracy.
  • Improved coding skills and understanding of BEM methodology.
  • Used meaningful names for elements.
What challenges did you encounter, and how did you overcome them?

Development Insights:

  • Encountered and resolved issues styling the preview image.
  • Used flexbox to center the image.

Responsive Design:

  • Implemented a clamp() function for dynamic width adjustments between mobile and desktop views.

HTML Enhancement:

  • Wrapped the publication date in a tag for better accessibility.
Code
Select a file

Please log in to post a comment

Log in with GitHub

Community feedback

  • P
    Levi•230
    @law973
    Posted 9 months ago

    Hey there! The solution looks really good. There are a couple of things worth considering. I'll preface this by saying that my comments can get long and I usually focus more on what could be improved than on what was done well, but I do that because I like everything else I've seen.

    Without further ado, and in no particular order:

    • The card should use either an article tag or a div (probably the former with the section tags being used), and the main tag should go around the card; the main tag contains that which is considered to be the "main" content, and normally would not be tied to a specific component on the page.
    • I am not sure that h2 is the best choice for the author name when something else (like p or span) could be used instead, since a heading is meant to be part of a "table of contents" of sorts and have content that follows it.
    • On the topic of headings, the usage of h1 might not be the most appropriate either. If this component was part of an actual page, there would probably be other cards/previews, and this preview card would not be using an h1, of which there should only be one per page. I believe h2 would be more appropriate. (Having said this, heading levels should normally not be skipped either.)
    • The alt text for the blog component image could perhaps be more descriptive in regards to what is being visually portrayed, but I'll admit I'm unsure about this. I have been told that for decorative images (such as background decorations) the alt should be left blank (alt=""), and there's not a whole lot of information that the blog image happens to provide outside of visual appeal.
    • When the footer has position: fixed, it's noticeable (albeit at very small viewport widths) that it isn't centered and stays to the left. In situations where elements have this type of positioning, here's a trick to keeping them centered horizontally:
    left: 50%;
    transform: translateX(-50%);
    
    • Using clamp() for font sizes to make them change dynamically along with the card is an option that could be considered. This would also have the bonus of removing much of the media query at the end and trimming up the code quite a bit.
    • The challenge mentions being able to see hover and focus states for interactive elements, so I would consider using :focus on the blog article's title (though many people don't seem to bother with this sort of thing, so it might just be me).
    • At the moment I'm fond of using the font shorthand, where the font-weight, font-size, and line-height can be specified in one line (though the font-family must be declared there as well). (Perhaps it's not the best for readability, or there's a technical drawback I'm unaware of, but I think it's worth mentioning!)
    • If the card is set to start and stop growing in width at the right times, then I believe that the width could be moved outside of the media query and the max-width values could potentially be removed (and combined with using clamp() for font sizes, this would remove the need for that media query altogether).
    • Adding a top margin to the card would give it some space from the very top of the page on certain viewport sizes, which would look nicer.
    • The style guides typically mention making the solutions compatible with screen widths as low as 320px, and here the card goes beyond the screen at that point. Keeping this in mind with the usage of max-width or side margins may be a good idea for future solutions.
    • It is my understanding that for accessibility, it's good to aim for making things visible/useable up to a 200% zoom, and at narrower screen sizes too. If you ever want an extra challenge, try this out sometime.
    • Since the Frontend Mentor link opens in a new tab, consider including a hidden span for accessibility purposes, something like this:
    .sr-only {
        border: 0 !important;
        clip: rect(1px, 1px, 1px, 1px) !important;
        -webkit-clip-path: inset(50%) !important;
        clip-path: inset(50%) !important;
        height: 1px !important;
        margin: -1px !important;
        overflow: hidden !important;
        padding: 0 !important;
        position: absolute !important;
        width: 1px !important;
        white-space: nowrap !important;
    }
    
    Challenge by <a href="https://www.frontendmentor.io?ref=challenge" target="_blank"><span class="sr-only">(Opens in a new tab)</span>Frontend Mentor</a>.
    

    I like that the card link actually goes to a page with information on HTML and CSS. You did a good job on matching the design screenshots. I also like how thorough the README file is (those Figma shortcuts might come in handy). Please don't be discouraged by the amount of things I mentioned; there's always a lot to learn and not too long ago I didn't know any of these things either. I need to update my own solution actually.

    This ended up being longer than even I thought it would. I think I'm done commenting today...

    Marked as helpful
  • M Asim Saeed•290
    @asimsaeed353
    Posted 9 months ago

    Very accurate and outstanding design!!

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
Frontend Mentor logo

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