In bug 427045, Roc wrote: "Should these be -moz-win-... instead of just -moz? I think so given the comment in nsILookAndFeel. If we do that I think we don't have to implement them in all platforms." The same applies to media-toolbox, communications-toolbox and browsertabbar-toolbox.

This is just a simple matter of: s/(xxx-toolbox)/-moz-win-$1/ s/(xxx_toolbox)/_moz_win_$1/ ... right?

Comment on attachment 318488 [details] [diff] [review] patch Hm, the NS_THEME_ enums should probably have WIN in them as well, I think? NS_THEME_MEDIA_TOOLBOX_WIN32 or something? Maybe just _WIN?

Oops, uploaded the wrong file in the previous attachment.

Sorry. These items are -moz-appearance constants. So they don't really need -moz or -win in their names because we already know 'appearance' is a Moz-only property. We *do* need -moz and possibly -win in the names of colors since they can appear in cross-browser properties. Make sense?

(In reply to comment #5) > Sorry. These items are -moz-appearance constants. So they don't really need > -moz or -win in their names because we already know 'appearance' is a Moz-only > property. We *do* need -moz and possibly -win in the names of colors since they > can appear in cross-browser properties. Make sense? > Oh, okay. Should this bug be marked as invalid then? So what did you mean by bug 427045 comment 28? My understanding was that these three toolbar styles are Windows-only (well, Vista-only), and that the idea was to flag it so that it is clear that they won't be available on Linux/Mac.

I was thinking about the colors there. I guess we probably should have -win here, but not -moz.

Morphing bug title...

Hmm, are you sure that no-one will implement, for example, BROWSER_TAB_BAR_TOOLBOX for another OS? Note also that iirc there are other NS_THEME things that are not implemented on all OS in there.

Not 100%, but these special toolbox styles are a lot less generic than the other appearance constants.

(In reply to comment #11) > Not 100%, but these special toolbox styles are a lot less generic than the > other appearance constants. Ah, ok. Indeed, they seem to not be generic. I was just wondering since iirc these are the first ones with an OS prefix :-)

I guess this is no more generic than -moz-mac-menuselect (for all we know, Microsoft might decide to fork its highlight color into one for menus and one for everything else in the next Windows).

We should talk about this on MozillaZine, since this could break a bunch of third party themes which relied on these styles.

Comment on attachment 318558 [details] [diff] [review] using the -win- prefix a1.9=beltzner

(In reply to comment #14) > We should talk about this on MozillaZine, since this could break a bunch of > third party themes which relied on these styles. > Yea, and I'll update the docs at MDC, too.

(In reply to comment #7) > I guess we probably should have -win here, but not -moz. Has this been done before? I don't think it's strictly conform to <http://www.w3.org/TR/CSS21/syndata.html#vendor-keywords>.

hmm. That's a good point. I guess the choice is then between attachment #318510 [details] [diff] [review] and attachment #318558 [details] [diff] [review].

David, you choose :-).

(In reply to comment #17) > (In reply to comment #7) > > I guess we probably should have -win here, but not -moz. > > Has this been done before? I don't think it's strictly conform to > <http://www.w3.org/TR/CSS21/syndata.html#vendor-keywords>. > I think excluding -moz is right here for the sake of consistency. If we were to strictly adhere to that, then we'd need to tack -moz- in front of all of the possible -moz-appearance values... would you volunteer to do a patch to change every instance of button, textfield, et al. to -moz-button, -moz-textfield, et al.? ;-) In any case, I'll removed "checkin-needed" until this is decided.

Don't use "-win-*". The "-moz-" in -moz-appearance is sufficient as a vendor prefix, although at some point we might implement the standard appearance property, which would mean we'd need to rename nonstandard values to have the prefix. It should either be "-moz-win-*" (attachment 318510 [details] [diff] [review]) or "win-*" (not one of the options you gave me), but not "-win-*" (attachment 318558 [details] [diff] [review]). As for -moz-win-* vs. win-*, I'd prefer -moz-win-* if you think the values are particularly hackish/temporary (which they are in this case, right?) and win-* if they're permanent (but I hope not). So I'd say just attachment 318510 [details] [diff] [review], but I could probably be convinced as far as win-*.

(In reply to comment #21) > As for -moz-win-* vs. win-*, I'd prefer -moz-win-* if you think the values are > particularly hackish/temporary (which they are in this case, right?) and win-* > if they're permanent (but I hope not). Er, actually, I think my preference between the two depends on what these values do on non-Windows platforms ... whether they do something sensible there is the main indicator (to me) of how hackish they are.

They will probably never do anything on non-Windows platforms. I'm not sure I'd call that "hackish" since I'm not aware of a better approach that would supersede it.

I don't see any code that would make them a parser error on non-Windows (I'm not sure if we want any of our CSS property value space to vary between platforms, though), so they do *something*. If that means using a color from uninitialized memory, or using NS_RGB(0, 0, 0), then I'd call that hackish.

These are -moz-appearance values. So if one of them was used on, say, Mac, nsNativeThemeCocoa::ThemeSupportsWidget will return false. So it behaves just like '-moz-appearance:none'. Which is not the same as if it was a parse error, but it's still innocuous.

Here's the win- prefix, if it is decided to use that instead. Or we could just mark this bug as invalid or wontfix and leave the status-quo. But if we do want to change the name, I personally think that now is the best time because the feature is still new and mostly undiscovered (AFAIK, only one addon is making use of it at the moment).

(In reply to comment #21) > The "-moz-" in -moz-appearance is sufficient as a vendor > prefix, although at some point we might implement the standard appearance > property, which would mean we'd need to rename nonstandard values to have the > prefix. Exactly, and a Windows-only value is less likely to be ever standardized, which is why I would already use -moz-win- today.

Comment on attachment 318510 [details] [diff] [review] using the -moz-win- prefix Alright, I think everyone will be happy with this one and it's the conservative approach.

Note that more stylesheets need to be updated. See URL field.

Dao, do you know of any other bugs that would depend on this change? Bug 431229 is the only one that I am aware of.

Comment on attachment 319898 [details] [diff] [review] additional CSS changes to land r+a=beltzner

Checking in browser/themes/winstripe/browser/browser.css; /cvsroot/mozilla/browser/themes/winstripe/browser/browser.css,v <-- browser.css new revision: 1.219; previous revision: 1.218 done Checking in widget/src/windows/nsNativeThemeWin.cpp; /cvsroot/mozilla/widget/src/windows/nsNativeThemeWin.cpp,v <-- nsNativeThemeWin.cpp new revision: 3.125; previous revision: 3.124 done Checking in layout/style/nsCSSKeywordList.h; /cvsroot/mozilla/layout/style/nsCSSKeywordList.h,v <-- nsCSSKeywordList.h new revision: 3.108; previous revision: 3.107 done Checking in layout/style/nsCSSProps.cpp; /cvsroot/mozilla/layout/style/nsCSSProps.cpp,v <-- nsCSSProps.cpp new revision: 3.169; previous revision: 3.168 done Checking in gfx/public/nsThemeConstants.h; /cvsroot/mozilla/gfx/public/nsThemeConstants.h,v <-- nsThemeConstants.h new revision: 1.28; previous revision: 1.27 done

Checking in browser/themes/winstripe/browser/browser-aero.css; /cvsroot/mozilla/browser/themes/winstripe/browser/browser-aero.css,v <-- browser-aero.css new revision: 1.15; previous revision: 1.14 done Checking in browser/themes/winstripe/browser/places/organizer-aero.css; /cvsroot/mozilla/browser/themes/winstripe/browser/places/organizer-aero.css,v <-- organizer-aero.css new revision: 1.3; previous revision: 1.2 done

Verified with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008050806 Minefield/3.0pre ID:2008050806

Where's this documented?

(In reply to comment #36) > Where's this documented? > * Under "all properties accepting color keywords" at <http://developer.mozilla.org/en/docs/CSS_Reference:Mozilla_Extensions> (most of the -moz- colors are only listed there and have no page of their own) * Mentioned alongside their corresponding -moz-win- background style at <http://developer.mozilla.org/en/docs/CSS:-moz-appearance>

(In reply to comment #37) > * Under "all properties accepting color keywords" at > * Mentioned alongside their corresponding -moz-win- background style at > Oops. I didn't pay attention to the bug title and mistakenly thought that this was the foreground color bug. The toolbar background styles are documented only in the -moz-appearance article.

I've added the toolbar styles to the Mozilla Extensions page.