[roca]

Right. 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. It is very hard to get 100% right, which is why no browser does.

[Wowfunhappy]

Huh. I wonder if that applies even to Safari on Mac and iOS, given how integrated Apple likes to be with their UI controls.

[saagarjha]

Some of them are native, if you don't style them.

[roca]

That isn't true. Browsers reimplement the native look and feel (in some cases) but they do not use the actual native control implementation.

[saagarjha]

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…)

[roca]

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

[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]

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.

[saagarjha]

I can't tell by looking at them, which is why I am speaking from experience that they are actually using native controls :)

[dstaley]

> Browsers can't use the OS control implementations, because the demands of DOM/CSS simply can't be handled by those native implementations. [...] It is very hard to get 100% right, which is why no browser does.

This is not correct. In instances where CSS doesn't affect the styling of the control, the browser can use native controls. As far as I know, every browser _except_ Firefox does this. For example, <select> elements in Chrome and Safari are native elements (albeit Win32 versions in the former on Windows).

[roca]

Chrome and Safari are absolutely not using the actual native control implementation. E.g. on Windows Chrome is not jamming a combobox HWND into its browser window.

[pcwalton]

> In instances where CSS doesn't affect the styling of the control, the browser can use native controls. As far as I know, every browser _except_ Firefox does this.

This is not true. It's not just the styling of the control itself that makes it infeasible to just stick an NSButton inside the browser's NSView; it's about the way a control interacts with everything else on the page.

Source: I work on browser graphics.