-
Notifications
You must be signed in to change notification settings - Fork 22.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HTML autocorrect attribute #35692
HTML autocorrect attribute #35692
Conversation
Preview URLs (12 pages)
Flaws (1)Note! 11 documents with no flaws that don't need to be listed. 🎉 URL:
(comment last updated: 2024-11-01 00:48:50) |
A little bit of safari 18 debug:
|
Co-authored-by: Estelle Weyl <[email protected]>
2735f40
to
0308881
Compare
FYI reviewers, I just finished this draft end of day and so have not self-subedited. If you don't wish to review until Friday that would be more than fine. |
- {{htmlelement("textarea")}} elements and {{domxref("HTMLTextAreaElement")}} objects. | ||
- Any element that has the [`contenteditable`](/en-US/docs/Web/HTML/Global_attributes/contenteditable) attribute set. | ||
|
||
Editable text elements (other than the exceptions listed above) have auto-correction enabled by default, except for within a {{htmlelement("form")}} element, where the default value may be inherited from the form. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how about fieldsets? if set to false on the fieldset, is it inherited from that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good question. I don't think so.
As I read the spec the fieldset can inherit from the form, but a nested input within that fieldset would also inherit from the form. So even though the fieldset inherits from the form, this has no real impact on anything.
Co-authored-by: Estelle Weyl <[email protected]>
Co-authored-by: Estelle Weyl <[email protected]>
Co-authored-by: Estelle Weyl <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
two issues and a suggested very basic example for the HTML attribute page (remove the "end" after the three tic marks if committing my suggestion)
|
||
## Value | ||
|
||
`true` if auto-correction is enabled for the element, and `false` otherwise. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
`true` if auto-correction is enabled for the element, and `false` otherwise. | |
`on` if auto-correction is enabled for the element, and `off` otherwise. | |
>[!NOTE] | |
> The Safari implementation returns a Boolean; `true` if auto-correction is enabled for the element, and `false` otherwise. |
Or something like that: the spec says on/off, but safair does true/false, so 🤷
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@estelle I am pretty sure that what I have here is correct. The spec says the HTML element (shown here) is a boolean that sets/gets true
/false
. The tag attribute takes a string on
/off
in spec.
See https://html.spec.whatwg.org/multipage/dom.html#htmlelement:
Also the description
The autocorrect getter steps are: return true if the element's used autocorrection state is on and false if the element's used autocorrection state is off.
The setter sets the attribute to "on"/"off", which I take this to mean that if you output the doc as HTML you'd see the attribute as the string form.
So Safari correctly returns true/false for the HTMLElement.autocorrect, but incorrectly uses the string 'true"
, "false" instead of "on"/"off".
- : A string that represents the element's capitalization behavior for user input. Valid values are: `none`, `off`, `on`, `characters`, `words`, `sentences`. | ||
- {{domxref("HTMLElement.autofocus")}} | ||
- : A boolean value reflecting the [`autofocus`](/en-US/docs/Web/HTML/Element/select#autofocus) HTML global attribute, which indicates whether the control should be focused when the page loads, or when dialog or popover become shown if specified in an element inside {{htmlelement("dialog")}} elements or elements whose popover attribute is set. | ||
- {{domxref("HTMLElement.autocorrect")}} | ||
- : A boolean that represents whether or not text input by a user should be automatically corrected. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- : A boolean that represents whether or not text input by a user should be automatically corrected. | |
- : A string that represents whether or not text input by a user should be automatically corrected. |
only implementation is safari, which incorrectly has values of true/false (instead of on/off).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think so, as per #35692 (comment)
Co-authored-by: Estelle Weyl <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @hamishwillee, and thanks for clearifying the on/off / true/false. That was confusing!
Yes, so very confusing! Thanks for the review. |
The global
autocorrect
attribute is now part of the standard. This documents it.Note, in draft because I haven't been able to "see" and autocorrection behaviour in testing. Creating this PR allows me to create something that "may" allow that.
Related docs work in #35593