Where does the error message come from and is it possible to style it? I looked through the other files but can’t figure this out.
For example, if I type 0 and click submit it says: “Value must be greater than or equal to 1”. Say you wanted to change the message ( for example, “Enter a number between 1 and 10”) or style it with css. Is that possible in this case?
Anything in the DOM can be given CSS properties of our liking, so yes, the message can be styled. Chances are the error messages are written in the HTML but hidden from view (with, display: none;). Dig through the HMTL and CSS and find the id or class attribute given to the element(s).
MDN documentation says you can change the message with JavaScript: https://developer.mozilla.org/en-US/docs/Learn/HTML/Forms/Form_validation#Customized_error_messages
Not sure you can change the style (font, color, margin etc.), though.
I now know how to style the error message with JavaScript. See this article from CSS Tricks:
It’s not easy, but it’ll be a good practice to horn your JavaScript skills.
Sorry how do you display the “error message” text? Is it possible to do within the exercise?
Can’t say for sure without looking at the exercise. Please post a link.to that page.
Thank you for getting back me. I just saw Masakudamatsu’s article. That helped. I deleted my comment because I thought it was redundant. But here’s the link to the exercise:
https://www.codecademy.com/courses/learn-html/lessons/html-form-validation/exercises/min-max
It’s part of the Intro to Html: Set the Minimum and Maximum.
It looks like you found your answer, but what I got from the exercise is that the HTML element will handle creating an error message for you when using the required attribute on any <input> tag.
For this exercise the result should have been when submit button is clicked will show a error message “Value must be greater than or equal to 1” but it doesn’t when input field is empty why?
as I notice that the values already start from 1 and we set the “min” value to 1 idk if this is the reason?
When the Submit button is clicked, the browser has built in behavior for that event. If we want to validate before that behavior kicks in, we need an onsubmit event listener and a handler that prevents the default behavior. Without seeing the lesson and exercise, I’m not sure what else I can add other than to speculate.
Another consideration is having an onchange listener on the input control that handles validation before the submit button is even clicked. Please post a link to the exercise so we can bring everything into view.
Okay, this one is handled by an ACTION so that when Submit is clicked that page is requested. It is that page that imports the behavior to check the user input. There is no validation other than the direct comparison in that script.
One will need to play with the model a bit to see if I can reproduce the same outcome. Leave it with me. This shouldn’t hold you up, though. Move along and expect a ping in the next day or two.
Well, that was fast, but only preliminary:
<input type="number" name="guess" id="guess" min="1" max="10" required>`
We can pay particular attention to the boolean flag at the end of the tag: required. When the field is left empty, the browser tells us the field cannot be left empty. We don’t build that validation, the browser has it built in, just so long as we include the flag in our markup.
Here is what the request URL looks like when we choose 3 and click Submit:
https://localhost/check.html?guess=3
That is directly tied to the METHOD, to wit, GET. The URL. consists of the protocol, the host (domain) and the endpoint of the action, plus a query string starting with ?. The ‘guess’ variable will be in the local namespace (global) so accessible in script.
We see the script behavior is very rudimentary, but for this exercise aptly chosen in my view. The waters can get muddy, real quick. I recommend you give all the files in this exercise a good reading over and disseminate them as best you can while you have the opportunity and time. See how all the moving parts work together before abandoning it. If not now, bookmark and come back to it in your next unit review.
I see you always talking about “DOM”. What is it, exactly ?
It will come up early in HTML, et al. DOM (Document Object Model) is the collection of document nodes (elements and their descendants) organized in a tree like structure that treats every node as an object with its own attributes. Those attributes are the ones written into the element, as well as the CSS styles associated with them. This is all constructed when the page loads.
Using script we can poll the DOM, manipulate elements, add elements, remove elements, add or change styles, and so on. It is all one big namespace in memory.
Note that when we manipulate a document in memory, it has no effect on the source HTML that was downloaded from the server. That remains unchanged and can be restored with a page refresh. DOM is HTML in memory, not in file form.
Thanks, your comments add so much value to this course
I noticed the input field is validated after hitting the Submit element, is it possible to validate user input before the submit action like when you leave focus on the input element?
If leaving focus entails going immediately to the Submit button, it would take a script intercepting the onSubmit event. This can be tricky, and may need to be explored.
Question remaining, how to carry out the Submit once the processing is done? Again, up for discussion.
Just popped up idea of tracking changes to, rather change of focus. onChange is an input event, is it not? That would give an opportunity to validate as typing is taking place. A red signal text would tell the user we are monitoring their input. Once it is valid, the signal goes green and the error bar dissolves. When they go to submit, this field will be already have been validated.