..
What challenges did you encounter, and how did you overcome them?..
What specific areas of your project would you like help with?..
No specific areas.
Should I have handled submitting the form differently?
Probably just the structure of my styles in general but nothing in particular.
The hero images on desktop. I was able to get have them expand outside the width of the screen using negative margins. Then at 1440px I used clamp()
to reduce the negative margins to 0 otherwise the screen continues expanding and reveals the clipped portion of the images which looks ugly. It works but I wonder if there is a better way to achieve this.
I'd like help figuring out how to make the grid intrinsically responsive if possible, so I can avoid using media queries as much as possible. This may not always be possible but I think there could be a way. I'm trying to model Andy Bells way of thinking by making everything fluidly responsive.
The whole .card-grid
class. Is there a better, cleaner way I could've built the layout in the design?
..
What challenges did you encounter, and how did you overcome them?..
What specific areas of your project would you like help with?..
Firstly, the <summary>
is hoverable indicating that it should probably be clickable but it's not. Only the plus/minus icon is clickable so it should be the whole summary.
I also couldn't trigger the open/close of the accordions using my keyboard only. To make your solution more accessible, address these two issues.
Next major thing is that you've created a custom accordion component which uses JS. But HTML actually now has a native element designed exactly for accordions called <details>
. I would suggest refactoring to use this element.
Few minor things:
The background image could probably just be done in CSS rather than as an HTML element on the page.
Personally I wouldn't use the <h4>
and <h6>
the way you have, especially the <h6>
. It's not a heading so this could be confusing to people with screen readers.
Also looks like some styles have been copied over from the interactive-rating-component challenge, so it would be good if they were cleaned out of the codebase.
Most importantly, the accessibility around the radio buttons could be improved.
For starters, there are no :focus-visible
styles meaning when I tab through the page I can't tell whether I've focused onto the inputs. :focus-visible
can be used to add an outline around the inputs to make it clearer they have focus, which is the case when the submit button is focussed.
Secondly, when going over the radio buttons with a screen reader, all that's read out is "Unchecked, Radio button - <num>". This isn't very descriptive to a person using a screen reader especially since the body text doesn't actually explain that they're leaving a rating out of 5.
You're using tailwind which believe has a .sr-only
class which visually hides its content but keeps it in the dom, so that it can be read out by screen readers. So you could do something like <span class='sr-only'>Rating </span>1<span class='sr-only'> out of 5</span>
and the screen reader would read out "Unchecked, Radio button - Rating 2 out of 5"
A few more more minor things:
There's no need to use opacity on the You selected <num> out of 5
text. It gives it the appearance that the text is 'muted' or disabled.
The padding for the card is actually different on large screen vs mobile screen. On large it's 2rem, mobile it's 1.5rem. Try using clamp()
to generate a fluid value that can be used here, it'll save having to use an arbitrary breakpoint. Have a look at Utopia for generating the clamp()
value.
I used Astro for the first time which was really nice. What I might do differently is how I style the components. Astros scoped styling is nice but I wonder if having the styles in their own stylesheet is a bit neater and easier to follow since you'd use classnames instead of Astros autogenerated fingerprints.
What challenges did you encounter, and how did you overcome them?Astro encourages using its scoped styling, but due to this when I tried using a separate Astro component in a style selector I found it didn't work despite using :global()
in the selector. So I decided to combine the components into the one file again instead of having them in separate files.
Probably just the structure of my styles in general but nothing in particular.
Disregard the "00" labels in the popular articles section at the bottom of the design comparison. I think the tool frontendmentor uses to generate the screenshots for the comparison must use an outdated browser or something. I've noticed similar issues on other challenges which used styles that are relatively new.
If you view the live site you'll see the correct label numbers.
Some areas for improvement:
I think the nav switches to the mobile nav at a point that's unnecessarily wide. It's still at a decently wide tablet screen where the desktop nav has plenty of room. I'm not saying it's bad at all, just that my personal preference is that I'd make the switch happen at a narrower point.
Heading hierarchy could be improved. There can be more than one <h1>
on the screen if they're in their own <section>
s. Therefore the "New" heading could be a <h1>
while the article headings inside that section could be <h2>
s. Similarly, the popular article headings could be <h2>
s instead of <h3>
s. I also used visually hidden <h1>
in this section that contained the text "Popular Articles" for accessibility purposes.
You could simplify the javascript by using a single button that is relatively positioned and has a high z-index, so that when the mobile nav appears the button actually appears above it, allowing you to click it again. The javascipt then gets simplified by only having to add an event listener to one button and in that event listener there's an if statement that determines whether to add or remove a class. You would also then use the applied class to determine whether the button displays the open or close icon. You could look at my solution to understand what I mean.
For my solution I took a lot of inspiration from Kevin Powell's solution, especially for the mobile nav. His solution also taught me some uses for aria attributes which are good for accessibility. I think you could learn a from this video like I did, just try not to copy the code as is and try watching it first then seeing if you can do it on your own.
I think you could benefit from Andy Bells teachings as I have. I've learnt a lot from learning about his css methodology, CubeCSS. It's similar to BEM but allows for even more reuse by coming up with composition classes (layout) and utility classes (think tailwind). Once you've gotten the layout done you can then add in your block classes.
An example in your code of where CubeCSS could make it neater is where you have:
.hero__button:nth-child(2) {
background-color: var(--Purple-600);
}
This style can only be used by one single thing. That is, the second button inside .hero__button
. But changing the background colour of an element could be a pretty common thing. So you move this style into a utility class, something like .bg-purple-600
. Now you can apply that class to the second button as well as anywhere that may need it, rather than having to repeat the style in some other elements class.
When you start approaching your css in this way, you might find your css becoming neater and smaller as you create more and more reusable classes.
I’ve been working on another grid challenge. To be honest, I don’t think the grid layout itself is too difficult.
What challenges did you encounter, and how did you overcome them?However, I’ve realized that I have some misunderstandings about basic CSS concepts while using grid. This practice requires applying identical color designs to each section, and organizing the CSS has been a challenge for me. I think that’s why I’ve spent almost four hours on it!
What specific areas of your project would you like help with?I believe I have done my best to organize my code structure and address some minor issues. If there are still any mistakes, please feel free to point them out!
You should look into using BEM class names. You'll be able to make more reusable styles rather than having to target things by id. In real production applications you'd rarely be styling by id, if ever.
Using BEM would help in situations where you're hardcoding data. For example, in src/Section.jsx
you have Nickname == "daniel" ? (<svg>) : ""
. So instead of adding all of the data used in these testimonials into an array and iterating over that array to render each card, you could just instantiate each individual card and apply modifier classes that change the appearance of them. So you might have a .section--with-bg-img
class that applies the quote mark background image, instead of using that ternary operator and checking for "daniel". You could also have a modifier class called .section--span-2
which is what makes the section span 2 rows or columns. This way the styles are more reusable instead of relying the exact data that goes in them. The styles shouldn't care about the data.