Some attributes not allowed for the new HTML5 input elements

First try.

Good catch, thank you.

Changed the doxygen to say the 'required' attribute is not allowed. It's not really that #required is not supported by Drupal, but that adding the 'required' attribute would make invalid HTML.

The doc says the default value should be minimum plus half the difference between the minimum and the maximum. That is the same thing as (#min + #max) / 2. We also must round the value to match #step.

+++ b/core/includes/form.incundefined
@@ -4032,6 +4032,26 @@ function form_validate_number(&$element, &$form_state) {
+ * Make sure range elements always have a value. Default to 0. The 'required'

Accidantely left "Default to 0." in.

Alright, here are tests. (And they helped me catch at least one more mistake, so far.)

Other than that, what is the expected behavior for a range field left empty with a min of 2, max of 8 and a step of 2?

I added excatly that scenario to the tests as well. Let's see: The mean of #min and #max is 5. That is 1.5 step from 2. Round the number of steps to 2. 2+ 2 * 2 = 6. The intresting part is of course the decision between 1 step or 2 steps, so I double checked webkit does the same thing.

unless the maximum is less than the minimum, in which case the default value is the minimum.

Good point, attiks. I'd say we should ignore this state, since it won't pass #min and #max validation anyway. Browsers skip that validation then, but I believe we shouldn't ignore #min and #max in that case. Otherwise it might be hard to spot such a mistake.

Alright. So what happens with:
<input type="range" min="10" max="5" />
Apparently no value can meet both min and max. That's why min > max is invalid. No client side validation will happen in that case, as if min and max weren't provided at all.

Now: What happens on the server side?
I think we should not skip validation, instead simply fail for all values. Silently skipping validation might lead to problems that are hard to find.

If we do agree on that, it doesn't matter what default value we choose when min > max, since no value can pass validation anyway.

No, I believe this is wrong.

Both chrome and Opera try to validate

Actually try this:

<form>
  <input type="range" min="10" max="1" name="foo" />
  <input type="submit" />
</form>

Chrome will show a slider from 0 to 100 and will let you submit any integer between those limits, which is the behaviour as if min or max weren't given.

but tho only thing that can pass is an empty field.

Range elements can't be empty, which makes sense, because in what state would a slider be, to be empty?
That means no value at all could pass validation (if it happened). And because it should happen at least on the server side, no value can pass. Not even the default value. So there is no point in calculating that value.

Thank you for the added test, though. It shows a different problem:

• Send the form with an empty value.
• The default value gets calculated. Even 10, if you wish.
• The validation should now fail, but it is skipped, because $element['#value'] is still '' in form_number_validate().

Exactly, for that and against malicious forgery :)

Alright ... let's get this issue cleaned up. Since we're not in a hurry, I go back from RTBC.

I should have highlighted #17:
[...] Thank you for the added test, though. It shows a different problem: [...]

I added a test (based on attiks test - and thank you again) that shows that we also have to update $element['#value'] for the following validation.

1540174-html5-attributes-26.patch should fix everything.

With that fix invalid ranges won't get past validations. That probably means we can also close #1542258: Decide what to do when min > max for HTML5 number/range element. Like: "What value will get passed?" "I don't know, it doesn't even get to the submit handler." But we can discuss that there.

Edit: Yay! Test results as expected. Exactly one fail for #17, 4 fails for the patch without tests and the combined patch is green.

Awesome, perfect fit, thanks!

Didn't even know such a thing existed.

Fix typo.

Another good catch. Thanks. form_type_checkbox_value() that I used as a template seems to confuse $form and $element, too. (There's a clean-up issue already.)