[saagarjha]

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.

[roca]

I think I was pretty clear up above:

> 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.

[saagarjha]

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.

[pcwalton]

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.

[saagarjha]

On macOS the situation is interesting because there is a sort of an “in-between” later that doesn’t really seem to exist on other platforms, which is cells. Usually you either have a control or you have a drawing primitive and you get nothing in between, but on macOS you have a class that encapsulates the drawing portion of a control and you can hook up your own event system on top of it. Safari has it a little bit more complicated than this because it needs to handle basically every possible abuse of NSButtonCell before it falls back to something completely custom; Mac apps typically don’t style their buttons in a dozen different ways. Safari can’t actually use NSButton because such a class obviously can’t be hooked up to the DOM: it wouldn’t be worth it. But if Safari actually included a full reimplementation of NSButton, it would be significantly more complicated than what we see here. It is still relying on a lot of NSButtonCell functionality, which as you mention is just drawing but includes behaviors like highlights and sizing and animation which people who actually do try to reimplement have historically done poorly. (Actually, to be completely honest, Safari actually does break a couple of things as it tries to disable built-in behaviors. But this is coming at it from the opposite direction from usual.) I know it isn’t sending NSEvents around but it “feels native” and works with the web: it looks, acts, and even updates like a button but makes an event in the web page, which is I think the best anyone can do. (FWIW, iTunes does its own thing too, and it’s native as well. It’s just bad native.) At some point, when they’re using a significant portion of the platform’s native control and are working hard to hook it up to something which isn’t what it usually is connected to, to the point where people who generally have complaints about “non-native UIs” (hello) sit back and say “actually this is not too terrible” I think you have to give it to them.

Edit: I thought more about it and I think I was misunderstanding where this conversation was going. I do care very much about native controls being more than looking native. The thing is that in the web really the only thing exposed is how the control looks because all the platform behaviors have to be stripped out: for example, on one OS a native control with the word “OK” inside of it may be implicitly activatable via the pressing enter on the keyboard, but such an interaction is undesirable on the web because a button should have the lowest common denominator of behaviors. There really is no room for much more than the actual UI of a control to show platform conventions and so when I call things native in this context I mean that they are native as they can be used in a webpage. Plus more complex interactions, which is often where such “native” frameworks go wrong, are just not a thing on the web so I am using ignoring them while you are not.

[roca]

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.

[saagarjha]

Yup, I know both you a Patrick work(ed) on this stuff, hence why I will from this point on stop claiming things about Firefox as I have not done more than glance at the file you linked. However, as someone who is fairly familiar with WebKit and even worked on it for a short period, and as someone who happens to be a person who gets mad at others at claiming that they are designing “native” UIs: I think calling what Safari does as “native” is a better description than saying it is not. (To give you an idea of where I tend to draw the line: Flutter is not native. Qt is not native. React Native uses native controls, as does wxWidgets.) I think of you asked a random software engineer how they thought web controls were implemented they’d guess that they were drawn and implemented from scratch in the browser, and some browsers (like Chrome) actually do this. What Safari does isn’t drawing a rectangle on a screen using Quartz: it’s actually pulling the class that defines the UI of a button from Cocoa and putting it on the screen, making sure it stays consistent with the DOM. There are actual AppKit engineers working on this and they call these native controls. Safari sometimes needs to disable or patch around bugs in them. It’s basically as close as you could possibly get while still being able to use one of these in a webpage.

Edit: as I mentioned in another comment, what I’ve really been trying to say isn’t that they’re as native as the web will let them be, and that happens to allow them to use a fair bit of platform-specific code if they would like. I think the things you are trying to bring up are just a consequence of the web not being a native platform.