Quiz

1. What is the difference between label and name?

   Good question! The name is primarily for use by the software. For example, in my database course, a user might fill out a form with their rating of a dish on Wellesley Fresh. The input might be named rating and have a value of 4. So the back end gets rating=4.

   Meanwhile, the label is for the user. That rating of 4 might be a radio button with a label of "good". (Or maybe "bon" if the page is in French). Or it might be a similar drop-down menu. Like these:

   
       <label><input type="radio" name="rating" value="4"> good (bon)</label>
   
       <!-- or -->
   
       <label for="rating-menu">Rating</label>
       <select id="rating=menu">
           <option value="5">Excellent (tres bon)</option>
           <option value="4">Good (bon)</option>
           ...        
       </select>
   
   

2. I didn't understand under what circumstances Structural Version of Labels won't work and we will need to use the ID Version?

   One example is the SELECT menu above. The structural should work, but it sometimes confuses the validator, while the FOR/ID doesn't confuse the validator.

   Another example is where the text inputs and labels are in two columns of a table. (We haven't learned tables, because they aren't often necessary, but they can be useful sometimes.)

   label	value
   Username

   
       <table border=1>
           <tr><th>label</th><th>value</th></tr>
           <tr><td><label for="username">Username</label></td>
               <td><input id="username" name="username" type="text"></td></tr>
       </table>
   
   

3. Could you elaborate a bit more on the MENU element? I am a bit confused about how it differs from elements like select or radio buttons when presenting options

   The MENU tag doesn't exist. It was just there to distract you from the correct answer.

4. I was wondering if there is a way to have a back up for some types (such as time and range) that were introduced in HTML5 so that if they are not be supported by some browsers, a different version (like type=text) is supported? For example, I remember in the readings before, not all browsers supported transparency for the colors so we were supposed to include another color as a backup in CSS, is there something similar for the unsupported types in HTML?

   Great question! If browsers don't understand a type (like time and range), they fall back to a text box, since that's universal. So, that behavior is built-in. But it's great that you are thinking about that!

   Also, transparency is pretty widely supported nowadays, so the color backup is less important than it once was. But again, it's good to think about it.

5. Is there a way to restrict input by custom parameters? (ex: make it impossible to type in special characters or uppercase/lowercase letters or a different language, etc) I know we can just test the string afterwards and make the user retry if the input is invalid, but is it possible to get the same effect as the number input (just not adding the symbol to the input box in the first place if it's invalid) for custom rules?

   Yes! Later in the course (if there's time), we'll learn how to add some JavaScript to do form validation: checking that inputs are proper, including things like you describe. There are some built-in mechanisms (patterns and such), but also a way to hook our own JS into the form mechanism, so that our code gets run instantly and automatically, giving the user immediate feedback.

   But it sound like you don't even want to wait that long. Yes, it's possible to hijack the keyboard event handler (using the input event) so that the user can't even type a letter into a text box that is supposed to hold a number, for example. So, we kinda already know how to do that.

6. Can you explain the <style></style> inclusion in the last example of the Coffeerun form?

   I think you are talking about this:

   
   <style>
           /* the following is applied to any form input that is in focus
         (the user is typing into it), is required, and is not valid. Try
         typing something that is not an email address into the email
         input. */
   
           form :focus:required:invalid {
               border-color: #a94442;
               border-width: 2px;
           }
   
       </style>
   
   

   I appreciate the careful reading you have done. However, this is a topic we will discuss later in the course when we get to form validation.

   In a nutshell, required form inputs have a :required pseudo-class on them and invalid form inputs get the :invalid pseudo-class added to them by the validation code. This CSS changes the border to highlight invalid form inputs.

7. Would it be possible to store users' statement into variables and then perform if/else statements on them? For example, if the user inputs something, it could show them a different part of the page?

   Absolutely! That's what we'll do next time, after the break!

8. Currently no, thanks!

   Great!