I should clarify, "the value appears empty" because badInput exposes it as the empty string. But in reality, the user has input a value of some kind, regardless of whether it's valid or not, and this value should not be ignored when determining whether a control suffers from a missing value or not.

Appears to whom? The script? I don't really understand the problem here.

> Appears to whom? The script? I don't really understand the problem here.

Yes, to the script. I'm not saying that the script needs to see the inner text value, but it does need to be aware of the actual state of the form control, as in, whether a value was entered, or not, and if it was, whether that value is usable or not.

I've left a more detailed explanation of this on the Chromium bug. For humans, we don't expect to be told that we haven't entered anything, simply because the value we've entered is not usable. Setting `valueMissing` to true in these cases leads to this. However, if we only consider the inner text value when determining whether the control is suffering from bad input, then we don't have this problem, and we accurately reflect the state of the form control.

This is desirable for everyone, from humans who are using the form controls, to frameworks who are rendering validation messages or deciding whether or not to submit a form over XMLHttpRequest, etcetera. There is no valid reason to lie to the script context and tell it that no value was supplied, when in fact a value had been supplied. Doing this effectively lies to the user as well, and this is not good.

(In reply to Ian 'Hixie' Hickson from comment #2)
> Appears to whom? The script? I don't really understand the problem here.

Currently browsers that are implementing HTML5 form validation we are seeing that both badInput and valueMissing are returned for inputs such as number type. From a users point of view a value has clearly been provided so raising valueMissing seems to be incorrect.

This is causing an issue from a developers point of view, when providing more in-depth validation responses that go beyond what the default browser validation provides. We desire to have trust in the existence of the valueMissing boolean, and should not have to say, required is missing if (valueMissing && !badInput).


Our request is to have the specification for valueMissing to directly and explicitly express it can only be marked as valueMissing if no value has been provided, regardless of the validity of the provide value. ie if a Alpha string is provided for a number, which causes a NaN error and the internal value becomes null, this shouldn't count toward valueMissing as the user provided a value and is still on the screen within the input.

(In reply to caitp from comment #3)
> [the script] does need to be aware of the actual state of the form control

Why?


> whether a value was entered, or not, and if it was, whether that value is
> usable or not.

if e.validity.badInput is true: a value was entered but it is not usable
if e.validity.badInput is false and e.value is empty: no value was entered
if e.validity.badInput is false and e.value is not empty: a value was entered and it is usable.
   

> I've left a more detailed explanation of this on the Chromium bug. For
> humans, we don't expect to be told that we haven't entered anything, simply
> because the value we've entered is not usable. Setting `valueMissing` to
> true in these cases leads to this. However, if we only consider the inner
> text value when determining whether the control is suffering from bad input,
> then we don't have this problem, and we accurately reflect the state of the
> form control.

If validity.badInput is true, then it seems reasonable to me that that would be the only thing you would complain about in the user interface. Nothing seems to force a different UI right now, unless I'm missing something?


> This is desirable for everyone, from humans who are using the form controls,
> to frameworks who are rendering validation messages or deciding whether or
> not to submit a form over XMLHttpRequest, etcetera. There is no valid reason
> to lie to the script context and tell it that no value was supplied, when in
> fact a value had been supplied. Doing this effectively lies to the user as
> well, and this is not good.

Suppose that this is an <input type=number> control, and the way the control works is that the user taps on it and then draws the number using their finger, which the browser then converts to numeric input by OCRing the numbers. Now suppose the user drew a tree, and so the browser flags badInput.

What value should the browser expose in the e.value attribute?


(In reply to Mason Mize from comment #4)
> 
> Currently browsers that are implementing HTML5 form validation we are seeing
> that both badInput and valueMissing are returned for inputs such as number
> type. From a users point of view a value has clearly been provided so
> raising valueMissing seems to be incorrect.

Sure. So don't tell the user about valueMissing if badInput is set.


> This is causing an issue from a developers point of view, when providing
> more in-depth validation responses that go beyond what the default browser
> validation provides. We desire to have trust in the existence of the
> valueMissing boolean, and should not have to say, required is missing if
> (valueMissing && !badInput).

valueMissing means that the "value" attribute is blank but the control has a required="" attribute.
badInput means that the user provided some input that could not be converted into a usable value.

They are orthogonal states; it's possible for badInput to be true and valueMissing to be false, for example, if the user has entered a valid value, and then tried to edit it in a way that cannot be validly represented.

It's also possible for other flags to be set at the same time. For example, you could have rangeUnderflow, stepMismatch, and customError all set at once. I don't recommend telling the user about all three in such a situation; focusing on one (probably the customError) is much more likely to be usable. Similarly, you could have something that's tooLong and patternMismatch and typeMismatch all at the same time. I would recommend in such a situation primarily focusing on the typeMismatch, since telling the user that it doesn't match either the pattern nor the type is not particularly useful to the user.

The point here is that the API gives you all the information it can. How you use it is up to you.


> Our request is to have the specification for valueMissing to directly and
> explicitly express it can only be marked as valueMissing if no value has
> been provided, regardless of the validity of the provide value.

If we did that, then there'd be cases where required="" was set, .value was the empty string, and yet valueMissing was false. This would be very confusing, IMHO. It would basically mean that the page should then check the .value attribute instead of being able to rely on valueMissing if it wanted to know whether there was a value or not.

We are not denying the validity of ValidityState object holding multiple flags stating each condition in which the value is invalid. We are only outlying the incorrect validity is allowing valueMissing to exist at the same time as other existing validity state flags. It simply comes down to what is displayed to the user. Your references of 'OCRing' would result in a defect within the software that handles that aspect. If the user is prompted for a numeric value and draws a tree, that software should handle its own user input validation before applying the provided value into the form input. The same goes for any aspect of programmatically obtained values, it should be the role of the software to validate said value before attempting to applying it to a form control, such as which input number.

This issue comes from a Javascript developer point of view. Which processing validation for form controls we want the ValidityState.valueMissing=true to truly mean the value is missing. We see no reason to program logic to say its only missing if valueMissing=true while badInput=false (or any other flags that may be causing both valueMissing and said flag to be true). In my eyes from a Javascript point of view such logic is simply a patch for bad browser behavior.

My recommendation is simply to outline that the ValidityState object should not contain valueMissing=true if said form control currently holds a displayed value. ie in Chrome with input type number, if the user supplies 'a'. When the input is blurred, the value 'a' is retained and both badInput and valueMissing exist. That seems incorrect and miss leading.

(In reply to Ian 'Hixie' Hickson from comment #5)
> (In reply to caitp from comment #3)
> > [the script] does need to be aware of the actual state of the form control
> 
> Why?

Because the script will often play a role in communicating validity to the user, and this works a lot better if we know the actual state of the control.

> 
> > whether a value was entered, or not, and if it was, whether that value is
> > usable or not.
> 
> if e.validity.badInput is true: a value was entered but it is not usable
> if e.validity.badInput is false and e.value is empty: no value was entered
> if e.validity.badInput is false and e.value is not empty: a value was
> entered and it is usable.

The meaning of a flag should never depend on the presence or absence of other flags or properties. This complicates the system, and is arguably broken.

> Suppose that this is an <input type=number> control, and the way the control
> works is that the user taps on it and then draws the number using their
> finger, which the browser then converts to numeric input by OCRing the
> numbers. Now suppose the user drew a tree, and so the browser flags badInput.
> 
> What value should the browser expose in the e.value attribute?

The empty string is just fine. I've argued in the past that it's a bit problematic, but I think it is not totally unreasonable, and if the ValidityState flags behave in a sane fashion, then we don't need to see the actual value anyways.

---

It might be useful to flip this around, to show the **benefits** of specifying valueMissing for invalid values. What problem does this actually solve, and how does it result in a less complicated system?

This bug might be stemming simply from a misunderstanding of the validity state values.

"valueMissing" does not mean that the user has not entered a value. It means that the form control's internal value, the one that would be submitted to the server, is missing. This says nothing about what is displayed.

"badInput" means that the user has entered a value that cannot be turned into input that could be considered for submission.

These are orthogonal states.

It sounds like what you're really asking for is another attribute that tells you which of the following states you're in:

 - form control is displaying nothing
 - form control is displaying data that cannot be converted into a value
 - form control is displaying data that can be converted into a value

It's true that the current attributes don't directly provide this, but as noted in the earlier comment, you can trivially find this information from the attributes we already expose:

 - form control is displaying nothing:
     (!control.validityState.badInput) && (control.value == '')

 - form control is displaying data that cannot be converted into a value:
     (control.validityState.badInput)

 - form control is displaying data that can be converted into a value:
     (!control.validityState.badInput) && (control.value != '')

I suppose we could add an attribute that just did this logic test and returned an enum "empty", "bad input", "value"; but this would just be a convenience accessor. The bar for adding something like this is different: it's just a matter of showing that many Web pages are doing these checks and thus we could make matters easier by providing a convenience accessor.


(In reply to Mason Mize from comment #6)
> Your references of 'OCRing' would result in a
> defect within the software that handles that aspect. If the user is prompted
> for a numeric value and draws a tree, that software should handle its own
> user input validation before applying the provided value into the form
> input. The same goes for any aspect of programmatically obtained values, it
> should be the role of the software to validate said value before attempting
> to applying it to a form control, such as which input number.

Exactly. And that's exactly what is happening. The browser asked for a number, the user entered "fifteen", and the browser has no idea how to turn that into a number. So it doesn't change the "value" attribute. This is _exactly_ equivalent to the example I gave above: the browser asked for a number, the user drew a tree, and the browser has no idea how to turn that into a number. Or the browser asked for a number, the user hummed the Stars and Stripes, and the browser has no idea how to turn that into a number.


(In reply to caitp from comment #7)
> 
> Because the script will often play a role in communicating validity to the
> user, and this works a lot better if we know the actual state of the control.

Can you describe how it "works better", in concrete terms? What would you do if you had this information?


> The meaning of a flag should never depend on the presence or absence of
> other flags or properties. This complicates the system, and is arguably
> broken.

The meaning of the values don't depend on each other. "badInput" means "the user has provided input in the user interface that the user agent is unable to convert to a value", and "valueMissing" means "the element has no value but is a required field".

What I described is just what combinations of the values mean, much like "rangeUnderflow" alone means that value is too low, "rangeOverflow" means it's too high, and both together means that "max" is less than "min".


> The empty string is just fine. I've argued in the past that it's a bit
> problematic, but I think it is not totally unreasonable, and if the
> ValidityState flags behave in a sane fashion, then we don't need to see the
> actual value anyways.

I don't understand what is insane about the current definitions. They're nicely orthogonal. Can you elaborate on this?


> It might be useful to flip this around, to show the **benefits** of
> specifying valueMissing for invalid values. What problem does this actually
> solve, and how does it result in a less complicated system?

The benefit is simple: it tells you that the control needs a value, but no valid value has been provided, regardless of whether that's because a value was entered but could not be represented, or because no value was entered in the first place.

On the other hand, badValue tells you that a value _was_ entered, but it could not be represented in a valid way.

I wouldn't agree with labeling this bug as a simple misunderstanding due to the specification lacking the direct references of the inner working on the ValidityState object.
I cannot locate anything in the referenced specification pages directly stating that 'valueMissing' means that the internal value is what is actually missing, not the user provided value.
All your comments on what these flags mean in these conditions lead me to believe there is another document that possibly goes into further technical details.
If there is such a document I would like to have a link to it so that I can read it and correct what would be a misunderstanding, otherwise I feel the referenced specification may need to provide some more details as to what counts as 'valueMissing'.
Statements saying (element/control) has no value doesn't suffice as a clear explanation of the flags meaning. What the browser can or cannot do with the provided value in regards to the components inner value doesn't relate to the currently outlined definition.
While the outlined information for 'badInput' does cover aspects discussed in this defect, such as the user provided an alpha value in a numeric only input.

It's worth stating, in two browsers implementing the ValidityState for input type number, I see two completely different logic paths. Safari simply clears out the invalid values, while Chrome does not do this behavior and returns an error message regarding the 'badInput'.
Chrome's reactions to this is fine in terms of the needs it handles, but for web application developers a different and often better error message the existence of multiple flags led to the confusion expressed in the bug request.
Which already shows different interpretation and implementation of the brief specification covering the subject.

To speak in regards to your reference of convenience accessor's, this could hold benefit, because these condition checks may or may not be as trivial as expressed as it is currently uncertain which other flags are set at the same time as 'valueMissing'.
I still don't understand the push back on this request. Because the end goal is the same regardless if the specification states that if any other validation flag exist 'valueMissing' should not be true.
Because the browser will still provide the exact same message. And I see no benifit out of allowing multiple flags to be returned along with 'valueMissing', and the implementation should be handling the other messages. 
The reason for this, is because if you get both 'badInput' and 'valueMissing', and you display to the end user "Input required, blank value provided", when they are sitting there looking at the value provided.
I completely see zero benifit in the specification allowing 'valueMissing' to exist with other flags, and the other flags provide direct validation results about the value provided by the end user, and those values are used to present a message to the user.
Which means the 'valueMissing' is completely ignored in a sense, due to checking for other flags. Why should this be required by the developers.
This would make not only the browsers implementation more simplified, but it would also help Javascript programmers attempting the provide clearer and more concise error messages.
Being that the web developers are the individuals in the field really taking hold of the power that HTML5 offers I see nothing but value in this request.

To digress, I will accept which ever direction this goes and will move forward with my development.
I merely wanted to speak out to what I found to be an oddity in implementation and what resulted in unclean code to handle the issue with not being able to trust the ValidityState object.
I express this as a lack of trust in the object, because when I am returned a flag of 'valueMissing' I directly want to go ahead and inform the user this field is required and you provided a blank value, instead I have to perform asinine logic to confirm the truth of this flag, regardless of how trivial it may be.

Please understand, our point of view is taking care of the needs of whom the web focuses on, the end Users, and their experience within a web application.
Javascript provides us the ability for rapid and powerful development, and we only thrive to make our tools of choice better when we find oddities or defects.

Also, as unprofessional as it is to point this out, at this point I can no longer withhold my opinion on this subject.
By submitting this bug request I expected to have helpful and positive responses, but rather in return received what comes across as belittling and condescending remarks.
I apologize for expressing this, I only want it to be known how such responses can and are interpreted and result in non construction collaboration with the matter at hand.

> By submitting this bug request I expected to have helpful and positive
> responses, but rather in return received what comes across as belittling and
> condescending remarks.

I apologise profusely. It is not my intent to belittle or be condescending. If you could forward the specific bits of what I said that made you feel this way to ian@hixie.ch then that would help me make sure I don't do it again. Thanks.


> I still don't understand the push back on this request.

All requests get the same pushback. Adding features to the specification has a high cost, even for trivial features, and changing the specification after browsers have already shipped also has a high cost.

The cost of adding features is discussed here:
   http://wiki.whatwg.org/wiki/FAQ#Where.27s_the_harm_in_adding.E2.80.94

The cost of changing features that are implemented is that pages depending on those features to be as implemented will break, tutorials will have to be updated, tests rewritten, there'll be cross-version and cross-browser incompatibilities while the two variants are both around, etc.

This is why for all requests, I try to figure out exactly what the problem is, and see if there might be simpler ways of addressing it, or if maybe it can be avoided by changing the authoring approach, etc.

It's nothing specific to this particular request. Indeed just the other day some guy from the TV industry was asking me why his request was getting pushback. It's the same thing.


> I cannot locate anything in the referenced specification pages directly
> stating that 'valueMissing' means that the internal value is what is
> actually missing, not the user provided value.

The formal definition of valueMissing is:

   http://whatwg.org/html#suffering-from-being-missing

...which refers to the term "value" as defined here:

   http://whatwg.org/html#concept-fe-value

The "value" is basically the internal state of the control, as exposed by the .value IDL attribute. In the section on type=number, the spec says:

# User agents must not allow the user to set the value to a
# non-empty string that is not a valid floating-point number.
 -- http://whatwg.org/html#number-state-(type=number)

This is referring to the same "value" as the .valueMissing IDL attribute.


> It's worth stating, in two browsers implementing the ValidityState for input
> type number, I see two completely different logic paths. Safari simply
> clears out the invalid values, while Chrome does not do this behavior and
> returns an error message regarding the 'badInput'.

As far as I can tell, Safari doesn't show form validation UI yet at all.


> Chrome's reactions to this is fine in terms of the needs it handles, but for
> web application developers a different and often better error message the
> existence of multiple flags led to the confusion expressed in the bug
> request.

There's multiple flags because the problems are mostly orthogonal. For example, you can be under the "min" and not match the "step" at the same time. Or you can be too long and not match the pattern. Or you can have a type mismatch and not match the pattern. Or you can have any of these and a custom validity error message at the same time.

It's not hard to handle this in code. You just check them in the relevant priority order. badInput probably comes first, since if the user's input is bad then it doesn't really matter if the previously non-bad value failed to match some other criteria. typeMismatch is probably next, since if it doesn't match the type, then there's not much point looking at the other aspects. Then the custom error, probably (although maybe that should come before typeMismatch). Then you probably want to check tooLong/tooShort and patternMismatch together, and then underflow/overflow, and then stepMismatch.


> To speak in regards to your reference of convenience accessors, this could
> hold benefit, because these condition checks may or may not be as trivial as
> expressed as it is currently uncertain which other flags are set at the same
> time as 'valueMissing'.

If we defined a convenience accessor, it would be equivalent a fixed expression. This is why it's just a convenience accessor and not really particularly useful IMHO.


> The reason for this, is because if you get both 'badInput' and
> 'valueMissing', and you display to the end user "Input required, blank value
> provided", when they are sitting there looking at the value provided.

If badInput is set, there's not much point looking at the other flags (except maybe the custom one), I agree. But the solution to that is just: if badInput is set, ignore the other flags. I don't understand why the API needs to change to let you ignore it.


> I completely see zero benifit in the specification allowing 'valueMissing'
> to exist with other flags, and the other flags provide direct validation
> results about the value provided by the end user, and those values are used
> to present a message to the user.

valueMissing can only occur with the custom flag and the badInput flag. The custom flag might be set for reasons unrelated to the value itself (it might be based on other values, e.g.). The badInput flag is set when the user has entered something that can't be turned into a value and thus can't satisfy the constraint that valueMissing is checking.


> Which means the 'valueMissing' is completely ignored in a sense, due to
> checking for other flags. Why should this be required by the developers.

Why should what be required? Doing nothing? I'm confused.


> I express this as a lack of trust in the object, because when I am returned
> a flag of 'valueMissing' I directly want to go ahead and inform the user
> this field is required and you provided a blank value, instead I have to
> perform asinine logic to confirm the truth of this flag, regardless of how
> trivial it may be.

Just don't check valueMissing first. Check it second, after badInput. This isn't "asinine logic", it's the same as how you wouldn't particularly need to check patternMismatch if you got a typeMismatch, or stepMismatch if you got an underflow.


> Please understand, our point of view is taking care of the needs of whom the
> web focuses on, the end Users, and their experience within a web application.

Yes, that is my point of view also.

I completely understand the cost of development, etc. This bug report is the point out a defect/improvement to the current specification.

4.10.18.1 A form control's value, still doesn't allude to the internal value of the form input control. I understand that it may not need to, but all over the document it keeps referring to the users input.
Throughout the entire document, often references of value are followed by attribute, which would mean the HTML element attribute, i.e. [<input type=number value=1 />]
4.10.5.1.13 Number state (type=number), directly states [Constraint validation: While the user interface describes input that the user agent cannot convert to a valid floating-point number, the control is suffering from bad input.].
And says nothing about the valid usage of setting valueMissing.

Reference to Safari was not an indication that they provide validation messages on the UI, but rather they avoid this entire defect completely by enforcing what the specification states, [User agents must not allow the user to set the value to a non-empty string that is not a valid floating-point number].
Which I will need to raise that in my original defect with Chrome, as this would completely avoid this entire problem, but not solve lacking details/logic within the specification.

As stated, the flags are "mostly orthogonal", the keep point is mostly. It simply doesn't make sense that some flags exist at the same time. Such as the case with badInput and valueMissing.
As asked from the parties requesting correction, what value does this provide to keep both? While raising this bug we are pointed to just simply ignore valueMissing if badInput exist, why should I be required to do so?
That is clearly a defect, if I am to ignore something because it provided me zero value and zero truth.

In all honestly a convenience accessor is just a workaround to avoid the flaw in the ValidityState, if that's all I can get that's okay, but I don't want that, I want a true valid and trustworthy object.

> "valueMissing can only occur with the custom flag and the badInput flag. The custom flag might be set for reasons unrelated to the value itself (it might be based on other values, e.g.)."

I'm not really following this statement, valueMissing isn't a custom flag, it directly ties with the HTTML required attribute and can be set on all form input controls (that I can think of), while badInput doesn't fit to be a candidate for all form inputs (maybe it can I have not thought of that use case).

> > I completely see zero benefit in the specification allowing 'valueMissing' to exist with other flags, and the other flags provide direct validation results about the value provided by the end user, and those values are used to present a message to the user.
> > Which means the 'valueMissing' is completely ignored in a sense, due to checking for other flags. Why should this be required by the developers.

> Why should what be required? Doing nothing? I'm confused.

It has been directly stated here, to check for badInput followed by valueMissing. My question is why should that be forced, valueMissing simply should not exist when the only valid flag in that scenario is badInput.

Such logic is truly asinine, comparing checking badInput before valueMissing to other flags isn't the right way to approach this. There are several flags that make sense to be returned together, at that point its the developers role to determine which flag hold priority on which message should be returned to the user to take action on.
But badInput and valueMissing doesn't fit this model. The flag valueMissing is essentially a null/undefined/blank indicator. 

Best coding practices always have NULL/undefined checks come first. This is to no only to avoid exceptions within the code, but to also assist in performance of said code. Processing conditions takes resources, ordering those checks plays an important role, every millisecond you can save in execution time adds up.
For example, lets say I have a section of code that allows the user the provide input of some kind.
This provided value can be either a String, a Number, or Blank (to keep it simple).
It wouldn't be wise to check if they provided a number, then a string, then a NULL value.
Checking for the NULL value first prevents unneeded usage of resources. If the value is NULL you skipped two value checks.
Now to put that logic into perspective, consider that same piece of code deployed to thousands of users at the same time.
The execution time adds up, and the saved resources by checking for NULL first place helped a lot.

Checking badInput before valueMissing is simply a workaround for a flawed design, I will keep my current work around that is, [isRequiredError = (valueMissing && !badInput)], but that shouldn't even bee needed.

Once again, I understand the cost involvement, but why just offer work around's for what is clearly a flawed designed.
Work around's should only be needed for the interim, while waiting for a fix to be released. Things take time, this I understand.
Ignoring a defect/improvement is something I don't understand. The community is here to help suggest improved or find defects that need to be fixed, and thats what Im trying to do.

If there is a valid use case I am not seeing for badInput and valueMissing to both exist at the same time, please let me know.
I can't find or think of any such case. If the only value that valueMissing provides is some sort of internal check for the User Agent to use, the ValidityState object is not the place for this.
Javascript developers also have scope to this object, internal logic of such shouldn't be exposed to the such developers.

> 4.10.18.1 A form control's value, still doesn't allude to the internal value
> of the form input control.

All that section did was introduce some terms without saying what they meant. I've just now added some text to that section to try to make it clearer that these terms do not refer to the user-visible value, but to the internal value.


> I understand that it may not need to, but all
> over the document it keeps referring to the users input.

The intent of the spec is to refer very rarely to the user's input in normative prose.


> Throughout the entire document, often references of value are followed by
> attribute, which would mean the HTML element attribute, i.e. [<input
> type=number value=1 />]

Right, that isn't the input of the user either.


> 4.10.5.1.13 Number state (type=number), directly states [Constraint
> validation: While the user interface describes input that the user agent
> cannot convert to a valid floating-point number, the control is suffering
> from bad input.].
> And says nothing about the valid usage of setting valueMissing.

valueMissing is just defined here:

   http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#suffering-from-being-missing


> Reference to Safari was not an indication that they provide validation
> messages on the UI, but rather they avoid this entire defect completely by
> enforcing what the specification states, [User agents must not allow the
> user to set the value to a non-empty string that is not a valid
> floating-point number].
> Which I will need to raise that in my original defect with Chrome, as this
> would completely avoid this entire problem, but not solve lacking
> details/logic within the specification.

Chrome also doesn't let the user set the element's value to a non-floating-point number.

You can test this:

   <!DOCTYPE html><form>
   <input oninput="test.value = value" type=number>
   [<output name=test></output>]
   </form>

Try it here:

   http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3093

As you enter values, you'll see only numbers change the value. If you enter text, the value goes to the empty string.


> It simply doesn't make sense that some flags exist at the same time.
> Such as the case with badInput and valueMissing.

I don't see why. The value is missing (it's the empty string). And at the same time, the user has entered something invalid (which is why the value is the empty string — it can't be what the user entered).


> As asked from the parties requesting correction, what value does this
> provide to keep both?

None, particularly. It's just the result of the way things are defined. You can just ignore valueMissing if badInput is set.


> While raising this bug we are pointed to just simply
> ignore valueMissing if badInput exist, why should I be required to do so?

You're not _required_ to do so, but your users will have a better experience if you do.


> That is clearly a defect, if I am to ignore something because it provided me
> zero value and zero truth.

It's not zero truth. It is true that the value is the empty string, and if the control is marked as required, the empty string is insufficient — the value is missing.


> > "valueMissing can only occur with the custom flag and the badInput
> > flag. The custom flag might be set for reasons unrelated to the
> > value itself (it might be based on other values, e.g.)."
> 
> I'm not really following this statement, valueMissing isn't a custom flag,
> it directly ties with the HTTML required attribute and can be set on all
> form input controls (that I can think of), while badInput doesn't fit to be
> a candidate for all form inputs (maybe it can I have not thought of that use
> case).

I'm saying that if valueMissing is true, then one of the following is true:

   i.validity.valueMissing && i.validity.badInput && i.validity.customError
   i.validity.valueMissing && i.validity.badInput && !i.validity.customError
   i.validity.valueMissing && !i.validity.badInput && i.validity.customError
   i.validity.valueMissing && !i.validity.badInput && !i.validity.customError

...and all the other validity flags will be false.


> It has been directly stated here, to check for badInput followed by
> valueMissing. My question is why should that be forced, valueMissing simply
> should not exist when the only valid flag in that scenario is badInput.

It's not forced. You could check valueMissing first, and then if it's true, check to see if badInput is true or not to decide how to report it. I'm just saying that doing so is pointless.

Whatever you do you have to pick an order to check things in, right? So I'm just saying that the optimal order to check things in has badInput first, and valueMissing after. I really don't see why that's so bad.

It's actually no different than the other flags. There's no point checking patternMismatch if typeMismatch is true, for example.


> But badInput and valueMissing doesn't fit this model. The flag valueMissing
> is essentially a null/undefined/blank indicator. 

Not really. It's just checking whether or not there's a value in the case of the "required" attribute being set. If you don't set required="", valueMissing will never be set.


> Best coding practices always have NULL/undefined checks come first.

Not necessarily. Depends what you're doing. For example, before checking if the first field in a file is null or not, you might want to check if the file exists.


> For example, lets say I have a section of code that allows the user the
> provide input of some kind.
> This provided value can be either a String, a Number, or Blank (to keep it
> simple).
> It wouldn't be wise to check if they provided a number, then a string, then
> a NULL value.
> Checking for the NULL value first prevents unneeded usage of resources. If
> the value is NULL you skipped two value checks.

Right. That's why I'm telling you that it's best to check badInput first. The badInput flag tells you if the value is worth looking at at all. If badInput is true, then the value is not worth looking at. You can think of this as an "even more null than null" value. Then, if you know the value isn't more-null-than-null, then you can check valueMissing to see if it's just a regular missing value or not. And finally, if it's neither bad nor missing, you can check other things it might be.

Note again, though, that valueMissing is not actually the equivalent of a null check. In particular, if a field is not required="", checking valueMissing will not tell you if the field is empty or not. If you care about whether it's null or not, you should check if input.value == '', not if input.validity == valueMissing.


> Checking badInput before valueMissing is simply a workaround for a flawed
> design, I will keep my current work around that is, [isRequiredError =
> (valueMissing && !badInput)], but that shouldn't even be needed.

It's not needed. Just check badInput before you check for isRequiredError.


> Once again, I understand the cost involvement, but why just offer work
> around's for what is clearly a flawed designed.

It's not clear to me why this is flawed. These attributes tell you different things.

Checked in as WHATWG revision r8703.
Check-in comment: Try to clarify that a control's 'value' isn't what the user has entered, necessarily.
http://html5.org/tools/web-apps-tracker?from=8702&to=8703