My code kept ‘failing’ the site’s test until I changed the actual label text to a single word in lower-case. That seems like a poorly designed test process (my opinion, anyway). Displayed text is not the challenge; attributes are. My output worked and displayed correctly with many edits changing the locations of and . Only the “testing” reported erorz.
The challenge is very much also about the label. Just look at how much of the challenge text is devoted to it. The test is just checking the values to see if they are correct.
Yes, that was the remains of one of my many attempts to track down what the problem was. Using “indoor” makes no difference in this code since it is not valid html, anyway. But it does “upset” the site’s testing since the parser is not very informative. Most “misteaks” give the same output. I did manage to get a “Pass!” from the parser but not before sending my message. It’s part of learning to code most languages; make one change at a time and sometimes it helps to note what those changes are and the results… every time!
Thanks for your quick reply! It’s a bit unusual for some free coding sites!
Actually, the text in the label button can be almost anything that would be appropriate and helpful to the user. Of course, the parser may not accept (pass) text that does not match the lesson instructions.
I’m disagreed, in real life scenario maybe, but in the test you need to do what the test is asking to do. And here is very clear:
Add a pair of radio buttons to your form, each nested in its own label element. One should have the option of indoor and the other should have the option of outdoor. Both should share the name attribute of indoor-outdoor to create a radio group.
There will be a lot of tests or projects where you maybe want to change something because it seems more logic to do it, but you can’t because you need to fullfill the user stories exactly how their are written. Lets say tomorrow you have a work to do for someone and this person ask you to add a button with the text “CLICK ME” (which is very bad for accesibility), you can tell this person why he or she should change that text, but at the end if he/she dont want to change it you will delivery your work as was requested.
We are a group of people who Believe Strongly, and Care Deeply about helping others move forward to a more successful Educated Place in their lives.
I welcome you to join our community, but I want to say something to you first:
I want you to understand, that when you make small criticisms, like referring to something as “Poorly Designed”, That everything here, is run by volunteers… Who Essentially have given “Blood, Sweat and Tears” to make all elements of freeCodeCamp succeed.
There are literally people all over the world, engineers, computer scientists, people who help with Translation and individuals who produce tutorials for freeCodeCamp on video for YouTube, who believe in the effort to Make an education in Code available to ALL PEOPLE… Not just people who can afford it, in first world countries.
My BAD!! Thanks for explaining the concept behind the site and how it is maintained. My only excuse is from not so good experience at other coding sites where “support” was less than helpful. Even some sites that charge didn’t have the feedback I’ve seen here.
I have learned that the trick to the parser is to follow the instructions to the letter. Sometimes one can try different things and see the results in the right-hand display column but always revert back to the instructions before asking for the parser. The parser is like any other software; it does exactly what it is designed to do. It is not designed to “read my mind”! At least not as well as my wife can!!!
It’s totally ok to have frustrations or suggestions for improvement! Frustration is a natural part of the learning process (if it isn’t, I’m sure in trouble!), so you shouldn’t feel bad for being frustrated!!
Computers are tragically, utterly literal machines. Sometimes, our tests are a bit strict, but a lot of that comes from computers being only able to understand exact, literal instructions. If we tell the computer to check for the label named “Indoor”, it isn’t smart enough to check for all of the different variations that might be in use. It only checks for the one version that we ask for, with exact capitalization.
You’ll see this as a general theme as you learn more. Javascript syntax is even less forgiving and needs to be even more precise. Remember, computers are just really dumb pieces of rock that we tricked into doing really fast calculations by using lots of electricity! Computers need really specific instructions - they get confused easily
As tests go, it is pretty clear. And yes, its a pain when it is expected that we match spacing or punctuation or casing.
But there is a method to this. Often, we as developers are handed a “specification sheet” by a team lead, a manager, or someone outside of our development sphere. We don’t know why we got this particular spec, we just know what our markers to pass are.
It may be that we have to match some HTML to some given Javascript hook - we don’t know. Maybe we need to pass a very particular value from a form to a backend API - we don’t know. Maybe we are being given a particular string for any of eighty reasons, none of which we know, and none of which matter. They are outside of our responsibility.
What is our responsibility? To pass the test, by matching its expectations precisely. As @JeremyLT wisely pointed out, parsers are very literal. "a big cat" is not the same as "A big cat", even though we can see they are semantically identical. They are not literally identical.
Thanks for explaining the concept behind the site and how it is maintained. My only excuse is from not so good experience at other coding sites where “support” was less than helpful. Even some sites that charge didn’t have the feedback I’ve seen here. 
