Skip to content
OverviewSolutions
24
Comments
21
P
Eli Silk
@elisilk

All comments

  • Bruno Feitozaā€¢20
    @feitozabrunoSubmitted over 1 year ago

    Frontend Mentor - Body Mass Index Calculation Solution

    This is a solution for the Body Mass Index Calculator challenge in Frontend Mentor. Frontend Mentor's challenges help you improve your skills in developing realistic projects.

    Index

    Note: Please delete this note and update the table of contents based on the sections you maintain.

    Overview

    The challenge

    Users must be able to:

    • select whether to use managerial or imperial units
    • Enter your height and weight
    • View your BMI result, with your weight rating and healthy weight range
    • See the optimal layout for the interface depending on the device screen size
    • View hover and focus states for all interactive elements on the page

    Screenshot

    Project preview

    Links

    My process

    Built with

    • semantic HTML5
    • SASS/SCSS
    • Flexbox
    • CSS Grid
    • Mobile first workflow
    • Pure JavaScript

    What Ive learned

    Use this section to recap some of your key learnings as we look at this project. Writing them down and providing sample code of the areas you want to highlight is a great way to strengthen your own knowledge.

    To see how you can add code snippets, see below:

    SASS/SCSS/CSS

    1. Modularization of files and use of variables in SASS/SCSS.
    2. Flexbox and GRID
    3. Absolute and Relative Position.
    4. Styling radio type inputs.
    5. Visual accessibility and accessibility for screen readers.
    6. Pseudo-class (::after) and (::before).
    7. Property (:focus-within) to activate the focus of a child element on the parent element.
    8. Responsibility for all device sizes.

    JS

    1. Manipulation of the DOM
    2. Create reusable functions.

    Continuous Development

    I'm building my JavaSript base to learn and work with ReactJS and then NextJS in the future. For styling I intend to work with TailwindCSS and styled-components.

    Useful Resources

    • ChatGPT - This helped me understand the concepts and workings of all my doubts.
    • Frontend Mentor - This is an amazing platform that helped me find professional and responsive Figma projects to turn into code.

    Author

    Body Mass Index Calculation Application Developed with HTML, SASS, JS

    1
    Eli Silkā€¢660
    @elisilkPosted 11 days ago

    Hi šŸ‘‹ @feitozabruno,

    Congrats on a very nice solution. šŸ‘ From the solution/design slider, it looks like what you produced was super close to the design, which is amazing.

    But it looks like you took down your GitHub repository and your current live solution looks much different than the design (at least as of 11/11/2024), so it's hard to provide any useful comments. I do like that you made the solution your own. That is super cool. But it might have made sense to fork your first solution before creating this new one.

    If you are up for diving in šŸ¤æ just a little further with your new solution, I ran the Lighthouse audit on your site and it overall performs very well. The one exception in terms of Accessibility is that some of the colors don't have sufficient contrast. That's most noticeable with your h3.text-info class on the "BMI Calculator" heading. But the same issue also shows up on a couple of of your BMI category boxes. If you want to read more about color contrast, check out this link:

    Elements must meet minimum color contrast ratio thresholds

    Here is the Color Contrast Checker for the color on your h3.text-info class:

    Color Contrast Checker for text color of #0DCAF0

    And then here is a potential alternative color that would enhance the contrast:

    Color Contrast Checker for text color of #054957

    Anyway, just an idea to consider if you are thinking about improving on your customized solution. šŸ¤”

    Great job overall! Happy coding. šŸ’»

    Eli

    0
  • KapteynUniverseā€¢2,070
    @KapteynUniverseSubmitted 23 days ago
    What are you most proud of, and what would you do differently next time?

    Added a couple of simple but nice transitions.

    Normally i go from top to bottom but during development of this challenge i jumped section to section, it might caused some repetitive codes at some places.

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

    Any feedback is appreciated.

    Just found a bug before posting, it is possible to focus some hidden element and modal with tab button.

    E-Commerce Product Page

    1
    Eli Silkā€¢660
    @elisilkPosted 22 days ago

    Hi šŸ‘‹ @KapteynUniverse,

    Congrats on a very nice solution. šŸ‘ I like how you incorporated animations/transitions -- especially with the cart, but also more subtle ones like the hover effects on the main navigation menu. Very cool!

    And I also appreciate the use of .sr-only labels, such as on the prices and on the input labels, as that definitely increases the accessibility of the page in the cases where the visual styles are not enough. Great work.

    If you are up for diving in just a little further šŸ¤æ, I'd suggest a few things:

    • First, I think a few small design tweaks might make the implementation a little cleaner visually. One that stood out to me are the shadows in your add-to-cart form section. In the design, there is only a small, subtle drop shadow behind the add-to-cart button, and that shadow is present only on the mobile version. And there isn't a shadow at all on the quantity input field (your .quantity class) in the design. So here is the drop shadow value that I used for the add-to-cart button based on what was in the Figma design file:
    .cart button {
  box-shadow: 0 20px 50px -20px hsl(26, 100%, 55%);
}
    • Second, I noticed something a little funny when I was looking at your solution at different viewports. Specifically, I started by viewing your solution at a mobile viewport width (<55em), then scrolled down to the bottom of the page (my screen is not tall enough to see the whole page without vertical scrolling). And then before scrolling back up to the top, I moved to a desktop viewport (>55em). What happens in that case is that the top of the page is no longer visible or scrollable. I think that's because you have the following set on your body element:
    @media screen and (min-width: 55em) {
    body {
        overflow-y: hidden;
    }
}

    And I'm guessing you hid that vertical overflow so that you can have the modal lightbox be "hidden" down at the bottom of the page and then animated back up when shown, while preventing any scrolling while it's in the hidden state. Is that right? I certainly understand that choice. And admittedly, I don't think many users will go back and forth between viewports like I did. šŸ¤Ŗ

    However, if you are looking for alternative ways to get your modal to transition in and out of the screen, I'd recommend you check out two YouTube videos by Kevin Powell:

    1. "Animate from display none" from April 2022
    2. "We can now transition to and from display: none" from June 2024

    The approach in the second video is super cool but still not fully supported in Firefox browsers and so may not be the best option.

    Anyway, just some ideas to consider if you are thinking about improving on this solution. šŸ¤”

    Great job overall! Happy coding. šŸ’»

    Eli

    Marked as helpful
    0
  • Sam Hookerā€¢680
    @35degreesSubmitted 3 months ago
    What are you most proud of, and what would you do differently next time?

    I'm proud that I used anchor positioning for the first time (using it on the mobile hamburger menu). I strengthened my a11y code with strong use of semantic headers.

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

    ensured the page was SR friendly

    responsive grid a11y news

    2
    Eli Silkā€¢660
    @elisilkPosted about 1 month ago

    Hi šŸ‘‹ @35degrees,

    Congrats on a very nice solution. šŸ‘ I like how you implemented the hamburger menu using only CSS. Very cool!

    If you are up for diving in just a little further šŸ¤æ, I'd suggest a few things:

    • First, when you have different versions of the same image, like you do for the banner image in this challenge, consider using the <picture> element. This will help ensure the correct image loads on the user's device, saving bandwidth and boosting performance. For example:
    <picture>
    <source media="(min-width: 768px)" srcset="{desktop image path here}">
    <img src="{mobile image path here}" alt="{alternative text here}">
</picture>
    • Second, when I open your solution on my browser and move to a smaller viewport width, for me, the height of the content extends beyond the viewport height and there is scrolling down but not up. And so the top of content (the nav and part of the banner image) is cut off and not accessible. One option to fix this would be to adjust how you set the height attribute of your .main-container in your CSS. Specifically, try changing the height attribute to instead be min-height. Doing that will allow the container to fill up the entire viewport height (as you had it originally), but now it will also allow the main-container it to extend beyond that viewport height when needed. Like this:
    .main-container {
    min-height: 100vh;
}

    Anyway, just some ideas to consider if you are thinking about improving on this solution. šŸ¤”

    Great job overall! Happy coding. šŸ’»

    Eli

    Marked as helpful
    0
  • Emerson Limaā€¢200
    @poissonfouSubmitted about 1 month ago
    What are you most proud of, and what would you do differently next time?

    I am to have been able to easily create the layout and the form validation.

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

    I didn't have any challenges with this project

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

    Any suggestions on how to improve the css and the js are appreciated :)

    Responsive, Flexbox, BEM

    1
    Eli Silkā€¢660
    @elisilkPosted about 1 month ago

    Hi šŸ‘‹ @poissonfou,

    Congrats on a very nice solution. šŸ‘ The solution looks a lot like the design and functions very well. I also appreciate that you focused on the accessibility of the form. Great job!

    If you are up for diving in just a little further šŸ¤æ, I'd suggest a few things:

    • First, to get your <main> container centered in the viewport, I'd suggest a few changes. First, I'd take off the margin-left and the transform CSS attributes you currently have. Instead, I'd suggest just setting the max-width to constrain how big it can get in the larger screens. Then, I'd suggest setting its container, the <body> element, to be the full height of the viewport and be a flex container so that it's relatively easy to center the <main> element both horizontally and vertically using align-items and justify-content. All together, here is what the solution would look like:
    body {
  min-height: 100vb; /* so will take up at least the full viewport height */
  display: flex;
  align-items: center; /* centers child items vertically */
  justify-content: center; /* centers child items horizontally */
}

main {
  max-width: 46rem; /* so will take up no more than 736px */
}

    • Second, I noticed when using the keyboard to access your form that the two radio buttons weren't connected. That is, when I can hit tab or shift+tab to go from one to the other, but usually when they are connected you should move between them using the arrow keys instead (see https://webaim.org/techniques/keyboard/#testing). And then I noticed that you have a JavaScript function selectRadioInput that looks for the ratio options and makes sure only one is checked at a time. Instead of that approach, if you make them part of one radio group then that gets taken care of automatically. To make them part of the same group, all you have to do is change your HTML so that they have the same name attribute. See this MDN reference: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/radio#defining_a_radio_group

    • And finally, I also noticed you are using the built-in form validation. That is definitely a workable way to go. But the design (and your HTML) calls for more custom messages that you show up below the input fields (into your .form__error elements). Although a bit more work, you might try to implement those more custom messages. If you are up for giving this a try, I suggest looking at the "A more detailed example" section in this MDN guide as a useful starting point: https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_validation#validating_forms_using_javascript

    Anyway, just some ideas to consider if you are thinking about improving on this solution. šŸ¤”

    Happy coding. šŸ’»

    Eli

    0
  • Smaylen5ā€¢530
    @Smailen5Submitted about 2 months ago
    What are you most proud of, and what would you do differently next time?

    I'm glad I practiced using ARIA attributes. At first, I thought it would be difficult to implement them into my workflow, but thanks to the articles I read, I realized that there are many tools that help ensure proper usage.

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

    I wanted to use the accordion from Shadcn, but unfortunately, I couldn't understand how Radix-UI handles icons inside it. Therefore, I decided to create the accordion myself according to the required specifications.

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

    Any feedback is welcome šŸ˜‰

    Faq accordion accesibility

    1
    Eli Silkā€¢660
    @elisilkPosted about 1 month ago

    Hi šŸ‘‹ @Smailen5,

    Congrats on a cool solution. šŸ‘ I appreciate that you are using ARIA attributes and that your solution is keyboard accessible. That's great!

    If you are up for diving in just a little further šŸ¤æ, I'd suggest a few things:

    • To be a bit more consistent with the design, I'd suggest starting with the first FAQ open. Does your component allow for that?
    • I'd also suggest looking at how the FAQ question headings look center aligned when you move to smaller viewport widths (e.g., the mobile view of 375px viewport width). I think this is because you are using a <button> element for those question headings and the default user-agent styling for them is text-align: center. It isn't a problem at larger viewport widths because you have the button set as display: flex container with justify-content: space-between; And that means when the FAQ question is just one line, the flex container pushes the question text all the way to the left. But when the FAQ question breaks onto more than one line, then the center text alignment shows up. So I'd suggest adding a text-align: left; somewhere in the CSS that you are putting on those buttons.
    • It doesn't look like the Work Sans font that is specified in the design is loading properly. When I view the solution, I see your fonts rendered primarily in Helvetica. I'm not certain the issue as I see that you are including the links to those assets. But maybe look into how you are loading the fonts? Or possibly the url path that you are using? Sometimes things work well on your local machine, but then when pushed to the server the url paths get broken.

    Anyway, just some ideas to consider if you are thinking about improving on this solution. šŸ¤”

    Happy coding. šŸ’»

    Eli

    Marked as helpful
    1
  • Eli Silkā€¢660
    @elisilkPosted about 1 month ago

    Hi šŸ‘‹ @naveen-developer,

    Congrats on a great solution. šŸ‘ I love the way you implemented it all so simply in one file. It's super concise and lean. Nice job!

    If you are up for diving in just a little further šŸ¤æ, I'd suggest a few things:

    1. Take a look at radial-gradient() as an alternative to linear-gradient for the background on your main ratingCard containers. Using the radial gradient with a circle centered near the top will help make it seem like the light is coming from a more central source rather than from the top right corner. I would also suggest increasing the lightness of your finishing color just a bit (e.g., 12% or more), so that the bottom part of the container is better distinguished from the background. For example, this could be one alternative to try out:
    .ratingCard {
    background: radial-gradient(circle at top, hsl(213, 19%, 18%), hsl(216, 12%, 12%));
}

    1. In the design, it looks to me like each of the rating numbers should have an orange background if they are in the hover state (not white). When selected, then it's white, like you have it, but when the mouse hovers over any of them, I think you should turn the background color to orange.

    2. Finally, if you are up for a bit more, I'd suggest thinking about switching over the rating numbers from an unordered list to <input type="radio"> elements. The radio buttons are definitely harder to style well, which is a disadvantage. On the other hand, they come with built-in advantages of being semantically more aligned with what I think the design calls for (see First Rule of ARIA Use), which is to choose one value from a set of values. And along with that, they come with built-in interactivity features that make for a more accessible solution. So for example, someone can use the keyboard to access the ratings and select their choice. Again, the styling is not that straightforward, but it is possible if you are willing to explore a bit.

    Anyway, just some ideas to consider if you are thinking about improving on this solution. šŸ¤”

    Happy coding. šŸ’»

    Eli

    0
  • Eli Silkā€¢660
    @elisilkPosted about 2 months ago

    Hi šŸ‘‹ @aouintihouari,

    Congrats on a great solution. šŸ‘ I love that you implemented the light/dark theme toggle switch, that your design layout is nicely responsive. Overall, the solution looks and functions very similar to the design. Nice job!

    If you are up for diving in just a little further šŸ¤æ, I'd suggest taking the keyboard accessibility one step further by making your buttons accessible. Currently, on your game-screen, the answer choices are nicely accessible by hitting the tab key to navigate between the choices and the enter/return key to select one, which is great. Building on those great choices, I think it would be good to consider switching your button element from a <div class="btn"> to a <button class="btn"> element. The <button> element has standard keyboard interactivity built into it (that a regular <div> doesn't have). That way when a user is tabbing through the answer choices and selects one, they can then continue to tab along to the "Submit Answer" button, and then hit the return/enter key to submit their choice. Of course, you could make similar changes to the "Next Question" button, the "Play Again" button, and the start menu choices as well if you were up for that.

    Anyway, just an idea to consider if you are thinking about improving on this solution. šŸ¤”

    Happy coding. šŸ’»

    Eli

    Marked as helpful
    1
  • Weverson Godinhoā€¢360
    @GodinhoweversonSubmitted about 2 months ago
    What are you most proud of, and what would you do differently next time?

    Iā€™m proud of the layout and responsiveness of the project. Next time, I aim to write cleaner, more structured code.

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

    I came across a challenge to create a function that shuffles the elements of an array, which will display each password character randomly

    Password Generator

    1
    Eli Silkā€¢660
    @elisilkPosted about 2 months ago

    Hi šŸ‘‹ @Godinhoweverson,

    Congrats on a great solution. šŸ‘ I love your implementation with JavaScript of the range slider so it has two different colors as it moves from right to left. That's definitely something I'd like to add to my solution. Nice job.

    When you are ready to dive in further šŸ¤æ, I'd suggest a few things:

    First, for your checkboxes, it doesn't look like the checkmark SVG is showing up. I think this is related to needing to use a relative path when putting in the URL for the SVG. Your code probably works well on your local machine, but when pushed to GitHub pages it doesn't. So I'd recommend using a relative URL like this:

    input[type="checkbox"]::before {
  background-image: url(../images/icon-check.svg)
}

    And then thinking about the responsiveness of your design, using the media queries is one way to go. But you might also consider letting Flexbox and the size of the content determine the width and the height in a more flexible way. For example, on your main container, I'd recommend you try removing the hard-coded height and width pixel values. Instead, replace them with:

    main {
  max-width: 540px;
  width: 100%;
}

    If you try this out, and play with the viewport size, you will see that the container resizes itself pretty well (although admittedly not perfectly). You'd probably have to make a few other modifications of the elements inside main to make the whole design work out, but I hope you get the idea.

    Anyway, just some ideas to consider if you are thinking about improving on this solution. šŸ¤”

    Happy coding. šŸ’»

    Eli

    Marked as helpful
    0
  • Eli Silkā€¢660
    @elisilkPosted about 2 months ago

    Hi šŸ‘‹ @dejuliansr,

    Congrats on a great solution. šŸ‘ I think you do a great job of utilizing Flexbox throughout the solution. Nice job.

    When you are ready to dive in further šŸ¤æ, I'd suggest a few things:

    • Have you thought more about implementing the error states? It looks like you included one .error-message for your "Number of people" input, but it doesn't show up when a user puts in a "0". I think one issue is that in your JavaScript (lines 37 and 39), you are editing the inline style setting of the element. I'd suggest trying out the setProperty() method instead. I'm not 100% sure if that's the issue, but I think it's worth a try.
    • I think it was a good choice to make 1 be the default value for the number of people. That just seems sensible. But given that choice, I wonder if it then also makes sense to put "1" as the placeholder value for that input field. What do you think?
    • I also noticed that at smaller viewport widths (i.e., in the mobile design), the body still has an inline padding. To be more consistent with the design, you might consider only adding that inline padding after the viewport width gets to a certain size so that the main .container takes up the full width of the viewport. You also might consider removing the border-radius on the bottom of the main .container class too, and having it extend to the full viewport height -- all to get more consistent with the design.

    Anyway, just some ideas to consider if you are thinking about improving on this solution. šŸ¤”

    Happy coding. šŸ’»

    Eli

    1
  • edpauā€¢440
    @edpauSubmitted about 2 months ago
    What challenges did you encounter, and how did you overcome them?

    When resizing the window, instead of having the hero images resize, I made them behave like in the Figma design, where they stay the same size and are evenly cropped from both the left and right sides. I used flexbox to ensure that the hero images disappear equally on both sides as the window is resized.

    But I have to wrap the hero content in an extra div for better control. Please kindly comment on my approach, is there anything I can do better?

    Responsive meet landing page with Grid

    2
    Eli Silkā€¢660
    @elisilkPosted about 2 months ago

    Hi @edpau šŸ‘‹,

    Thanks for commenting on my solution. That's much appreciated!

    I took a look at your solution for the hero image and it is a really cool approach. I definitely prefer solutions that make use of Flexbox over absolute positioning, so that is great and something I will want to try out myself.

    One small thing I noticed is that on the .hero-container class, you set the min-width: 1500px; and that results in the hero not being centered when the viewport width is between 1500px and your breakpoint at 1130px (and sometimes that means horizontal scrolling). I think you could fix that by just adding an overflow: hidden; to your .hero class. So maybe give that a try? šŸ¤”

    I also like your README file. It's great that you explain some of the thinking behind the different aspects of your solution. For the footer, I think you should reconsider your current approach and take a look at this MDN article on "Multiple backgrounds":

    https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_backgrounds_and_borders/Using_multiple_backgrounds

    It says you can layer backgrounds on top of each other, but "Only the last background can include a background color." That is a little problematic for this situation because we effectively want the color to be on top of the image. However, you can get around that limitation by making the first/topmost background linear-gradient, and using an RGB color with an alpha value specified (so it's a little transparent). And then that semi-transparent color is layered on top of the second background, which in this case is the image. Here is an example that corresponds to what I did:

    background:
      linear-gradient(rgba(77 150 168 / 0.9), rgba(77 150 168 / 0.9)),
      url("assets/desktop/image-footer.jpg") no-repeat center center / cover;

    This multiple background approach feels to me a lot simpler than working with pseudo-elements and z-indices. Give it a try!

    Happy coding! šŸ’»

    Eli

    Marked as helpful
    0
  • Eli Silkā€¢660
    @elisilkPosted about 2 months ago

    Hi šŸ‘‹ @KMS56135,

    Congrats on a great solution. šŸ‘ It looks almost exactly like the design.

    When you are ready to dive in further šŸ¤æ, I'd suggest a few things related to how the solution works at viewport widths between 1440px and 375px.

    First, when I tested your solution out, I noticed first that at 375px, your solution's height can go beyond the viewport height and so is off the screen (at least for my smaller screen šŸ“ŗ). I'd suggest in your dashboard class, changing the height: 100vh; attribute to min-height: 100vh; instead. That way the container fills the entire viewport, but is not prevented from scrolling.

    Second, testing out your solution at around a viewport width of 940px or so, it starts to get cramped and extends beyond the viewport (without scrolling). And then it continues to get more cramped until it switches over to one big column at 375px (as in the design). I can imagine different approaches to handle this kind of thing. Although maybe not the most flexible solution, adding a couple more breakpoints with media queries would be relatively simple to do. For example, you could move your dashboard container down to one column sooner (while keeping the stats-grid as is), so that the profile and time periods are on top but the stats grid stays at 3x3. Alternatively, you could move the stats-grid__inner down to two columns (from 3) earlier and keep the profile on the left for a little longer. Or do some combination of those two moves before you finally get down to one full column for the whole dashboard. To facilitate this, I'd suggest removing from the .dashboard class the attribute grid-template-rows: 518px; so that your dashboard is free to extend further in the vertical direction.

    Anyway, just something to consider if you are thinking about improving on this solution. šŸ¤”

    Happy coding. šŸ’»

    Eli

    Marked as helpful
    0
  • Eli Silkā€¢660
    @elisilkPosted about 2 months ago

    Hi šŸ‘‹ @shpokas270,

    Congrats on a great solution. šŸ‘ I appreciate the goal of focusing on just getting some experience with the JavaScript logic rather than getting distracted by other aspects of the challenge.

    When you are ready to dive in further šŸ¤æ, I'd suggest trying to implement a bit more of the client-side form validation. I found this Client-side form validation guide on MDN to be super helpful as I built my solution to this challenge. And the section on "Validating forms using JavaScript" is especially useful:

    https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_validation#validating_forms_using_javascript

    For example, right now it looks like your email input field begins with a .wrong-format class on it. I would suggest taking that off and then replacing .wrong-format with the input:invalid selector in your CSS. You then have to make a few more updates to your HTML and to your JavaScript to actually do the validation, but the example provided in the guide is very nicely aligned with this particular challenge, so I hope it will be reasonably straightforward to see the connection. If you run into trouble, though, I'd be happy to help troubleshoot.

    Worth considering if you are thinking about improving on this solution. šŸ¤”

    Happy coding. šŸ’»

    Eli

    Marked as helpful
    0