[Webkit-unassigned] [Bug 22261] Clicking on a non-text input element does not give it focus

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue May 25 10:13:37 PDT 2021


https://bugs.webkit.org/show_bug.cgi?id=22261

--- Comment #73 from Darin Adler <darin at apple.com> ---
(In reply to Dave from comment #71)
> web developers require browser consistency in order to deliver applications and features to those users

I think this is the crux of the matter.

People are strongly encouraging Safari to adopt Windows-style focus on buttons, check boxes, etc., even though this is not natural for most macOS users, because the other browsers, all of which have more users on Windows than Mac, have chosen to make the browser world a world of Windows-style within a window, even on Mac.

Perhaps in the end the Safari will be *forced* to do this, because we simply can’t resist the tide of all those website developers who are relying on this aspect of how Windows works, perhaps without even being aware of that, within webpages. The webpages that are theoretically and aspirationally platform-independent, but in the end strongly depend on this specific behavior from Windows.

I do see these impassioned arguments, and I really don’t think the Safari team resistance comes from arrogance: We’re looking out for the many Mac users that find the web browser easier to use when it matches the rest of software on the Mac.

Some of these arguments start with the bizarre claim that Apple and Mac are intrinsically "elitist". I really don’t know what to do with that claim; I have no intention of debating it.

But I do understand the claim that the Safari team must prioritize the ease of making a website work across browsers by people who will never test that website in Safari, and the strong request that we accept the Windows model on Mac to make that easier. And the related claim that some, or even many, Mac users don’t even care about the inconsistency between the browser and the rest of the Mac software, and those people are happy to accept that in Mac Chrome, for example.

On Mac, *nothing* except a text field focuses just because you click on it, unless you turn on accessibility options that allow you to use the keyboard to cycle through everything. Pushing a button does not focus the button. Clicking a check box does not focus the check box. On Windows, keyboard focus is a concept that’s on by default, and all of those things *do* happen. This difference has been around as long as Windows has; it’s one of a few key things that Microsoft changed when implementing concepts that were first on Mac.

And these accessibility options that change the focus rules need to affect focus even in web browsers. Thus, it is possible, perhaps even likely, websites that depend sensitively on exactly what is focused are effectively choosing to work only for certain people based on their accessibility options!

I suppose it may be too late to change the approach of the web platform. I’m a little sad that it seems "you must match Windows; please drop things that are different about the Mac because it is too difficult to accommodate them and keep websites compatible" is the strongly encouraged approach to cross-browser compatibility.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210525/d1f58139/attachment-0001.htm>


More information about the webkit-unassigned mailing list