903200 - invalid state on form reset causes default border style to be applied to invalid form inputs

Status: RESOLVED INVALID

(Core :: DOM: Core & HTML, defect)

Description

[christyn.wegner]

Attachment: shows the styling error on reset and a workaround

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:23.0) Gecko/20100101 Firefox/23.0 (Beta/Release)
Build ID: 20130730113002

Steps to reproduce:

1. load html 5 form requiring validation of inputs
2. attempt to submit form with invalid values
3a. (optional) enter valid data
3b. reset form


Actual results:

after reset, the browser default invalid style is applied to all form controls that are reset to the invalid state. The invalid state itself is expected.


Expected results:

Perform the steps 1, 3a, and 3b. after reset the form input controls are reset to the invalid state but the browser default invalid style does not get applied. This should also be the case when steps 1, 2, and 3b are performed.


Additional Info:

Inspecting the applied styles on the input control prior to the first case of invalid input on any individual input control reveals that the default style rule for an invalid input does not exist. Only on the first occurrence of an invalid input on an individual control does the style rule get applied to that input control. The specific style rule that gets applied is ":-moz-ui-invalid:not(output)"

However, if no invalid input is encounter then the style rule is never applied to the control; therefore, on a form reset the style rule doesn't apply to any of the form inputs that are also in an invalid state.

It may be reasonable to assume that the specification for the form reset method does not state that this default style is to be removed. Thus, the request is to determine if the specification itself (and subsequently the form reset method) has a bug regarding this behavior. The request is to determine if upon reset that the style rule ":-moz-ui-invalid:not(output)" is removed from all input controls that the reset button belongs.

Workarounds:

I have identified two workarounds to get around this behavior.

1. reload the page (doesn't seem practical, especially if there are other forms on the page)

2. override the style rule (eg. element.style.boxShadow = 'none' ) for the form's input controls when the reset event is fired and disable the style rule (eg. element.style.boxShadow = null ) for individual input controls when the invalid event is fired (this event shall also fire for each of the form's invalid input controls on form submit but before the submit event is fired).

Reason for the request:

Submitting a form via an xmlHttpRequest that may be submitted multiple times but requires a reset after each successful submission without leaving the page  shows the invalid style to the user. Even with a message that the submission was successful red border around the input controls may send a conflicting cue to the user that the submission was not successful and the data was lost.

Comment 1

[Mounir Lamouri (:mounir)]

The default style you see is :-moz-ui-invalid and it applies if the user interacted with the form control but also as soon as the user tried to submit the form once (the element has to be invalid too, obviously).

It seems that the behaviour you see is actually expected because the form control is invalid and you tried to submit the form once.

Comment 2

[christyn.wegner]

I have been searching for the specification pertaining specifically to the form reset method but have not been able to find it. The only spec I have found regarding the reset method is the developer version which states that it functions the same as a reset button.

Are you able to direct me to the specification for the algorithm to the reset method? I'd like to review and if necessary submit a change request to the specification. The HTML 5 living standard leaves specific implementation up to vendors only stating that the reset algorithm doesn't fire events like it would if a user had interacted with the control.

The case I am making is that the pseudo class applied to the form controls are applied by the browser and thus it should also be the browser responsible for removing the pseudo class from the form controls upon reset. Thus the state of the form and it's controls don't depend on the state prior to reset.

One could make the case that attributes are not reset, if they were changed by a client side script, and thus why should the pseudo class also be reset. In the former case the browser cannot make the distinction of whether a reset should reset the values and validity of the form controls or to reset the form to the point prior to manipulation by a script; this is a completely valid case, for obvious reasons.

However, the application of pseudo classes to elements is predictable by the browser. Take the :hover as an example. When hovering over and element the :hover pseudo class is applied, when the mouse exits the boundaries of the element the :hover pseudo class is removed, effectively resetting the hover state of the element. It doesn't matter if element is manipulated while the :hover pseudo class is applied, the state after a mouse exit is a state where no :hover pseudo class is applied.

The the application and removal of the :-moz-ui-invalid pseudo class is just as predictable as the :hover pseudo class or any other pseudo for that matter. By not removing the :-moz-ui-invalid pseudo class after the form has been reset seems to be inconsistent with other pseudo classes having similar behavior.

Comment 3

[Mounir Lamouri (:mounir)]

The style that applies is described here:
https://developer.mozilla.org/en-US/docs/Web/CSS/:-moz-ui-invalid?redirectlocale=en-US&redirectslug=CSS%2F%3A-moz-ui-invalid

It is not standard yet.