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

Mobile first Article Preview usint html, css and js

Bernard•195
@Bernardanxiety
A solution to the Article preview component challenge
View live sitePreview (opens in new tab)View codeCode (opens in new tab)

Solution retrospective


I feel like i don't entirely know how the social div was done. When the socials div appears on mobile version, the card's height changes like it wasn't done through position absolute but rather display: none;

On desktop size the arrow icon disappears from social div and as well, don't know how that was done so i just cheated it and did it through position absolute, but definitely not proud of that...

Looking on feedback on literally everything that Your eye catches so i can improve, thank You in advance!

edit: I see that my poor solution falls apart really badly when it's not at full size and the media query switches to desktop size at 700px, definitely looking for help with how to fix that.

edit v2: Instead of positioning the arrow that closes the socials div on desktop size with position: absolute, i just made the same button open and close it. Now i have a problem with keeping socials position in the same spot from 700px when it switches to desktop size to 1440px.

Code
Couldn’t fetch repository

Please log in to post a comment

Log in with GitHub

Community feedback

  • Elaine•11,360
    @elaineleung
    Posted over 3 years ago

    Hey Bernard, I came across your solution since I also had worked on the same challenge; I just looked at some of the questions you noted down and thought to add a reply here. Here are some comments I have; hopefully they can be useful to you!

    By the way, here's a link to my repo for your reference! Live site here.

    Arrow icon: I did the same thing where I used a pseudo class with position:absolute. On your page, I noticed that in certain cases when I change the screen size while the social section is active, the arrow/triangle becomes visible in desktop view without the callout itself, or that the callout would be visible without the arrow. Thankfully that shouldn't be an issue in the actual use case since people just use a static device in viewing, but in any case, I think you can look at your JS file and fix that. It looks like it could be the open-icon-close class that needs to be removed in your closeBtn.

    Responsiveness: I find that with the Frontend Mentor challenges, most of the time it's best to just keep the widths static if the challenge is a single component and not a webpage. That just means I had the card at a fixed width for each breakpoint; in other words, while the viewport changes, the card's width does not change at the designated views. You may find this approach easier to work with and in that way, you only have to worry about sticking to the two sets of sizes for the mobile and desktop views.

    Social div: I also used display: none in my code. I had come up with various approaches to tackle the profile/social section; I was originally going to do something similar to what you did, but in the end I decided I would only change the styles and use the same arrow for toggling the state instead of having two different arrows. (Side note: Honestly I didn't like the original mobile design where the height changes when the social div is active because the vertical padding is uneven for the main text content. In any case I just used padding to change the heights.)

    Some other comments/suggestions: I noticed that you got a number of accessibility warnings; most of them seem to point to the need for landmarks (i.e., tags like main, header, section, etc.). I'd recommend replacing some of your divs with these landmarks tags. You can have a look at my HTML to see how to do that. One tricky thing is the need to have an h1 before using an h2; I came across a suggestion online of using a non-visible h1 in a header, and that seemed to fix the h1 accessibility issue for me.

    Marked as helpful

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