Skip to content
OverviewSolutions
5
Comments
4
Robert
@waffleflopper

All comments

  • Robert•170
    @waffleflopperPosted over 1 year ago

    Kudos on taking the design and making it your own - not something people usually do. Just some things I noticed could be improved/challenge you to do:

    On the main page in the desktop view I'm able to scroll to the right and see a huge white bar going down the screen because your desktop container is set to 100% but also has a left margin. This can be solved by seeing box-sizing: border-box; on your :root in CSS. By default margins are not taken into account when calculating the width of a container. so because you have a container set to take 100% of the available width (which in your case is the entire screen) and then set a 8% left margin on it, the total width becomes 108% which causes your planet panels to overflow the horizontal bounds of the screen. Either removing the margin-left or setting the box-sizing on the root should solve this problem. Some additional reading can be found here.

    Regarding the use of margin-left to center the content - this isn't typically how you should center content. Using a setting auto is usually what I do if I'm not relying on align-items or justify-content within a flex box.

    I noticed you have a margin of 10px on the planet tiles themselves, as well. I would recommend taking advantage of the gap property on the flex containers to do this for you. As well as looking at the flex-grow, flex-shrink, and flex-basis (which can be shorted handed using flex: [num] [num] [num];) properties on the planet cards for their sizing. WC3Schools is a good place to reference and FlexBox Froggy is a great little browser puzzle/game to learn about flex boxes and what you can do with them. (Grid Garden is the equivalent for Grid, which would have been a good use case for your planet cards).

    I plan on diving more into your site later but I'm out of spare time at the moment, unfortunately. You're off to a great start (and congrats on writing your first custom React hook!) and you should be proud of what you've accomplished. Take a look at the resources and look at refining your CSS skills. There's no shame in starting with some of the easy free challenges and finishing them out completely with CSS. I've noticed a lot of people are more likely to look at the repository and comment on it when it's pure HTML & CSS, versus using a library like we did for this challenge. Kevin Powell has done a couple of the free ones and in general his youtube channel has taught me a ton and really brought me to enjoy working with CSS, rather than being frustrated with it at every turn.

    An absolutely FANTASTIC, bullet point guideline for interfaces can be found at Rauno Freiberg's portfolio site. It's a great way to make sure the user experience is consistent throughout your site. A big one that helped me is (as a general rule) keeping any transitions below 150ms. Keep on grinding and dive deep on CSS - I personally feel it's the most important thing to learn for front-end developers.

    Marked as helpful
    0
  • Reni•40
    @renikoulenSubmitted over 1 year ago

    When I worked on this project, I found it challenging to resemble the design (aligning the elements within the Summary parts). I will probably re-work that piece. I am also unsure whether I managed the challenge of responsiveness.

    result-summary-component-main HTML and CSS

    1
    Robert•170
    @waffleflopperPosted over 1 year ago

    Hey there. I just want to make sure before I give any feedback that you got everything uploaded properly to the live preview? Few things seem broken so I wanted to make sure you had the opportunity to get it working exactly how it did on your computer before I make any further comments :)

    0
  • Robert•170
    @waffleflopperPosted over 1 year ago

    I like how you formatted out your CSS styling, with the comments about what each was doing before writing all the layout styles and such. I'm an in-progress self-taught looking to start a career in the field in about a year and was wondering where you picked this method up? I'm always on the lookout to for new practices to implement =)

    Nice work =)

    1
  • Nina Alin•30
    @nina-alinSubmitted over 1 year ago
    • How can I improve my CSS responsability ?
    • Did I use SCSS' full potential ?
    • Could my CSS be simpler ?

    HTML / SCSS

    1
    Robert•170
    @waffleflopperPosted over 1 year ago

    I'm not quite versed enough in SASS yet to let you know if you're harnessing it's full potential yet. That being said there are a few things I can see, in general, but you may have had a purpose behind it.

    CanIUse is a great site for checking what CSS properties are supported in what browsers. The reason I bring this up is I noticed you were doing background styles using -webkit and -o notations, when linear-gradient() on it's own has been widely supported for some time. So unless you are supporting some really old computers or that very (very) small percentage of people using browsers that don't fully support linear-gradient(), it's just redundant syntax.

    While I'm just learning SASS myself, I'm trying to use mixins where possible in areas that can be served by them. For example in my own solution to this project I used my own mixin for bg-gradient because I knew I was going to be using it in a few spots and @include bg-gradient($slate, $royal) was just nicer to put in (for me at least). They're also really popular to use in media breakpoints.

    While using %s and or viewport units can be really nice and make things feel really responsive, they can create a lot of issues on their own - especially when setting the browser to weird dimensions. Your design breaks in a few different ways when I manipulate the dimensions. Additionally on mobile vh/vw doesn't account for the address bar that mobile browsers take up and can break designs reliant on them as well. You can use DVH or DVW if you're really set on using viewport units, but I would stick with either pixels, em or rem, and set some max-widths and max-heights to constrain your design to keep it from breaking when shrinking things down, or expanding them out to the extremes.

    Lastly, I would look at trimming back some divs. For example, putting the continue button in a container isn't really necessary as it's a single contained button that can be positioned inside a flex box on it's own.

    I do like how you separated concerns with your SCSS files. I had all of my stuff in a single file but I can definitely see the advantage of having things in their own areas - especially when working with larger projects.

    Keep on trucking!

    Marked as helpful
    0