Reversed behaviour for the novalidate attribute in the form

[okoram]

BC Break Report

Q	A
Version	3.20.0

Summary

There is a problem with the operation of the novalidate attribute after a change:
#273

According to the documentation: https://html.spec.whatwg.org/#attr-fs-novalidate

The novalidate and formnovalidate content attributes are boolean attributes. If present, they indicate that the form is not to be validated during submission.

Therefore, it does not matter what value is assigned to the novalidate attribute. As long as this attribute is present, it is treated as TRUE - the form is not to be validated.

This change has therefore reversed the condition's behavior in all cases except one:
Element::setAttribute('novalidate', true)

In my opinion, this change should be marked as "Breaking Changes".

Previous behavior

novalidate
novalidate=""
novalidate="novalidate"
novalidate="anything"
etc. are always TRUE.

Element::setAttribute('novalidate', 'anything')
rendered as novalidate="anything", which meant TRUE

Current behavior

Element::setAttribute('novalidate', 'anything')
renders nothing, which means FALSE

[okoram]

I have re-checked all these variants and the problem only occurs in one case:
Element::setAttribute('novalidate', '')

Previous behavior

Element::setAttribute('novalidate', '')
rendered as novalidate="", which meant TRUE

Current behavior

Element::setAttribute('novalidate', '')
renders nothing, which means FALSE

[froschdesign]

In my opinion, this change should be marked as "Breaking Changes".

We follow semantic versioning, so breaking changes are only allowed in a new major version.
The change was made to ensure consistent handling of the boolean attributes.
For example, if you run frontend tests or use the empty string as a value, this can lead to problems. Therefore the question if there was a concrete problem in your application?

Thanks in advance! 👍