Social proof section (HTML and CSS)

here is where I tried (https://www.frontendmentor.io/solutions/huddle-landing-page-with-a-single-introductory-section-xtmdDUtu9#feedback) in this challenge, on the font size of the title

Again, looking pretty strong! I'll probably nit-pick and will focus on concepts more than actual code.

Lets go with a list?

1. **Avoid using height. If you want to use height I recommend min-height. **

Why? GREAT QUESTION! The concept here is simple: we want to let the content decide how large a container is. When we write CSS we are working with alot of unknowns: What is the screen size of the user's client? What browser and what version are they using? Do they prefer darkmode or default? Etc.

This gets into the core of FRONT END web development: we don't want to create pixel-perfect styling for the content. We want to create adaptable content that is responsive. You actually did really well in this regard, but like all of us a few improvements here and there will just carry you further!

Back to the height.

Lets say, for whatever reason, our user's display is 200px wide. And lets say your .review card is responsive in width. The content will not fit in the .review container! You'll see the .star-icon's breaking out of the container on the top. Why? height: 62px (you should be using 6.2rem btw, keep it consistent 😁)! The height will break it. Instead you could use min-height: 6.2rem and voila. Now the content is responsive on ultra-thin displays.

Lesson: Don't use height as we simply don't know the users display etc. Allow content to rule the height and allow the browser to recalculate everything for you.

This is mega important I think so ask me questions if I failed to explain it.

1. What if the user, for whatever reason, is using a very wide display, lets say 34"+?

Another responsiveness lesson: the background image you are using will be tucked away in the depths of the far-left-top corner of the users display. I have a 49" display and so it's very simple for me to test this. You could test it by zooming out whilst building your projects.

The fix is rather simple too, one line of code to body:

body {
        background-position: right 66vw top 0%;
}

This should be un-intuitive. If we want the background to be in the left why are we using right?? I've no clue how the math works unfortunately. But this keeps the image relatively 'centred'. If you tried doing this with left it would mess it up and it would at some point be located outside of the viewport. Depths of CSS I've not yet covered...

1. Be brave with UI

I'm really only talking about you being comfortable at judging when something is too small/large and just making an 'executive-decision' to change it.

Lets take the .review card again. I think that during the mobile -> desktop transition it becomes too wide, taking up WAY more space than it needs to.

1. Continuing point 3 but introducing clamp

Lets use clamp for this to declare a min, optimal and max widths:

.review { 
      /* other code*/
      width: width: clamp(22rem, 50vw, 41rem); 
}

I'm pretty sure if you removed ALL other widths associated with .review this code would be sufficient. To understand clamp check this video out.

You can use clamp for anything tbh. Font size, width, padding, margin, name it. It allows you to easily write responsive measurements depending on a the screen width.

Once you have played around with clamp you can use this tool I built to get the EXACT clamp code you need. Don't use it now, it wouldn't make much sense (yet). I'm not brilliant with math so the math I took from someone else 😅.

If you use SASS then you can use this SCSS code as a function. If you don't use SASS yet, don't worry about it.

$breakpoints-units: (
  "mobile":        375,
  "mobile-wide":   480,
  "phablet":      560,
  "tablet-small": 640,
  "tablet":       768,
  "tablet-wide":  1024,
  "desktop":      1248,
  "desktop-wide": 1440
);

@function fluid($size, $minSize, $maxSize, $oneRem: 10){
  @if map-has-key($breakpoints-units, $size){
    $size: map-get($breakpoints-units, $size);
    $mobile: map-get($breakpoints-units, mobile);
    $minWidth: $mobile / $oneRem;
    $maxWidth: $size / $oneRem;
    $slope: ($maxSize - $minSize) / ($maxWidth - $minWidth);
    $yAxisIntersection: -$minWidth * $slope + $minSize;
    $vwUnits: $slope * 100;
    @return clamp(#{$minSize}rem, #{$yAxisIntersection}rem + #{$vwUnits}vw,#{$maxSize}rem);
  }
}

As an example of what the above code would do:

/* If we type this in SCSS /*
div {
    padding: fluid(tablet, 2, 4);
}

/* it will output the following CSS */

div {
    padding: clamp(2rem, 1.0458015267rem + 2.5445292621vw, 3rem);
}

So our padding will be a minimum of 2rem (starting at around 375px). And it will grow with every pixel of increased viewport-width until it reaches 3rem.

Magic 🧝‍♀️✨.

I think that's enough. I could blab on but it'd be less and less useful lol. Hope you get something out of this.

1. Avoid setting height, set min-height if you must.
2. Think of very small AND very large displays before you finish a project and implement tiny styling fixes.
3. Challenge designed/your own UI. As an obvious example, a single word with font-size: 1rem shouldn't have padding: 10rem.
4. Clamp baby!!! ✨🤩

Edit

Oh yeah. I noticed you were using max-width for your media queries. Generally this means you designed the Desktop version of the page first, is this correct?

Either way, the best practice is to code the mobile version first and use min-width for media queries.

The logic is quite simple too. A mobile page is easier to code and it gives your a MVP (minimum viable product). It's usually a simple, single column, layout that you can then easily style etc.

As you increase in screen size, you have more real-estate to work with. Then we add complexity, you see this in designs often I'm sure. Things get more interesting for desktop sizes.

And generally speaking it's easier to do the SIMPLE first and then add complexity. Because if we start with desktop, we are starting with complexity and then are trying to simplify it, this is often much more difficult than the alternative approach.