Created attachment 387272 [details] FF3.5, IE8, Chrome (top to bottom) The rendering of <select> is wrong on Windows 7. The dropdown should be a gray box with some sort of shading on it, but we're just rendering it plain white, without even a border. It looks correct on hover, however. See screenshot for comparison of Firefox 3.5 vs. IE8/Chrome. Tested on latest trunk, looks the same there.
This is consistent with the styling performed by the rest of the OS (Ex: Start -> Run). The dropdown marker does appear to be a few pixels too wide on the left however.
Rob pointed this out on IRC, and I agree with his assessment. It is confusing to have IE8's rendering of native OS widgets be incorrect. :) I'm fine with INVALID here since this is apparently the way the OS intends them to look.
Created attachment 387310 [details] Windows 7 drop-down list Well, this is what a drop-down list actually looks like in Windows 7. The white look is for a drop-down (i.e. the editable version). I would guess that IE's appearance is a compromise so that CSS on the items/background work better, but it doesn't suffer from Firefox's "looks like an editable control when it isn't" issue. I'd also dispute the comment #0 "it looks correct on hover"; Firefox displays the correct hover for an editable drop-down, but that isn't the same as IE/Chrome.
Interesting, I hadn't noticed that. (In reply to comment #3) > I'd also dispute the comment #0 "it looks correct on hover"; Firefox displays > the correct hover for an editable drop-down, but that isn't the same as > IE/Chrome. I just meant "looks the same as IE/Chrome in that situation", which AFAICT, it does.
Created attachment 387350 [details] Windows 7 drop-down list on hover: IE8 vs FF3.5 Broadly similar, yes, but not the same. In any case, there needs to be some decision on what the correct look should be since, as attachment #387310 [details] shows, the native-app look probably isn't the most appropriate for webpages.
FWIW, I am in favor of keeping the status quo. With respect to the textbox-like/button-like issue, every browser uses the textbox appearance. Non-Aero (themed in XP and classic in all versions) uses the textbox appearance. And if we used the button style, we will still have to fall back to using the textbox appearance when there is author styling of the border, background, etc. So a button-style appearance, while consistent with the OS, would be the odd man out. (That having been said, Gecko's native Gtk rendering of <select> uses Gtk's button-like appearance for non-editable <select>s.) WRT the two different styles of the textbox-like appearance, it's not our fault that other browser vendors don't fully implement native themes on Windows (look at IE's lack of scrollbar hover effects!). The Chrome/IE style is what you'd get if you used the exact same code on Vista/W7 as you did on XP, while we go the extra mile and recognize that on Vista/W7, there is a new style available for use and use it. We also fall back to the old style if there is author-specified borders/background that break the assumptions necessary for the new style to work. (I think the old/new menulist style thing in Aero is probably a compatibility mechanism: if old code written for XP made certain assumptions WRT the appearance--e.g., that the drop button is opaque and thus compatible with different background colors--then switching the appearance from underneath that application would not be desirable, so the new style must be explicitly asked for and applications that do not will get a rendering that is more visually compatible with the style used in XP. Kinda like having to declare in a manifest that your application is okay with uxthemed controls.)
FWIW, IE9 uses the correct rendering.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.