html.global_attributes.autocorrect - Safari claims are incorrect

[annevk]

What type of issue is this?

Incorrect support data (example: BrowserX says "86" but support was added in "40")

What information was incorrect, unhelpful, or incomplete?

It claims Safari does not support on/off, but it does.

What browsers does this problem apply to, if applicable?

Safari

What did you expect to see?

That Safari supports this attribute.

Did you test this? If so, how?

It's pretty clear from the source code that Safari does this correct:

Source/WebCore/html/HTMLElement.cpp:    auto& autocorrectValue = attributeWithoutSynchronization(HTMLNames::autocorrectAttr);
Source/WebCore/html/HTMLElement.cpp:    return !equalLettersIgnoringASCIICase(autocorrectValue, "off"_s);
Source/WebCore/html/HTMLElement.cpp:void HTMLElement::setAutocorrect(bool autocorrect)
Source/WebCore/html/HTMLElement.cpp:    setAttributeWithoutSynchronization(autocorrectAttr, autocorrect ? onAtom() : offAtom());
Source/WebCore/html/HTMLElement.h:    bool autocorrect() const { return shouldAutocorrect(); }

And also, Safari contributed this to the standard. I wonder how this was tested to begin with.

Can you link to any release notes, bugs, pull requests, or MDN pages related to this?

No response

Do you have anything more you want to share?

No response

MDN URL

https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/autocorrect

MDN metadata

MDN page report details

• Query: html.global_attributes.autocorrect
• Report started: 2024-11-06T14:18:49.053Z

[annevk]

@hamishwillee it seems you did this in #24249, but note that the getter/setter do operate on a boolean and Safari thus does that correctly. It's the content attribute that supports strings.

[caugner]

Looks like this was only partially fixed by #24834.

[GIgako19929]

Reject