docs(HTMLButtonElement): clarify setCustomValidity and reportValidity only affect submit buttons#44322
docs(HTMLButtonElement): clarify setCustomValidity and reportValidity only affect submit buttons#44322xonaib wants to merge 2 commits into
Conversation
|
Preview URLs (2 pages)
Flaws (1) Note! 1 document with no flaws that don't need to be listed. 🎉 Found an unexpected or unresolvable flaw? Please report it here. URL:
External URLs (2)URL:
URL:
|
pepelsbey
left a comment
There was a problem hiding this comment.
Hey! Thank you for the PR. It makes it clearer, but I would suggest a few improvements:
-
Align with the pattern used on sibling pages
The issue itself points to
HTMLFieldSetElement.reportValidity()as a model, andHTMLButtonElement.checkValidity()handles the same situation the same way: both pages bake the "always returns true / no effect" behavior directly into the opening description rather than using a[!NOTE]callout. -
Stick to the formatting used in the surrounding text: don’t split lines mid-sentences.
Fixes #42234
setCustomValidity()andreportValidity()onHTMLButtonElementonly have practical effect fortype="submit"buttons. Buttons withtype="reset"ortype="button"are barred from constraint validation per the HTML spec: their validity state can be set internally but the UI never reflects it, andreportValidity()always returnstrue.Changes:
[!NOTE]to thesetCustomValidity()page explaining the submit-only constraint.[!NOTE]to thereportValidity()page explaining it always returnstruefor non-submit buttons.setCustomValidity()note also links towillValidate.Validation:
http://localhost:5042/en-US/docs/Web/API/HTMLButtonElement/setCustomValidityandhttp://localhost:5042/en-US/docs/Web/API/HTMLButtonElement/reportValidity; both pages loaded and rendered the new note content.