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

Simple portrait responsive card using media query

João Oliveira•370
@jvmdo
A solution to the Product preview card component challenge
View live sitePreview (opens in new tab)View codeCode (opens in new tab)

Solution retrospective


Originally, my media query condition was min-width: 76.8rem. I've set html font-size: 10px, so I thought 76.8rem would be equal to 768px. But, instead, it resolves to 1228.8px (76.8 * 16px)

Is it supposed to behavior like this or am I doing something wrong?

Code
Select a file

Please log in to post a comment

Log in with GitHub

Community feedback

  • Md5 dalton•1,430
    @md5dalton
    Posted almost 3 years ago

    Hello João Oliveira 👋

    You are not doing anything wrong, that's the expected behavior. I was also a bit confused about the use of rems in media queries when I was watching a tutorial on CSS media queries by Coder Coder. So I searched online to see if anyone else has come across this issue and here is what I found:

    rem is one of many relative units in CSS, which means it is relative to something else, perhaps the size of the parent element's font, or the size of the viewport. In the case of rem, it is relative to the font size of the root element that is matched by the :root pseudo class or the html selector.

    So now here is where things start to get interesting. According to section 1.3 of the media queries spec, relative length units in media queries are based on the initial value, which means that units are never based on results of declarations. For example, in HTML, the em unit is relative to the initial value of font-size, defined by the user agent or the user’s preferences, not any styling on the page.

    So since rem is also a relative unit, when you choose to use them in media queries, the initial value will be 16px and not the 10px that you defined in your styles even though that was still inside the root element.

    I hope that clears the confusion. 👌

    Marked as helpful
  • Lucas 👾•104,160
    @correlucas
    Posted almost 3 years ago

    Aqui outra dica pra você João:

    A estrutura html o design também, algo que você pode fazer para melhorar a imagem que precisa mudar entre mobile e desktop é usar <picture> ao invés de <img> dentro de uma div. Por motivos de SEO e mecanismos de pesquisa tipo Google e bing, não é uma boa prática importar esta imagem do produto com CSS, pois isso dificultará a localização da imagem no google. Você pode gerenciar ambas as imagens dentro da tag <picture> e usar o código html para definir quando as imagens devem mudar configurando o dispositivo max-width dependendo do dispositivo (mobile / desktop) Aqui está um guia sobre como usar picture: https://www.w3schools.com/tags/tag_picture.asp

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

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