Skip to content
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

Merged
merged 17 commits into from
Nov 1, 2024
Merged

HTML autocorrect attribute #35692

merged 17 commits into from
Nov 1, 2024

Conversation

hamishwillee
Copy link
Collaborator

@hamishwillee hamishwillee commented Sep 2, 2024

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

  • Go back and fix up BCD. I think I got it wrong for the property of the HTMLElement.

@github-actions github-actions bot added Content:HTML Hypertext Markup Language docs size/m [PR only] 51-500 LoC changed labels Sep 2, 2024
Copy link
Contributor

github-actions bot commented Sep 2, 2024

@hamishwillee
Copy link
Collaborator Author

A little bit of safari 18 debug:

  • Password, email, url all return true or false for the value of the autocorrect - not match spec on or off.

  • Password does not autocorrect, but email and url do (try autocorrectt )

  • passwordElement.autocorrect=false; works, but "on" and "off" do not.

  • <input id="userPassword" type="text" autocorrect="off" /> - this turns it off - everything else is on. But the API returns true/false values. i.e. on and off are the values to set in the attribute value.

  • Form elements get autocorrect enabled by default - you can read it. Always on unless explicitly set to off in HTML or false via API.

    • nested elements obey this as per spec (modulo using true/false not on/off)
  • Div elements get autocorrect and it is on by default, but it is not inherited.

  • contenteditable is same

@github-actions github-actions bot added Content:WebAPI Web API docs size/l [PR only] 501-1000 LoC changed and removed size/m [PR only] 51-500 LoC changed labels Oct 22, 2024
@github-actions github-actions bot added size/m [PR only] 51-500 LoC changed and removed size/l [PR only] 501-1000 LoC changed labels Oct 22, 2024
@hamishwillee hamishwillee marked this pull request as ready for review October 22, 2024 07:02
@hamishwillee hamishwillee requested review from a team as code owners October 22, 2024 07:02
@hamishwillee hamishwillee requested review from sideshowbarker and estelle and removed request for a team October 22, 2024 07:02
@hamishwillee
Copy link
Collaborator Author

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.

@sideshowbarker sideshowbarker removed their request for review October 22, 2024 07:39
files/en-us/web/api/htmlelement/autocorrect/index.md Outdated Show resolved Hide resolved
files/en-us/web/api/htmlelement/autocorrect/index.md Outdated Show resolved Hide resolved
files/en-us/web/api/htmlelement/autocorrect/index.md Outdated Show resolved Hide resolved
- {{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.
Copy link
Member

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?

Copy link
Collaborator Author

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.

files/en-us/web/html/element/textarea/index.md Outdated Show resolved Hide resolved
files/en-us/web/api/htmlelement/autocorrect/index.md Outdated Show resolved Hide resolved
files/en-us/web/html/element/input/password/index.md Outdated Show resolved Hide resolved
Copy link
Member

@estelle estelle left a 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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
`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 🤷

Copy link
Collaborator Author

@hamishwillee hamishwillee Nov 1, 2024

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:
image

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- : 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).

Copy link
Collaborator Author

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)

Copy link
Member

@estelle estelle left a 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!

@estelle estelle merged commit 709d3a5 into mdn:main Nov 1, 2024
8 checks passed
@hamishwillee hamishwillee deleted the element_autocorrect branch November 1, 2024 22:39
@hamishwillee
Copy link
Collaborator Author

Yes, so very confusing! Thanks for the review.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Content:HTML Hypertext Markup Language docs Content:WebAPI Web API docs size/m [PR only] 51-500 LoC changed
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants