Looking to hire developers?
For this challenge I used:
zwnj; method to make the stats list keep it's semantics even using Voiceover in Safari@ApplePieGiraffe
Posted
Hi, Grace! 👋
Nice to see you submit another solution! This one's great! 👏
I noticed how you used a combination of pseudo-elements and CSS background images to add and position the background SVGs, which I thought was quite interesting! The images stay nicely in their place when the screen is resized. 👍
Happy coding! 😁
@usanCode
Posted
Dear @Grace, How do you do! I have done this challenge too. I have noticed in your webpage, the two main background-images just stay in their initial positions even when reducing the viewport's width . My approach about this issue was to define the background-image property for each of these two images. The result is not quite satisfying.
@tarasis
Posted
Thank you for sharing this take. Gives me something to think about and how I could / should refactor my own attempt (which I completed yesterday).
@JeffreyAllenLance
Posted
Hey Grace!
I just wanted to say this solution was so helpful for me as a new developer just to see how to approach a simple project with a mindset of accessibility, using semantically meaningful tags and modern styling solutions to aid screen readers. I really learned quite a bit just stepping through your code and deconstructing what each piece was doing and why. Thanks so much for sharing it!
@Mattvp21
Posted
Hi Grace,
I studied your html a bit to see how you handled the bottom portion of the card and I like how you used the section tags with the header and footer. What I’m getting at while I look at solutions is there’s a lot of different ways to tackle this, just some solutions make life easier than others. I’m going to do a new exercise this weekend and try and put this into practice.
@axevldk
Posted
Hi, @Grace. I have studied your code and learned a lot about BEM naming usage. But I have a question on your code. I think one benefit of using BEM naming is that we can nest classes in scss easily. In your code, you separated classes individually, but I think it would be better to make them nested.
Like, .c-profile-card { &__header { ... } }
I hope to hear from you about this. Thank you ~
@axevldk for years that's how I did it actually. But in my new job, the convention is to only nest children that depend on the parent - so direct children selectors, pseudo selectors, media queries. The reason is that it's much easier to read, to search for classes when bug fixing, and to isolate what elements you're working on at a quick glance.
Since working there over the last month, Im feeling the benefit and decided to start following that in personal projects too.
I could nest all under the main parent (c-profile-card), but I never nest multiple css selectors (like classes) to style an element, to keep specificity low.
@AlexanderMelox
Posted
@axevldk Same here, nesting is neat but after 1 nest it get's really complicated. I will do nesting once like this...
.header {
&__name { ... }
}
or like this
.header { ... }
.header__name { ... }
@SzymonRojek
Posted
Hi Grace!
Amazing solution, lots of to learn from you, thank you so much. I did not publish my solution yet because I am still learning HTML and CSS (beginner), anyway I did it already but I have to learn a bit more about sass first.
If you do not mind I have got few questions to ask:
@function percent($size) {
$percentSize: $base-font-size / 16 * 100%;
@return #{$percentSize};
}
so we can get the percent by the function which is 18/16*100 = 112.5 percent. Why there is a parameter $size? It is not returned.
In the HTML selector you have written font-size: html { percent(18) }. Can you explain to me how does it work?
Is it percent(18) mean that 18 / 16 *100 which is 112.5 percent ???
This is quite important to well understand because later you are using REM ( relative to font-size of the root element). It is very interesting for me because normally I did not use percent for fonts, only px - for example html {font-size: 20px;} then for another selectors I have used rem: .footer__text {font-size: 1rem}.
About rem:
@function rem($size) {
$remSize: $size / #{$base-font-size};
@return #{$remSize}rem;
}
for example rem(6) means that 6/18=0.66666667, yes? Here you have created parameter $size and this parameter has been used inside of the body function.
Why do we have to use hashtag and curly brackets #{$base-font-size}?
Another question is about headings h1, h3. You have used them for the screen readers because of accessibility - they have a "sr-only" class which is hidden for the main layout in the browser. Is it sometimes not the case that the headings are mainly intended for the project generally (design), for these parts of website which are also not hidden? Can we use for example paragraphs or spans instead of h1, h2,h3... ? What's about [aria-labelledby] or [aria-label]? This topic is very tricky for me.
Thank you for your help :)
Hi @SzymonRojek
I wouldn't get too caught up in thr sass functions. I might remove them actually, as they were more for my own learning, playing around. I've used scss for years and almost never touched functions, so you don't need them.
In my percent function I don't think any of it is necessary. Its only used to set the html font-size as 112.5%, which I could've done in a calc(), or could have just written in as font-size: 112.5%.
As browsers have a default size of 16px, 112.5% means the same as 18px (asked for in the style guide)
It is usual to set base html size using percentages as a unit, not pixels because it is a relative unit that can be scaled up or down.
The second rem function is simply to convert pixels to rems. I will almost always use rems for font sizes, and usually a font scale has all been set up in variables anyway, so the rem function is not something I'd reach for often at all. (just playing here, like I said)
The hash tag and curly brackets is just the format you have to use to pass sass variables into calculations. Again, rarely used, so not that important.
Your last questions are the really important ones. Semantics matter a lot. I added hidden headings because every page should have a h1 and every section should have a heading. When I look at a html document I think would this make sense as a written document, or does it need more headings? You can make any content visible only to assistive technology, but I think headings and form labels are the most common. They may be left off a design, but should still be present in the html document to give structure and meaning.
I hope that makes a little more sense. I think I will swap out the sass functions to be honest as they can cause confusion for others and were really just an experiment.
@SzymonRojek
Posted
@grace-snow Thank you so much for your experiment with these functions. I was really glad to check it out.
I red about pixels and rem, em, %. Opinions are divided which one is better but definitely it is not good to swap them in the document. After your explanation I will do:
:root {
font-size: 125%;
}
From the other hand doing everything in multiples of 20 isn't all that great, but a common suggestion is to make the apparent size of rem equal to 10px. The magic number for that is 10/16 which is 0.625, or 62.5% :)
Also thanks for the last point of your explanation. In the internet a discussion is still going on how many times we have to use each heading - only one H1 tag per page and put all of them in the correct order. Google evidently does care that much.
“We do give it a slight boost if we see a clear heading on a page because we can understand this page is clearly about this topic” - John Mueller.
Now, I know that you have added these headings because it is easier to navigate what is going on the page, or inside of the component, which is very helpful especially for blind people, screen readers. Also semantic markup has other benefits beyond accessibility.
Join thousands of Frontend Mentor community members taking the challenges, sharing resources, helping each other, and chatting about all things front-end!
Join our Discord
