Skip to content
  • Unlock Pro
  • Log in with GitHub
Solution
Submitted over 1 year ago

Typemaster pre-launch landing - Mobile first, BEM, Responsive images

bem
tediko•6,700
@tediko
A solution to the Typemaster pre-launch landing page challenge
View live sitePreview (opens in new tab)View codeCode (opens in new tab)

Solution retrospective


Hello!

This time I decided to challenge myself and create a landing page. I found typemaster design to be a good practice for mobile first approach, html landmarks and flexbox. Additionally, there was some work with ::before and ::after pseudo-classes to create some decorative elements. Finally, some practice with positioning images.

Here's some things I used or learned:

  • I learned and implemented responsive images. That is images that work well on devices with widely differing screen size. HTML provides us with elements to display identical image content, just larger or smaller depending on the device. This helps to improve performance across different devices.
  • Reduced browser inconsistencies in things like default line heights, margins and font sizes of headings, and so on by using CSS Reset by Andy Bell
  • I arranged my code with BEM - Block, Element, Modifier methodology, which is a popular naming convention for classes in HTML and CSS. BEM is useful when it comes to larger, more complex projects when code organization becomes crucial. The idea behind it is to speed up the development process, and ease the teamwork of developers by arranging CSS classes into independent modules.
  • I went down the road with mobile-first approach. It is one of the best strategies to create either a responsive or adaptive design. Started with the smallest mobile screen and worked my way up.
  • To make my component more accessible I used :focus-visible pseudo-class to increase usability for sighted users who use keyboard navigation. The :focus-visible pseudo-class is a native CSS way to style elements that are in focus but only applies when you actually want a visual indicator to help the user see where the focus is.
  • Instead of repeating code for reusable elements I write some helper classes to reuse them throughout the project. I created reusable classes for headings, paragraphs or containers. This saves time as well as unnecessary code repetition. I will definitely try to improve in this aspect.
  • I found small trick to make my heading in .feature section to wrap after one word to match design. You can do it using span and make it display: block or you can use 
 character entity reference in your HTML code with white-space: pre-line css. It will cause text to wrap Text on line break.

Questions:

  • Since the <section> element only becomes a landmark when it has been given an accessible name using aria-labelledby or aria-label my question is should I keep aria-labelledby or use aria-label when sections have heading within that is not very detailed/descriptive. To me headings in this project doesn't tell what kind of content is within that landmarks. Take a look at .kv or .product section.
  • This question is related to previous one. Since my .features section doesn't have heading element, should I stick with aria-label for that section or should I add heading element, and hide it with .sr-only class so I can use aria-labelledby. Which one would be better practice?

Any suggestions on how I can improve are welcome!

Code
Select a file

Please log in to post a comment

Log in with GitHub

Community feedback

No feedback yet. Be the first to give feedback on tediko'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 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.