We Keep Coding

jQuery val or javascript changing value, validate the field even if the value don't match with the Validation Properties

Element Example:
<textarea class="form-control" id="presentation" required="" minlength="10" maxlength="300"></textarea>
If manually, insert any text, the validation is set to Valid if the length is between 10 and 300 chars.
Example:
if i manually write "Hello" on the field and run:
$('#presentation')[0].validity.valid
/*will return "false" as expected*/
but if i use any of this way to change the value of the field:
$('#presentation').prop('value','hell')
//or
$('#presentation').val('hell')
//or
$('#presentation')[0].value='hello'
It will cause:
$('#presentation')[0].validity.valid
/*will return "true" and will cause a validation problem*/
it set the field to valid, and the only way to revalidate is to change the value in the field, manually.
this will cause that invalid data could be submitted in the form this field will not be checked.
This is happening in Chrome, firefox, edge and opera.
do you know if there's anyway to force the field to validate his value?
here a fiddler with this problem:
https://jsfiddle.net/rfigueiredo/jnuhfsc7/20/

Strange behaviour when input element switches type to hidden

I discovered a strange behavior of input text/hidden elements and I would like to know why this happens.
I have an input text box that has a value, let's say "test". I delete the input element value and I change the type of this element into "hidden". If now I switch it back to "text" the original value is there! If you don't fully delete the value of the text element but change it your changes are preserved. Why if you clear the element value this change is not preserved?
I created a fiddle that can show you what I mean.
function toggler() {
var iobj = document.getElementById('test');
if (iobj.type == 'text') {
iobj.type = 'hidden';
} else {
iobj.type = 'text';
}
}
<button name="toggle" type="button" onclick="toggler()">Toggle</button><br /><br />
<input type="text" name="test" id="test" value="sample" />

This has something to do with how different browsers handle defaultValue property of the inputs, whenever their type is changed. In this case, when the input type is changed and the .value is empty, Firefox uses the last non-empty value as .defaultValue property of the input. When the type is changed into text, Firefox uses the .defaultValue property for setting current .value property of the input. Chrome doesn't do this, i.e. it uses the last value, empty or non-empty, as the .defaultValue.
Here is a demo on jsfiddle. Comparing the logged values on Firefox and Chrome console, should demonstrate the different behaviors.
I should also mention that according to my experience/knowledge, Firefox is more standards-compliant than other browsers.
That being said, changing type of an input has never been a good idea. Form elements are very different and browsers handle the case in different ways.

Dynamically creating an input field with disabled = true is setting null values to zero

I have a timesheet table. At the bottom of the table there is a button which allows me to add a row. Understandably, all the cells in the new row start off empty. The JavaScript uses:
txtFld.setAttribute('value', '');
to do so.
However, in some situations I want some of the new fields to show up but be disabled so I (in those situations) add in:
txtFld.setAttribute('disabled', 'disabled');
The problem is that, when doing this, after submission, when the table re-renders itself, all those empty values show up as zeroes instead of empty strings. As far as calculations go, that's fine, but I don't want rows of zeroes. I want empty cells. If I take out the disabled part, it works fine.
I've temporarily remedied this by, instead of using disabled, using readonly, which seems to give me the desired results. The only problem is that, while the text field remains non-editable, the user CAN place the cursor inside the box. I want the cleaner, "can't even click in here" that the disabled gives me.
Any thoughts on why the disabled feature is doing this and how I can use disabled without the resulting row of zeroes?
For the record, I've mixed and matched every combination of:
txtFld.setAttribute('value','');
txt.setAttribute('value', null);
txtFld.value = '';
txtFld.value = null;
with
txtFld.setAttribute('disabled');
txtFld.setAttribute('disabled', 'true');
txtFld.setAttribute('disabled', 'disabled');
txtFld.disabled = 'true';
txtFld.disabled = 'disabled';
that I can think of with the same results (or worse) every time.
Thanks.

When a field is disabled, it's not included in the form parameters sent to the server.
In new browsers (IE11+, and pretty much everything else) you can use CSS to disable pointer events on the element:
txtFld.readonly = true;
txtFld.style.pointerEvents = 'none';
That'll make the element simply not respond to any clicks. (Here is a jsfiddle.) Because it's not disabled, a form POST will send the empty field to the server.
You should disable fields by setting the "disabled" property of their DOM nodes to true (the boolean constant, not the string).
txtFld.disabled = true; // disables field
txtFld.disabled = false; // enables field
The "disabled" property is treated as a boolean, so setting it to any string value (other than the empty string) will set it to true:
txtFld.disabled = "false"; // disables field
Another thing you can do to exploit the real disabled browser behavior and have empty parameters posted to the server is to use pairs of inputs:
<input type=text name=whatever data-companion=whatever-c> <!-- visible input -->
<input type=hidden name=whatever id=whatever-c> <!-- invisible input -->
Now whenever you enable the text field, you disable the hidden input, and vice-versa. That way there's always something posted.

Putting text in a number input doesn't trigger change event?

example
It appears that entering text into <input type="number"/> does not trigger a change event. I would like a change event so that I can warn the user to fix their input. How can I get a change event for this, and get the current value so that I can verify the bad input?
I've been testing in Chrome.
$('input').on('change', function() {
alert('change');
});
<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script>
put letters in me and press tab: <input type="number"/>

Try using the other keyboard events then. For example, I just added
$("input").on('keyup', function() {
alert('keyup' + $(this).val());
})
To your JSFiddle example, and the alert appears after pressing a within the number textbox.
Note: Checking $(this).val() will not return you invalid characters (at least in Chrome). It strips invalid values before returning the result (e.g., 1a becomes blank). This is also why the change event appears to not be fired when its value hasn't actually changed because the input is all invalid. To catch invalid characters, you must instead check the event's keyCode:
$("input").on('keyup', function(e) {
if (e.keyCode < 48 || e.keyCode > 57) {
// not 0-9 (note: ignores -)
alert('error!');
}
});
After messing around a bit more, I noticed that Chrome and IE10 behave similarly, but IE10 seems to have a bug in its stripping:
If you start the number input with a non-number, then IE10 (possibly 9 as well) will consider the rest of the input to be a valid number regardless of what characters follow (e.g., 1a2 is just as valid as 12 in the eyes of IE). However, in Chrome, if you enter a non-number, then it will immediately ignore the input and declare it to be invalid; in IE10, if you start with a non-number, then the behavior is the same.
One big difference in behavior is that IE10 will clear an invalid number field after blur, but, again, they only consider it invalid if the field starts with a non-number (e.g., a1). - can precede numbers, but not more than one of them.
In both browsers, if the number is considered invalid, then this.value (and consequently $(this).val()) will return blank. In IE10, you can be get the raw, invalid value if the number starts with a number (0-9). Both browsers will only fire change events when they consider the input to have actually changed and--in IE10's case--that means if the user enters abcd and then blurs the input, then IE10 will clear the field and fire a change event if it had a valid value before being changed. In Chrome, the change occurs whether the input is valid or not; if it's invalid then it is changed to a blank value.
What this means is that you can handle valid and invalid number input, but you cannot dependably get the actual value that the user has typed into the textbox.
HTML
put letters in me and press tab:
<br />
<input type="number"/>
<br />
<p id="event" />
<p id="text" />
JavaScript
function checkValid(e) {
var $this = $(this);
$("#event").text(e.type);
$("#text").html("this.value: " +
this.value +
"<br />$(this).val(): " +
$this.val() + "<br />$(this).is(:valid): " +
$this.is(":valid") +
"<br />$.isNumeric(this.value): " +
$.isNumeric(this.value)); // <- helps check
}
$('input[type="number"]').on('change', checkValid).on("keyup", checkValid);
You can check to see if it is a valid number by checking $.isNumeric. The :valid and :invalid pseudo classes do not work in IE10 with number except when the field is marked as required (not at all in IE9), but they both work in Chrome without marking it as required.

As pickypg has noted, if a user types 'abcd' into an <input type='number'> element, you cannot get the value 'abcd' via $(this).val(). (Caveat: I've only tested in Chrome.)
However, you can determine whether the HTML5 input validity constraints are satisfied (valid) or not by calling myDOMelement.checkValidity(), or looking at the individual properties of the myDOMelement.validity object. This at least lets you distinguish between a blank field (valid) and one containing 'abcd' (not valid). Check here for more on HTML5 validity.
What is rather confusing, at least in Chrome, is that if an <input type='number'> element is initially blank and then you type in 'abcd', the 'change' event is not fired on blur. Likewise when you delete 'abcd' from the field so the field becomes blank.
A workaround is testing for changes in the HTML5 validity on blur. Here's a jsFiddle to illustrate the technique. Note that you still cannot tell if the user has changed 'abcd' to 'efgh', since those are both not valid.

The event change is triggered on losing focus and it is working as it is supposed to be, you may need to use keyup.
Live Demo
$('input').on('keyup', function() {
alert('change');
});

How can I make the browser remember previous input? [duplicate]

When I refresh a page with Firefox, the values of the check boxes, input fields, etc. are kept.
Is there a way to make Firefox not keep them, using a meta tag without JavaScript?

For an input tag there's the attribute autocomplete you can set:
<input type="text" autocomplete="off" />
You can use autocomplete for a form too.

If you want to prevent remembering field values after reload, while still getting to use autocomplete:
First define autocomplete off in the markup:
<input id="the-input" type="text" autocomplete="off" />
Then re-enable autocomplete programatically:
document.getElementById('the-input').autocomplete = 'on';
this will disable autocomplete just at the right time when the page loads and re-enable it so it can be used (but the field value will be empty as it should).
If it does not work for you, try wrapping the js code in a setTimeout or requestAnimationFrame.

// Internet Explorer fix - do this at the end of the page
var oninit_async_reset = setInterval(function() { resetFormIEFix(); }, 500);
function resetFormIEFix() {
$('#inputid').val('');
if (typeof oninit_async_reset != 'undefined')
clearInterval(oninit_async_reset);
}