The <select> widgets in camino look a bit crappy because the box surrounding them seems like a pixel too far out. There's a white gap between that box and the scrollbar, and sometimes the box fails to refresh correctly.

See also bug 293343 about the refresh issue (possibly).

It's also 1px thick instead of being the former (IIRC) OS X-ish bevel.

This patch tweaks the #if MOZ_DEFAULT_TOOLKIT=="cocoa" part of forms.css, in the following way: textarea outlines are 1 pixel thick, and use hard-coded colors (since the theme drawing stuff draws textfield-style bevels). listbox outlines changed to use hard-coded colors, because DrawThemeListBoxFrame() seems to have issues with clipping (bug 293343) margins and padding tweaked on textareas and list boxes.

I initiall looked and made some fixes to this code, I tested this patch and I didn't come accross any strange stuff just some nice tweaks so R+ from me :D

Comment on attachment 186718 [details] [diff] [review] Tweak the cocoa part of forms.css if jasper's happy, r=pink

Comment on attachment 186718 [details] [diff] [review] Tweak the cocoa part of forms.css Camino-only, so checked in.

Checked in (with some minor tweaks).

After spending a while in Bugzilla with a build that has these changes (on 10.3.9), I have three comments: 1. This may have fixed bug 293343; at least the steps in bug 293343 comment 7 no longer cause it reliably; 2. The top and right margins (or padding in a CSS sense) of the textareas are very tight, which makes the top line hard to read IMO and textareas somewhat unattractive; 3. Inputs are still "beveled" while textareas are not, which is odd-looking when they're on the same page. "Annotated" testcase and screenshots for comparison coming up.... I don't know if these issues are even fixable, or if I'm just being picky, or whatever....

(In reply to comment #9) > 3. Inputs are still "beveled" while textareas are not, which is odd-looking > when they're on the same page. I believe this was intentional; if you look at OS X's text fields vs. text views, you'll notice that the text fields have a much deeper bevel than the text views do.

(In reply to comment #9) > After spending a while in Bugzilla with a build that has these > changes (on 10.3.9), I have three comments: > > 1. This may have fixed bug 293343; at least the steps in bug 293343 > comment 7 no longer cause it reliably; Yes, it did (as noted in comment 4). > 2. The top and right margins (or padding in a CSS sense) of the > textareas are very tight, which makes the top line hard to read IMO > and textareas somewhat unattractive; I agree; I was trying to make them match Cocoa. I can tweak this. > 3. Inputs are still "beveled" while textareas are not, which is > odd-looking when they're on the same page. This was a deliberate decision, to match Cocoa (and Safari).

Reopen for tweakage.

I spent some time in Safari and see the bevels on inputs there, too. Fair enough. Did you also tweak buttons to allow more styles through? The buttons on the MZ forums, for instance, seem "much" larger and not as well-aligned to their matching inputs as they used to be. If I disable the style rules for the buttons they come back down in size and align almost as before, but are still some pixels too high.

I did tweak the padding on buttons to get close to system appearance for buttons of natural height. Maybe this needs to be undone.

(In reply to comment #20) > I did tweak the padding on buttons to get close to system appearance for buttons > of natural height. Maybe this needs to be undone. Strangely enough, your sample buttons (and those throughout bugzilla) don't seem to have changed perceptibly, but those on the MZ fora do (which is why I asked if more style elements were being honored). Also, I noticed on the reply page of the MZ fora (hit quote rather than using the quick reply) there's a pop-up select next to a button (attached), and that also seems out of alignment now by some pixels.

(In reply to comment #20) > I did tweak the padding on buttons to get close to system appearance for buttons > of natural height. Maybe this needs to be undone. There have been a few complaints about this in the MZ forum, wondering why we have big fat buttons now instead of the small ones like in Safari. Like I said in comment 21, only some buttons (with styles already applied?) seemed to have changed.

So one probem here that causes some buttons (e.g. on Yahoo groups) to look bad is that our css has: input[type="button"] { border-width: 3px 8px 2px 8px; ... but the site is doing something like; input[type="button"] { border: 1px solid blue; so we end up with 1-pixel borders. So maybe our border rules should be !important (although this might break site layouts)?

Simon, are you planning on doing anything more here for 1.0 (aside from bug 315203, which has the separate patch waiting for r/sr/a)? We could do more with comment 9 point 2 (text too tight to edges of textarea) if we take the patch Uri mentions in bug 304609 comment 14, but I *think* it's safe to increase the top padding a few px without consequences regardless. I'm a little surprised we've not seen complaints about bug 311454; I think we should go with the small scrollbars, but it's not a big deal. I'm not sure what to do about the button issues, though. I wonder if reverting to the old (small buttons everywhere, and fewer styles honored) buttons fixes the issues in bug 310266?

I haven't had time to look more at this, and it is time-consuming.

Something odd I've noticed about the button styles: I usually run with browser.display.focus_ring_width set to 0 (to get rid of that dotted line when you click on links), and setting that back to 1 returns some buttons (e.g. news.google.com) to normal size, but leaves others (mz forums) large.

philippe has some nice testcases for some of the issues I raised in comment 16/comment 21 and related issues; see http://dev.l-c-n.com/camino/forms.php

Philippe, is this something you'd like to look at?

(In reply to comment #28) > Philippe, is this something you'd like to look at? > Specifically for the vertical alignment of the input[type="submit"] widgets (as noted in comment #27), I had opened bug 344483, where I also propose some changes to forms.css.

Since all of the discussion here is pretty much about forms.css that we no longer use, and all the future work here will be in another component, I'm going to close this as WFM. Remaining issues should be filed as individual bugs in Widget:Cocoa.