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

Responsive meet landing page using html and css

Ohazulike Stanley•220
@Gentlestan
A solution to the Meet landing page 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?

In this project, I improved on how to implement responsive design principles effectively. I worked with different screen sizes using CSS media queries, ensuring the layout adapts seamlessly across mobile, tablet, and desktop devices. This also helped me improve my CSS skills in handling flexbox and grid layout systems, especially when creating components like the portrait section and buttons.

I also gained more practice with semantic HTML. For example, I used elements like <main>, <section>, <footer>, and <h1> to improve the structure and accessibility of the webpage. This helped ensure better readability for both humans and screen readers, making the content more accessible.

Additionally, I worked with custom fonts and enhanced typography to make the page more visually appealing while maintaining readability. The use of reusable CSS classes for typography and layout allowed me to keep the styles consistent across the page, while also making the code more maintainable.

What challenges did you encounter, and how did you overcome them?

One challenge I faced was ensuring the design was responsive across all screen sizes. Particularly, the layout of the hero section and the grid of portraits on different screen widths required lots of adjustments. I had to test my media queries multiple times and adjust the grid template to ensure it displayed well on tablets and desktops.

Another struggle was optimizing the use of semantic HTML in a way that kept the page structure both functional and visually organized. I had to pay attention to not only the visual hierarchy but also how I could use tags effectively for accessibility without sacrificing the design.

To overcome these, I referred to the project brief frequently and cross-checked my layout in different browser tools, like Chrome's developer tools, to make sure everything looked good on various devices.

Code
Loading...

Please log in to post a comment

Log in with GitHub

Community feedback

No feedback yet. Be the first to give feedback on Ohazulike Stanley's solution.

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.