Move away from prototype/validation.js and towards native form validation

[loekvangool]

Description (*)

https://github.com/OpenMage/magento-lts/blob/1.9.4.x/js/prototype/validation.js is handling form validation like entry-required, validate-email. This is wildly outdated since native options exist now: https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_validation. Native validation removes all responsibility from us, except for adding the <input> attributes like type=email. We no longer need to care about translations, UI, adherence to RFCs, etc.

Since it is native, we can also eject (part of the) translations of form validation errors in every page (new Translate):

magento-lts/app/code/core/Mage/Core/Helper/Js.php

Line 140 in b6e65db

protected function _getTranslateData()

Note that security is not affected, both the current and proposed methods are client-side.

Benefits

• Don't validate forms like 2007
• Validate forms like it's 2013 instead!

[fballiano]

I'd need to check the subject a bit more in depth but I wanted to comment that the "Validate forms like it's 2013 instead!" broke me 😂😂😂😂

[kiatng]

A new theme package? And drop prototype.js while at it.

[addison74]

Just an opinion. It would be wonderful to completely remove the Prototype library from OpenMage and everything that is inherited from Magento and has become obsolete, but it is intensively used both in the Frontend and in the Backend. If this were to succeed, the big problem would be related to the extensions that use it and the custom code added by the developers. I have at least 5 extensions that use Prototype, I should migrate them to jQuery, but I don't really like to do this. If I remember correctly, there are methods in the Prototype that do not exist in jQuery.

[loekvangool]

What I would do is the following:

• Move away from prototype/validation.js by updating <input> fields one by one. Start with the most important forms.
• Keep prototype/validation.js enabled by default, but don't assume it's enabled (see Make Prototype Validator optional #3053). People can disable it if they want using local.xml, without complaints from js/*.

My opinionated opinion:

• Not all forms need to be updated to the new model. Just do the next most important one until it makes no more sense.
• Physically deleting libs, achieving 100% usage removal, are things that have no place in a maintenance project with limited resources? Very opinionated and I will not oppose it, of course, if anyone wants to. But it does not hold my interest, I need to balance my time.
• The backend is a 3rd class citizen in my opinion. I just want high Lighthouse/SEO scores and a modern UI for end users.
• The customer logged in section is 2nd class citizen for the same reason.
• The 1st class citizens are the frontpage, catalogsearch, product list view, product detail view, and the cart. As well as derived/override stuff like amshopby

[empiricompany]

I can report on my experience attempting to remove validation that relies on the Prototype library. I created a simple observer attached to the core_block_abstract_to_html_after event that adds the required attribute to all inputs with the class required-entry.

The problem is in the "Account > Change Password" section, where the new password fields are hidden and, with the required attribute, form validation occurs on submission. Additional code is required to add/remove the required attribute depending on whether the user has selected the option to change their password or not, otherwise the new password inputs will still be considered in the form validation even if they are hidden.

Another litte thing to consider for a potential new ultra-light default theme is to modify the qty inputs by adding pattern="[0-9]*" and inputmode="numeric". (I prefer not to change the input type from text to number because it add the graphical arrows.)

Removing Prototype is a bigger challenge because all classes for configuring product options, the search completation, etc. would need to be rewritten. I think that creating a new super-lightweight theme would bring a lot of value to OpenMage, but there is a lot of work to be done and it would be necessary to create a dedicated mega pull request.

Personally, I have removed many additional Prototype libraries such as Scriptaculous and have been able to achieve Lighthouse scores above 90.