On Jul 6, 2009, at 11:47 AM, Dan Bernstein wrote:

I was looking at themeWin.css and noticed a few rules relating to text controls. Can anyone shed a light on their purpose and why they are in themeWin.css rather than in html4.css or in a port-specific theme?

HISTORY

This got checked in when unforking Chrome. At the time, the stated goal was to have the theming be OS-specific and not port-specific. That's why, for example, there's no themeChromiumWin.css. It seemed like Safari was OK with matching Firefox/IE metrics on Windows. Now that I look back at the bug, I think this might have gotten checked in with a poor ChangeLog description and maybe didn't get as thorough of a review as a result. As to the specific rules in there, Chrome tried to match IE or Firefox for form controls. This all happened before the Safari Windows launch, so we didn't have the option of just matching Safari. Our primary goals were to have form controls look polished, maximize web compatibility and assist web developers by minimizing differences from other browsers. With respect to polish, there were mainly cases where form controls would look poor on Windows because the default styling was for aqua controls (e.g. rounded corners). FUTURE We've had a strong aversion to creating even minor rendering incompatibilities between Safari and Chromium. We'd like, as much as possible, to give web developers confidence that they can write code for WebKit and have it "just work" in both browsers. All the theming differences should ideally come from what OS you're on, not whether you're using Safari or Chrome. Does that seem like a worthwhile and achievable goal in general? Is this something we should encourage WebKit ports to do? Assuming we agree that's a good goal, what are the criteria by which we decide how Windows (or Mac for that matter) controls should be themed? The two I care about is that they 1) look good and 2) maximize web compatibility. From my perspective, part of 2 is to only diverge from other browsers as necessary to achieve 1. Since the current state of the world is at least partially my fault, I'm happy to follow through with patches for whatever the conclusions of this discussion are. SOME EXCEPTIONS

textarea:disabled, input:not([type]):disabled, input[type="text"]:disabled, input[type="password"]:disabled, input[type="search"]:disabled { background-color: #EBEBE4; }

This rule is an exception to the polish/compatibility argument since it's more about usability. We got a lot of bugs filed about being unable to edit text inputs. It turned out that the text inputs were disabled, but the disabled/enabled styling in WebKit is so subtle that people didn't notice. This styling matches Firefox Windows. Not sure if this was the correct decision, but probably warrants it's own discussion since a) the reasoning for this change is totally different and b) may justify a change of some kind to all ports.

The decision to use monospace for textareas was also a result of a bunch of people filing bugs. I don't think we've ever had a bug where someone asked for serif'ed fonts on textareas. :) This also somewhat has a compatibility benefit in that textareas that use cols for sizing will size closer to IE/Firefox metrics. Ojan