Ambiguous wording in form submission leads to interop issue

[lukewarlow]

What is the issue with the HTML Standard?

See step 11.5 of https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#concept-form-submit
this as specced means that a submit button in a dialog form will always override the dialog's returnValue because a button always "has a value" (it's an empty string when missing the value attribute).

However, Chromium and WebKit implement this step as "has a value attribute" which is not the same thing.

I believe Chromium and WebKit implement this as would be expected and the spec should be updated to clarify (with tests added for this case).

Test Case: https://jsfiddle.net/wfhgc9yd/

[annevk]

Did you also test with a value attribute whose value is the empty string? Because that would be needed to figure out what the exact semantic is here.

[lukewarlow]

Yes I did in that case all browsers agree, the returnValue is overriden (which makes sense because close the dialog overrides when it's not null.

see: https://jsfiddle.net/smqbcL5f/

[annevk]

@smaug---- @emilio how do you feel about aligning with Chromium & WebKit here?

Perhaps we should not define this in terms of concept-ce-value at all then, but rather some value attribute getter.

[smaug----]

What would the change be in case one is using <input type=image> as the submitter without value attribute?

[smaug----]

Ah, 11.4 talks about that already.
Only 11.5 would change to check if the attribute is there. Sounds ok, I think. Hopefully not causing inconsistencies elsewhere where the value is checked, not the existence of attribute.

[annevk]

It's a little inconsistent in that for ordinary form submission the button element would have its value included regardless if it's the submitter.

Maybe we should separately define "command value" and use that where appropriate?

[lukewarlow]

The minimal change would be using the same language as in #11045 I guess we've got to decide if we want to do that or a larger change, the issue with defining a command value and using it in this spot is that submitter can be an input and inputs can't be command invokers, so it might be confusing.

[annevk]

That's a good point, but having a content attribute check precede an abstract value concept check in a couple of places that will be hard to correlate is rather ungainly.

Here's an improved idea: we define concept-fe-optional-value that returns the value attribute or null in its absence. Potentially we also assert the state of the type attribute so it doesn't get used too widely.