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

Flex Baux, go! HTML & CSS

Bob•105
@robakerson
A solution to the 3-column preview card component challenge
View live sitePreview (opens in new tab)View codeCode (opens in new tab)

Solution retrospective


  1. Is there some dark magic secret to getting the design to match the previews better? First solution looked amazing on my screen then the upload to F.E.M. looked... less...amazing.

  2. Flex box was easier to implement/play with than I expected. Still a few edge kinks I need to play with. Is there a way to prevent individual boxes from growing? Is there a better "best-practice" way to control padding, height, etc?

  3. Desktop used VH for overall height but that broke mobile version so I switched to 100% and it seemed to work well for me but maybe there's a better way to control this?

  4. Tear it all down and let me know anything I did wrong/ that could be improved! Thanks!

Code
Select a file

Please log in to post a comment

Log in with GitHub

Community feedback

  • Joanne Wang•205
    @joanneccwang
    Posted almost 4 years ago

    To make the design match the preview better, I usually set the design jpg as background image with opacity while developing so that I can layout more precisely. So far it works pretty well!

    You can set flex property for each box to have specific flex effect. To prevent from growing, flex: 0 0 auto or flex-grow: 0 should do the job.

    Marked as helpful
  • Rafal•1,395
    @grizhlieCodes
    Posted almost 4 years ago

    Hi Bob, overall - great job.

    Your questions were simple but when I tried answering below I blabbed on for quite a while. After considering deleting this response I thought against it. I would have found the below useful when I was starting out. If something doesn't make sense just ask and I'll answer with more precision (and when it's not 3am and I'm actually awake) 😅.....

    ** dark magic secret - FEM Upload **

    I mostly work with design files (Figma files etc). I think it's safe to assume that as a developer you will either have access to design files that tell you exact measurements in pixels as a guideline, or you will be looking at a website with the ability to use developer tools. Either way if you're working from an image, like a lot of the free-challenges offer, I wouldn't worry about being pixel perfect. If you are worried then Joanne's answer is awesome and something I've never thought of doing.

    ** Flexbox - best practices **

    Flexbox is something people will usually find easy to get into and then will not seek best practices, so kudos for that. Whilst I don't know the best answer I'll share some knowledge that comes to mind immediately.

    Joanne already mentioned flex: 0 0 auto. What this does is flex: flex-grow flex-shrink flex-basis. This is hella useful and I probably use it in every single project. The first 2 should make sense. If there is space to grow, the flex-child will grow and take that space. Shrink is less useful in most circumstances I think. Flex-basis is basically a min-width/height for a flex-child (depending on whether you're using a row or column direction). Be at least 'x' high or wide basically before you shrink/grow/etc.

    As for best practices to controlling height etc - the best approach I think is to:

    Let the content dictate the height, set the width/max-width yourself. This approach is generally considered to be optimal for a lot of code as you sometimes don't actually know how much content will be injected in lets say a paragraph element. And if the widths/heights are static then the text will break from the normal flow and will spill outside of its container which ain't great.

    And this is where flexbox is magic frankly. If you declare a parent to have display: flex; you have already done a lot. Take this example. Here we don't specify much at first. Just the width of the flex-parent. We then add some content to 3 paragraphs. The second paragraph has twice the amount of content of the other 2.

    Notice that flexbox will squeeze the smaller content by itself and enlarge the middle paragraph. That's default behaviour.

    If you uncomment line 36 you will notice 1 more interesting behaviour. If all 3 paragraphs will take identical widths then 1 more thing is automatically decided by flexbox - all 3 paragraphs will share the height of the biggest (tallest in this case) paragraph, paragraph 2. We know this because of the border I've styled into there. All 3 borders show as the same height, even though the content of par-1 and par-3 are smaller by 50% than par2. This is a good thing of course, it was a long-sought-after behaviour that flexbox automated and saved a lot of clunky javascript calculations, or so I hear.

    Learn these default flexbox behaviours as they save a lot of time when you actually want to implement stuff into the projects. So far I've basically said that as long as you set the width of the parent container somehow, the rest will takecare of itself in terms of height. Unless you set it yourself of course, which is also OK, but it is by defenition 'less flexible' 😅.

    Padding - Padding is simply something you set for a parent. Not much more to add, not sure about best practice here. All you need to remember is that padding is used to control the spacing of child-elements within the element itself.

    I created this simple demo. Only difference is that in the first example we use gap: 2rem and in the other example we use margins from each flex-child to set the height and spacing of our flex-parent. So this is that "content controls size" approach in action again.

    Blabbed on too long on this and I think i lost the main point by now so I'll stop.

    Overall Height / VH etc

    Every project I add this to body:

    body {
       width: 100%; 
       height: 100vh;
       margin: 0;
       padding: 0;
    }
    

    You then want to specify a max-width for all of your content. In the case of your project I would have a set this (give or take) for outsideContainer:

    .outsideContainer {
       width: 90%;
       max-width: 42rem;
       /* you might want some min-height */
    }
    

    The 90% allows us to essentially have a "padding" on smaller displays. Then when the display becomes larger you will reach a max height of 42rem or 670px approximately. So that's for a simple project. Other projects width will be set at 100% and you will have very specific padding elsewhere.

    class naming - avoid camel case in css

    One of those best practice things I've come across is to avoid using camel-case in CSS; Reason being is that CSS is not written with that. We write flex-grow, not flexGrow, box-sizing: border-box not boxSizing: borderBox. It just allows the reader to not get lost/confused etc. Tailwind also doesn't use camel-case, it's just a best-practice thing, not that it breaks any code.

    What I would have done

    In summary: I think I covered that widths are best set in parents. So I'd start there. Then I'd place in the content of the flex-items. Then I'd set the margin-bottom of each of the elements (car logo, heading, info). The height is dynamically calculated in this case.

    Sort of like this example.

    Happy coding 😁

    Marked as helpful
  • P
    j5•2,270
    @jmnyarega
    Posted almost 4 years ago

    Nice work on the challenge @robakerson. On desktop height, I will recommend using min-height instead.

     .outsideContainer {
        display: flex;
        min-height: 100vh; // note the 'min-'
        align-items: center;
        justify-content: center;
    }
    

    This will prevent content from stretching downwards. Otherwise great job on the challenge.

    Keep code 🙂

    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

Oops! 😬

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

Log in with GitHub