Yes, you understand right, is exactly that what I am talking about, you can’t go up. If the input is chilled of label you can’t target the father.
No problems with making containers they are needed, the problem, in my opinion, is when people do it when not necessary, less code better performance. Today we have a good processor and memory in the devices and because of that people have less care with the code. Many people don’t know but the modern browsers check the code looking for mistakes and they try to fix them before start rendering the page and that will consume time in the processor, space in memory because each HTML node have tons of properties, and the browser will watch all of then, and for this day the most important of that will increase the consumption of battery.
Is very good to use containers, but use indiscriminately can cause a problem that people normally don’t think about.
The man landed on the moon with a computer that owned a few KBs, and today a simple page in the browser can consume some GBs.
The hardware evolution can’t be an excuse for people to just do what they are doing this day just because the hardware can handle it. But this is a discussion that is going out the theme here.
Back to the inputs and labels, what you can do?
This is a spoiler, I still doing refactor and tests in my FCC projects, look at my Survey form.
Just saying you have more advantages if you don’t use the label to be a container, but if you use isn’t wrong but you will limit some things or work with some workaround to do it, and that is ok too.
I hope at the end of the month I finish all my Responsive FCC projects and publish them here.
Yes, but realistically you rarely need to start at a child element and go back up the tree. Sure it might have a few use cases but it rarely is an issue. It’s an edge case at best.
Also, you can target the parent, you can’t start at the child and ascend back up to the parent. That is two totally different things.
Saying you shouldn’t use containers for performance reasons is just odd. I mean you would need to flood the DOM with elements before their count became an issue. And then it’s just the number of elements and not their position in the tree that is the issue.
As for selector performance, again this isn’t really an issue, but you shouldn’t over qualify your selectors. Keep them as flat as possible.
The reasons for using and not using containers are legibility, organization, semantics, etc. things related to humans, not computers. Writing code a computer can execute is easy, writing code a human can read, understand and maintain is the hard part. But there are cases where you just need a container to get the CSS to do what you want (CSS grid has some powers that can eliminate some container usage).
I just don’t understand your argument.
If I seem a tad defensive then you should know it might be because I’m the one that coded the Survey Form example project. I also don’t want beginners to take your word as gospel just because you are assertive in your statements. I’m really not trying to be argumentive for no reason.
@Carliess I’m sorry for the thread derailment. I apologize if this little detour was distracting. Hopefully, it was still a bit useful and informative.
@lasjorg Ok, I agree with you, and I am not was aware that you developed the example.
I think I am insisting a little too much on this because beginners need to learn that make code is more about thinking about how and why to do things than just writing code.
I do hope you don’t feel like I was going after you, or made it personal in any way. I try to be open-minded and respectful while having a healthy discussion. We can only grow as developers (and people) by engaging with each other. So thank you for the opportunity to do so.
