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

Pricing Component with toggle

Nyein Chan Lay•350
@CrystalNyein
A solution to the Pricing component with toggle challenge
View live sitePreview (opens in new tab)View codeCode (opens in new tab)

Solution retrospective


Feedbacks are appreciated.

Code
Select a file

Please log in to post a comment

Log in with GitHub

Community feedback

  • Raymart Pamplona•16,040
    @pikapikamart
    Posted over 3 years ago

    Hey, awesome work on this one. Both desktop and mobile state actually looks really great.

    Carl Wicker already gave a feedback on this one, just going to add some suggestions as well:

    • It would be nice to add the box-sizing: border-box on the * selector so that content sizing will be much easier to handle.
    • On your main tag, remove the overflow-x on it. If you inspect the layout in dev tools at the bottom, the layout creates another vertical scrollbar because if you set a overflow-x it will default the overflow-y to scroll instead of visible.
    • Those 2 background-waves could just be used as background-image so that you won't have to create extra img tag, but if you insist on doing so, add aria-hidden="true" on both so that they will be totally ignored by screen-reader.
    • For your pricing toggle, it works but only limited for mouse click because you used display: none on the input which you NEVER should do. Doing so removes the interactive element from the dom itself. On this one, if you think about it, this is a selection of choice right, therefore using radio-buttons input type="radio" is much preferable. For this one, you should use a fieldset to wrap the toggle, a legend tag which its text content should describe what is the purpose of those input. Use 2 label and two input type="radio". Those text, annually and monthly are label. Have a look at this old solution of mine in this challenge. But :>>, this is an old solution where I still don't know some semantic markup. But take a look at the toggle, just replace the div container into using fieldset and add maybe an sr-only legend tag inside it.
    • Each plan's pricing, like 199$, they could just a p tag since the h2 above them already gives information on what each section would contain. Because those numbers alone when used as heading doesn't really give that much content.
    • Those 3 information below each pricing could use a ul tag since those are "list" of information about the plan.
    • The learn more is better using a tag rather than button because if this were a real site, it would much likely be page link where user can "learn" more about a specific plan.

    Aside from those, great job again on this one.

    Marked as helpful
  • Carl Wicker•1,055
    @carlwicker
    Posted over 3 years ago

    Hey ya Nyein, Great job, I cant see any issues. There is a weird media breakpoint on the desktop version which makes stuff jump around. Personally I'd lose the additional break point.

    Keep up the great work.

    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 1st-party linked stylesheets, and styles within <style> tags.

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.

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