[webkit-dev] Text control rules in themeWin.css

[Ojan Vafai]

>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090708/40e170ab/attachment.html>