The summary is as follows:
Readonly only works for input(text/password) and textarea, while disabled is valid for all form elements, including select, radio, checkbox, button, etc. However, after the form element is disabled, when we submit the form in POST or GET, the value of this element will not be passed out, and readonly will pass the value out (this case occurs when we set the textarea element in a form to disabled or readonly, but submit button can be used).
Generally, the most commonly used situations are:
① A unique identification code is prefilled for the user in a form, and the user does not allow changes, but the value needs to be passed when submitting. At this time, its attributes should be set to readonly
② It is often encountered when the user officially submits the form and needs to wait for the administrator's information to verify. This does not allow the user to change the data in the form again, but can only view it. Since the range of disabled elements is large, disabled should be used at this time, but at the same time, it should be noted that the submit button should also be disabled. Otherwise, as long as the user presses this button, if no integrity detection is performed in the database operation page, the value in the database will be cleared. If you use readonly instead of disabled in this case, if there are only input (text/password) and textarea elements in the form, it is still possible. If there are other sending elements, such as select, the user can press the Enter key to submit after rewriting the value (Enter is the default submit trigger key)
③We often use javascript to disable the submit button after the user presses the submit button. This can prevent the user from repeatedly clicking the submit button in environments with poor network conditions, causing data to be redundantly stored in the database.