Skip to content
OverviewSolutions
12
Comments
21
P

Grog the Frog

@GregLyonsTexas480 points

- React - TypeScript - GraphQL - MySQL

I’m currently learning...

- TailwindCSS

Latest solutions

View more solutions

Latest comments

  • Codecblvck•20
    @Codecblvck
    What are you most proud of, and what would you do differently next time?

    The thing that went well for me I feel like I made good progress with the basic functionality of the project, especially the QR code generation and its presentation. The layout of the page looks great on larger screens. I also made sure to follow a clean, semantic structure using HTML5 and CSS, which I’m happy with. Additionally, I tried to use Flexbox for layout, and they helped me manage the design quite well on different screen sizes.

    What i will do differently next time Next time, I plan to focus more on the mobile-first approach when it comes to responsive design. I’ll start by designing for smaller screens first and then progressively enhance the design for larger screens. I also want to experiment more with CSS frameworks like Bootstrap or CSS variables to help streamline the process. Additionally, I’ll invest more time in testing on actual devices and use browser developer tools to fine-tune responsiveness.

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

    The biggest challenge for me was ensuring that the layout was fully responsive on all screen sizes. Initially, the design broke on smaller screens. I struggled with some of the media queries, and it took me a while to adjust the layout for different breakpoints. For example, text and images sometimes overlapped or weren’t sized properly. I also had trouble with ensuring consistency across devices—what looked great on my desktop often didn’t work as expected on mobile.

    how i overcome them

    1. Mobile-first approach: I switched to a mobile-first approach, which meant I started designing for the smallest screens and worked my way up to larger ones. This helped me focus on making sure the core layout and elements would work well on mobile devices first.

    2. Adjusting media queries: I experimented with different breakpoints to ensure that the layout adapted properly to various screen sizes. By targeting common device widths (like 320px for mobile, 768px for tablets, and 1024px for desktops), I was able to create a smoother transition between screen sizes. but i ended up using only (365px for mobile and 1440px for desktop) which was provided for me in the style-guide.md

    3. Flexible images and text: I used max-width for images and relative units like %, em, and rem for font sizes. This made the design more fluid and ensured that content resized dynamically, preventing elements from overlapping or being cut off.

    4. Testing on real devices: I also took extra time to test the design on real devices, not just using browser developer tools. This helped me catch issues I might have missed in the simulated environment, such as touch targets being too small or images not scaling correctly.

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

    I’m seeking feedback on how to enhance the responsiveness of my design. Specifically, I’m struggling with:

    • Ensuring text and images scale properly on smaller screens.
    • Handling different aspect ratios and screen resolutions.
    • Best practices for setting breakpoints in media queries—how do you determine the right breakpoints for different screen sizes?

    Any advice or recommendations would be greatly appreciated!

    QR code component using Flexbox

    1
    P
    Grog the Frog•480
    @GregLyons

    Seems like a pretty comprehensive project you did for this design. When considering aspect ratios and screen resolutions, maybe helpful to use less absolute height/width units and use relative ones.

  • P
    Grog the Frog•480
    @GregLyons

    Great work! You've completed quite a few complex projects recently. This one runs smoothly, and you handle state and asynchronous data fetching nicely.

    On your next project with asynchronous data fetching, I recommend reading this resource about handling loading and errors. That author also writes a custom hook to handle such things, which is good to read.

    A very good library for handling such things is React Query. In the example in that link you can see the useQuery hook similar to the first link. This library also handles a lot of other things for you, like caching (so you'd only need to do the "All countries" query once, and then when the user returns to that page it'll use the cached data instead of running the query again) and deduping (if you have multiple components on the page that call the same query at the same time, the query will only be done once, with its results being shared to both).

    One thing I would suggest for your code is to use more semantic HTML. In a lot of caes you're using <div> to contain text, whereas something like a heading <h1> (the "Where in the world?") or a <p> (for a lot of your other text) would be better. I think the best place to start would be the Text Content section of this MDN resource. I think that section's the most important (as well as "Forms"), and by practicing those two sections you would address a lot of the accessibility/HTML issues that Frontend Mentor is flagging.

    Marked as helpful
  • wxyzz22•240
    @wxyzz22
    What are you most proud of, and what would you do differently next time?

    Easy introduction project to brush up my previous knowledge on HTML and CSS

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

    Forgot mostly about the basic syntax of HTML and CSS. Post that, I was also told that my styling sets too much absolute height and width, which are not ideal in responsive design.

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

    Recommendation on CSS design tip, e.g. setting min-height instead of height and etc.

    QR Code Component (Refreshed Solution)

    1
    P
    Grog the Frog•480
    @GregLyons

    Congrats on your first challenge! Your solution looks good. Here are some tips for future challenges:

    1. Consider using a CSS Reset. Many elements in HTML have some default styles applied to them, like some top/bottom margin on <p> tags. In this case, those margins end up being in line with the design, but oftentimes you may find yourself struggling to remove a lot of default stylings to get your work to look more like the design. A CSS Reset like the one above should alleviate this, and give other more sensible defaults to start from.
    2. Your card wrapper has a width: 20%. This looks good on larger screens, but as you shrink the screen horizontally the card gets too narrow too quickly. Something like minmax or clamp are helpful to give a minimum and maximum width for your content, which will make your designs more responsive.

    Good work again, and best of luck on future challenges!

    Marked as helpful
  • P
    Grog the Frog•480
    @GregLyons

    Good work! You're using semantic HTML (<h1> for heading, <p> for body text), which is all you need in terms of accessibility for this challenge.

    I'll give you a few pointers I keep in mind when thinking about accessibility. Since this is your first challenge, I can't really assess what you know in terms of accessibility, so forgive me if I'm saying things you already know. My tips will mainly revolve around using semantic HTML, which is the idea of writing your HTML in a way that can be more easily understood by machines (e.g. screen readers for human comprehension, search engine crawlers for SEO, etc.).

    1) Headings Semantically, <h1>-<h6> elements denote sections on your web page. You should have precisely one <h1> on any given web page, which serves as its title. Then, your heading levels should decrease by one. That is, the heading of every section thereafter should have an <h2>, the subsections of those sections should have <h3> headings, and so on. A common mistake is that people will look at the appearance of a heading in a design, and assign it to <h3> or <h4> based on that, when semantically (i.e. the meaning), the heading introduces a main section of the page; in this case, it should actually be an <h2>. Remember that you can always style headings as you desire, so the HTML (i.e. which heading element) you use should reflect the meaning of the heading on the page, not the visual design you've been given.

    Another reason this is useful is that a lot of screen readers allow users to navigate the page by going to different landmark elements. For example, they can go to the next <h2>, or the next <h3>, etc. Thus, if two sections are the same level in the logic of the document, you should give them the same heading level (even if the headings are styled differently).

    2) ARIA roles To help screen readers understand your web page, there are many different attributes like aria-*, e.g. aria-role. For example, if you put an aria-role="button" on a <div>, screen readers will interpret the <div> as a button, which then indicates to the user, who may have trouble/may not be able to see your web page, that they can press it. Without this role, there's no indication (aside maybe visual indication) that the <div> can be interacted with.

    The thing is, different HTML elements have certain aria-* properties by default. For example, a <button> element already has aria-role="button" built in, so screen readers will interpret as a button without you needing to remember to add the appropriate ARIA role! Thus, using semantic HTML makes it a lot easier to make your websites accessible.

    3) Lists Think about which content on your page is semantically a list. For example, in a lot of Frontend Mentor challenges, you'll see a series of cards on the landing page describing the features of a product. I like to make these into lists using <ul> for the parent container and <li> for the individual cards, instead of using <div>s in either case. Why? Well, the <ul> now gets aria-role="list" automatically, and each <li> gets aria-role="listitem", so screen readers can now interpret these cards as a list, which is what they are semantically: a list of features for your product.

    Another neat things is that, upon entering the list, screen readers will signal to the user that they're entering a list, and it'll even tell them the number of items. Imagine instead that you have a list of <p> tags for the features of a product. A screen reader would read them one after the other, without telling the user its a list. This leads to confusion (imagine you're being read the words aloud without any breaks between items), and using an unordered/ordered list prevents this.

    I hope this helps! If so, feel free to mark this comment as helpful. Either way, I hope these pointers will help you write more accessible web pages. Best of luck in your future projects!

    Marked as helpful
  • P
    Grog the Frog•480
    @GregLyons

    (Doesn't look like I can edit my solution question, so I'll post a comment instead.)

    For some reason it says "SUBMIT QUERY" on the button in the Frontend Mentor screenshot for my solution, but when I go to the site link it just says "SUBMIT". Also, I don't have the word "query" anywhere in my source code. If anyone knows what this could be, let me know!

  • P
    Grog the Frog•480
    @GregLyons

    Good work!

    I actually think your solution to the tricky image-hovering problem is pretty good. When you say you're not entirely sure how it works, is it the CSS that you wrote that you're having trouble understanding? The hover effect is achieved using the :hover selector. The key is your two rules:

    .container:hover .image-equil {
opacity: 0.3;
}

.container:hover .middle {
opacity: 1;
}

    The rules are stating the following:

    1. When .container is being hovered, reduce the opacity of any of its .image-equil descendants.
    2. When .container is being hovered, increase the opacity of .middle (which is otherwise at 0) to 1.

    I believe what's happening here is this: the background of .container is that teal color, so when you reduce the opacity of .image-equil--which is taking up all of .container, the background color shows through (Rule 1). Then, the content of .middle consists of the eye image (which you've centered using CSS), and when hovering the eye becomes fully opaque, and actually blocks the portion of the .image-equil that is under the eye image (Rule 2). This is the desired effect, as you don't want to see the NFT image through the white eye (according to the design).

    I don't think it's necessary to have the .middle <div>, as you already have the .middle class on the eye <img> itself, so even without the <div> it'll still be a descendant of .container, and Rule 2 will apply to it. Other than that, I don't see much way to simplify your image hovering thing.

    Two more things I want to point out:

    1) For the author name "Jules Wyvern", you have a separate <p>, which you set to display: inline; so that it'll be on the same line as "Creation of". There's already a specific HTML element for what you're trying to do there, however: the <span>. Using a <span>, you'd have

    <p class="creator">Creation of <span class="name">Jules Wyvern</span></p>

    Since <span>s are inline elements, there's no need to change the display property in that case. This is also better since, if you think about the problem in terms of what the HTML elements you have are saying, they're indicating that "Creation of" and "Jules Wyvern" are in separate paragraphs, which is not what you're trying to convey. Instead, you want "Creation of Jules Wyvern" to be a single paragraph <p>, and then you can change text within that paragraph using a <span>.

    2) When you feel ready, I recommend learning Flexbox as soon as you can. It'll make solving these UI/layout challenges a lot easier. For example, your CSS:

    .eth-txt {
    position: relative;
    display: inline;
    width: 2rem;
    padding-right: 3.25rem;
    color: hsl(178, 100%, 50%);
}
.days-left {
    display: inline;
    position: relative;
    width: 2rem;
    color: hsl(215, 51%, 70%);
}

    which you use to position the ETH text and days left, only works for the very specific width of the box. If the width of the .card-body element were to change at all, suddenly your padding-right on the .eth-text would no longer make it look like the two pieces of text are on opposite sides of the same line.

    A more robust (i.e. works at any screen size/container size) would be to put your .eth-text and .days-left in a wrapper <div class="wrapper"> with

    /* Selects the .wrapper <div> */
.wrapper {
  /* Turns .wrapper into a Flex container */
  display: flex;

  /* Direct children of .wrapper placed on opposite sides/spaced out evenly up to the edges */
  justify-content: space-between;
}

    (Note that you'd need to put the ETH icon in the same block as .eth-text to make this work--but this would be the solution without the icon.)

    I hope this helps. If so, feel free to mark this comment as helpful. Either way, best of luck in your future projects!

View more comments