Mobile-first 3-column-preview-card example

Thanks @shashilo

1. The naming follows a component naming system that still uses BEM. The component is treated as the only block
2. I intentionally use em for padding on buttons so that it will scale when the font size is changed. This allows for size modifiers that only need to change the font size (btn—large) and can improve readability for supe-enlarged and/or zoomed views because the space around the element increases proportionally

With all the others I don’t even try to match specifics on these challenges. If I was pro member I would have and use the figma file to make these accurate, but am not going to worry about that when working from static images 😊

BEM can be enhanced to whatever you and your team feels is best. I was just mentioning that it didn't follow the proper BEM mythology.

If you want the font to be responsive, you should use clamp() instead of EM. Clamp() is a more stable and modern way to make responsive fonts.

Correct. The goal isn't to be pixel perfect, but it you should have a high level of detail when you implement. I too am not a Pro member, but I can see issues by pulling up the design and implementations side x side. I've worked with several designers and product owners who cared about every single pixel. I was lazy with my implementations early in my career until I was pushed to implement pixel perfect to what the designer had provided. They put their research and skills into designs, it's our job to make them come to life. So they're going to ensure that this process is as precise as possible.

@vanzasetia that’s a good point, they should have width and height really. And that’s easy to add in this case.

The c- prefix stands for component. Strictly speaking I would also use other prefixes like u- for global utility classes etc but I find this is the only one needed a lot of the time (in a real project, I know everything about this will live in the components directory)

CSS custom properties can be changed “live” in the browser so are particularly useful for things like color theme toggles (I’m way over simplifying but that’s one common use/reason). In this particular challenge I could use either and it would make no difference

@emestabillo there’s just no reason for it to be a ul. This is standard content that has headings, text and link so the headings already provide enough structure.

Assistive tech users commonly complain that list-itis is the new div-itis these days now that card-based designs are so popular. I would only use a list for card listing component or search results using cards or something if there are loads of them and if it’s helpful for a user to know how many are there and that isn’t communicated anywhere else.

I considered using article or section in here for the cards but again it doesn’t add anything. Article is really for when content could be distributable and section for more distinct content that deserves the extra announcement.