Upon inspecting the bug and commit, and doing some manual testing, I can now confirm that the attribute is supported under specific conditions, rather than not being supported at all. I've updated the PR accordingly, and set a version number based on the date of the commit linked.

I was thinking about setting partial implementation, but I wasn't certain. Then again, this behavior is technically non-conforming to the spec, and our definition of partial_implementation is if "the implementation of the sub-feature deviates from the specification in a way that may cause significant compatibility problems", so...I guess we should?

So, this will move this feature from baseline high back to limited availability. I think that's correct based on:

• https://bugs.webkit.org/show_bug.cgi?id=195884#c4

• https://medium.com/@brunn/autofocus-in-ios-safari-458215514a5f

I think this is more serious than the PR suggests, even, and it's OK for it to un-Baseline the autofocus feature. It looks like there are two compat issues to report here in BCD:

• autofocus: If there's no hardware keyboard connected, then the autofocus attribute has no effect (for example, the focus event doesn't fire and the element does not match the :focus selector).

  I think it'd be nice if the note mentioned an example of what "no effect" means. I don't think the on-screen keyboard not appearing is worthy of mention, since this doesn't seem to happen in Chrome or Firefox for Android, either (nor do I think we should endorse some web developers' expectation to have casual control over users' input devices, even virtualized ones).

• focus(): If there's no hardware keyboard connected and the user has not yet interacted with the page, then calling focus() on an <input> element has no effect (for example, the element does not match the :focus selector).

  I'm not sure if this matters enough for a partial on focus(), but it's definitely noteworthy and deeply weird.