Safari on macOS uses native controls. The reply button I'm about to click to submit this comment is 100% native, because Hacker News is using nothing fancy beyond <input type="submit" value="reply">. (Interestingly, Safari will outright ignore font sizes it cannot draw a native control for…)
To understand this better, here's a good place to start in the Webkit source code: https://github.com/WebKit/webkit/blob/master/Source/WebCore/...
That is the interface Webkit uses to draw "native theme" buttons and other controls on Mac. It is not using a real Cocoa NSButton for each button in the Web page. Instead, it creates its own internal DOM and CSS rendering objects (HTMLButtonElement, RenderButton respectively) which are cross-platform code. Every time it needs to draw a button, it calls virtual methods on RenderTheme. On Mac, the RenderThemeMac implementation calls down into Cocoa code to draw the background and borders of the button. (But not text; that wouldn't work in general, because in HTML a <button> can contain arbitrary HTML elements, and native buttons can't handle that.) That's pretty much the only involvement of Cocoa native button code. Firefox works in a very similar way; here's the Firefox version of RenderThemeMac: https://github.com/mozilla/gecko-dev/blob/master/widget/coco...
I am only familiar with WebKit, but glancing at the Firefox code, it looks quite similar. I'm actually not sure what you're claiming? Both implementations rely on NSButtonCell to perform button rendering when possible, and fall back on drawing it by hand if you mess with it too much (for example, if you set background-color: green on it). Then it hooks up internal DOM objects so they can be manipulated using web APIs.
> Browsers can't use the OS control implementations, because the demands of DOM/CSS simply can't be handled by those native implementations. But Firefox is trying to emulate the look and feel of the OS controls, using native theme drawing APIs when possible.
Then Wowfunhappy wrote: "I wonder if that applies even to Safari on Mac and iOS". It absolutely does, Firefox and Safari work the same way here. But you appeared to think you were contradicting us when you wrote "Some of them are native, if you don't style them."
I guess it boils down to what you mean by "Safari on macOS uses native controls." Drawing with NSButtonCell and the other theme APIs does not, in my view, warrant such a blanket statement. All of the interactive behaviour of buttons and other widgets is (re)implemented by Webkit/Gecko. Accessibility is reimplemented. Layout is reimplemented. It's only painting that uses NSButtonCell, and not all painting either (borders and background but not the text).
I would certainly never claim "Firefox on MacOS uses native controls" even though it works pretty much the same way as Safari.
I would call that quite native, because you can see what they do when they can't actually use the platform APIs. In my mind, blitting pixels onto a screen is non-native; using a NSView/NSCell or similar "generic" view and drawing into that wouldn't really cut it either, but using an actual button cell is basically as native as you get. Like, that platform API exists for exactly the thing Safari and Firefox are using it for? I'm not saying that they're rendering and interacting with the web natively–that would mean they're translating divs into NSViews and text into text components–but for controls they are using honest-to-goodness AppKit controls that they have hooked up to web APIs. What is not native is what they do when you mess with them, as I described.
The drawing code is not what people typically mean by "native". What they mean is the behavior. No browser relies on the built-in behavior of e.g. an NSButton. The source code of "native" Mac apps looks nothing like RenderThemeMac.cpp.
I guess you can use the word "native" to mean whatever you want, but I assure that (as a former Mozilla developer) if you claim "Firefox uses native controls" (because internally it calls into platform APIs for some rendering sometimes), people are going to get mad at you.
You can't tell by looking at the controls whether Safari is using the native control implementation (it isn't). All you can tell is that the Webkit implementation looks like and acts like the native implementation.