The pseudocolor "menu" has been defined as rgb(14, 55, 231), i.e. the blue background highlight of MacOS menus. Whilst a useful color in its own right, this does not duplicate typical usage of "menu" on other systems. "menu" is normally used for unselected items, and so should be a neutral gray - or, if you can insert a background image instead of a color - it might usefully be the same gradient or transparency that is used in menus. In any case, it should not be the menu-selected color. See URL example from LiveJournal of how "menu" is typically used in the field; note the menu bar across the top.
<rdar://problem/5692407>
The colour looks roughly correct, a darkish grey, in Safari 3.0.4. In TOT it's a bright blue, which definitely doesn't look right in this context.
*** Bug 16943 has been marked as a duplicate of this bug. ***
RenderThemeMac maps the menu pseudocolor to [NSColor selectedMenuItemColor], which explains the blue appearance. Looking over the methods on NSColor I can't see which method should be used in its place though.
(In reply to comment #4) > RenderThemeMac maps the menu pseudocolor to [NSColor selectedMenuItemColor], > which explains the blue appearance. Looking over the methods on NSColor I > can't see which method should be used in its place though. Looks like HIThemeDrawMenuBackground() can be used to draw the pattern into a graphics context, then a pixel can be sampled, the way the NSColor-based patterns are handled.
Created attachment 18615 [details] Use HITheme to get the color from the menu item background pattern
Fixed in <http://trac.webkit.org/projects/webkit/changeset/29728>.
Oh no, dude. You turned "menu" PINK! You're getting a flat menu color from the HITheme bitmap, right? I think you've chosen an unrepresentative pixel - or maybe worse, the pink was meant to be hidden by the alpha channel in the bitmap. Try going for a central pixel? This is on 3.0.4 (5523.10.6) - nightly from 10th Feb 2008. I think perhaps a better plan might be to pick colors by hand. This is not an exact science. The problem is that the list of colors map to the variables in a Windows 95 (or maybe 2000) theme, which is very crude by todays standards. It is probably more important that they are self-consistent, than that they are drawn from a pixel of the current Mac theme-du-jour. Here is the list of oddities in the current color selection: - MenuText on Menu is black on pink. It should probably be black on light gray. - HighlightText on HighLight is black on lilac for me - i.e. themed text selection color. This does not appear to be Microsoft's original intent. HighlightText on HighLight is the combo that they use for highlighting selected menu items. It should, therefore, on Leopard, be white on blue. The present choice might equally represent what it has been used for in the field... but the general consensus is at least light on dark - and this will give better odds when web designers mix and match colors. - CaptionText on ActiveCaption is black on black. This is unreadable. It is the combo originally intended to be for title bars on windows, and is white on dark blue under IE7. - InactiveCaptionText on InactiveCaption should follow the same theme but be paler. One of the most useful references to MS's original intent is their own page... http://msdn2.microsoft.com/en-us/library/aa358804(VS.85).aspx ...showing the anticipated "System Color Combinations". I will add some attachments.
Created attachment 19068 [details] Demo of system colors used in menus, buttons and input fields, per Microsoft original intent
Created attachment 19069 [details] System colors rendered by IE7 on XP
I updated again. Sorry - I have no idea which nightly gave me pink. We are back to a more sensible gray now. Comments about other pseudocolors remain valid - though this is therefore now not strictly the same, originally reported bug. Severity reassigned as minor, reflecting limited use in the field of other pseudocolors. (They are used mostly by intranet apps.)
(In reply to comment #11) > Comments about other pseudocolors remain valid - though this is therefore now > not strictly the same, originally reported bug. Please file a separate bug on those. Thanks!