Skip to content
  • Unlock Pro
  • Log in with GitHub
Solution
Submitted about 1 month ago

Project Tracking Intro Component Master

react
Evellyn Lindoso•60
@EvellynL
A solution to the Project tracking intro component 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?

I'm proud of having managed to use some CSS properties well that I didn't know much about before. I think I would change the way I place each component on the screen so that I don't have to work so much with responsiveness.

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

My main challenge was to make it responsive for different types of screens (mobile, tablet, desktop). Basically, when I adjusted one element, another one would move out of place and that was really annoying. With patience, I managed to make it as responsive as possible for each screen.

What specific areas of your project would you like help with?

I would really like tips on flex-box and how to use each unit (px, rem, %, vh, vw) more correctly, depending on the type of element. I would also like to know how other people organize their HTML base and compare it with mine.

Code
Select a file

Please log in to post a comment

Log in with GitHub

Community feedback

  • Bernardo Poggioni•6,770
    @R3ygoski
    Posted about 1 month ago

    Olá mais uma vez Evellyn, e mais uma vez parabéns pelo projeto.

    Sobre suas dúvidas vou começar pelas unidades de medida.

    • px essa é uma unidade absoluta, ela sempre tem o mesmo valor de sempre, 100px é 100px sempre, independente do navegador e/ou tamanho de fonte escolhido.
    • rem essa é uma unidade relativa, ela tem o valor baseado no tamanho de fonte do seu projeto, vamos supor que no seu html {} você passe um font-size: 24px;, nesse caso 1rem equivale a 24px. Por padrão o 1rem vale 16px ou o tamanho de fonte definido no seu navegador, na parte de configurações. Tanto que na maioria dos caos que for utilizar tamanho de fonte, é recomendado utilizar rem, porque ele se adapta e é responsivo.
    • % essa é uma unidade relativa, ela se baseia no tamanho do elemento pai, ou seja, suponhamos que temos uma <main> com uma <aritcle> dentro, a <main> tem 600px de largura, e <article> tem 50% de largura, ou seja, article tem 300px de largura porque é o 50% do elemento pai, se fosse 20% por exemplo, daí seira 120px.
    • vh e vh ambas são relativas e são baseadas na viewport do seu navegador, o vw é para a largura e o vh é para a altura, o que grosso modo significa a parte onde fica sua página, por exemplo, essa barra de cima que dá pra inserir URL ela não é parte da Viewport, agora onde está aparecendo esse site é.

    Sobre flex bom, ele é utilizado sempre para fazer alinhamento unidirecional, ou seja, da esquerda pra direita, de cima pra baixo e vice-versa. É bastante utilizado para centralização e alinhamento, mas ele pode acabar deixando o HTML verboso caso você tente utilizá-lo para alinhamento bidirecional. Para alinhamento bidirecional o ideal seria o grid. Bom eu criei esse exemplo aqui no CodePen do qual você pode dar uma olhada nos casos em que cada um cabe melhor: Flex e Grid - Codepen.

    Sobre acessibilidade, quando você for criar links utilize sempre a tag <a> (com exceção do NextJS). Na sua ul dentro de cada li poderia ser colocado um a dessa forma:

    <li>
      <a href="#">Nome</a>
    </li>
    

    E sempre utilize o "#" para que não seja enviado a outro link e mantenha na página atual, e também note que tags <a> sempre devem ter um href.

    E sobre semântica, há apenas um trecho que vejo possibilidade de melhoria, que seria:

    • div.nav-list poderia ser alterada para uma nav e manter essa ul devido a esses links serem para navegação interna da página. Agora para casos de navegações externas utilizamos apenas o ul sem o nav.

    Sobre estrutura, a div.container que contêm a imagem, ela está sendo redundante, você pode remover ela que não causará nenhum problema no layout.

    E agora sobre o CSS, uma dica é de sempre utilizar no seu body a propriedade: min-height: 100vh;, isso garante que o tamanho mínimo da tela sempre será de no mínimo 100% do tamanho da viewport.

    E na imagem, remover o width: 1200px fará com que ela não fique cortada.

    E é isso! Novamente parabéns pela conclusão do projeto, ele ficou muito bem-feito, caso tenha ficado qualquer dúvida, já sabe, só perguntar abaixo que tentarei ajudar da melhor forma possível.

    Marked as helpful
  • Harsh Kumar•3,410
    @thisisharsh7
    Posted about 1 month ago

    Hi Evellyn! 😊

    Great job on your project! Making a website responsive can be really tricky, so it's awesome that you kept going and made it work across different screen sizes.

    Here are a few simple tips that might help:

    Flexbox

    Try starting with just these properties:

    • display: flex
    • justify-content
    • align-items
    • gap

    These can help a lot in placing elements without writing too much extra CSS.

    Choosing Units

    • Use rem for font sizes and spacing — it's scalable and easier to manage.
    • Use % when you want something to adjust based on its container.
    • Use vh and vw for full-screen sections.
    • Avoid px for layout unless it's really needed — it can make your design less flexible.

    HTML Structure

    Your HTML structure looks really clean — nice job using <header>, <main>, and <nav>!

    A few quick tips:

    • Use <a> tags inside your nav list for better accessibility:
      <li><a href="#">Product</a></li>
      
      
    • If your buttons are meant to navigate, use styled <a> tags instead of <button>:
      <a href="#" id="demo">SCHEDULE A DEMO</a>
      
      
    • Add meaningful alt text to your images for accessibility:
      <img src={Logo} alt="Company Logo" />
      
      

    You're on the right track — keep going! 🚀

    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

Oops! 😬

You need to be logged in before you can do that.

Log in with GitHub