gecko-dev/layout/style/PreferenceSheet.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

138 строки
3.5 KiB
C
Исходник Обычный вид История

/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
/* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
/* Some prefable colors for style system use */
#ifndef mozilla_ColorPreferences_h
#define mozilla_ColorPreferences_h
#include "nsColor.h"
Bug 1525107 - Make Canvas/CanvasText and Link colors color-scheme-aware. r=dholbert For that, add `.dark` version of the browser.display* prefs that control the light version of these colors. The default for background/foreground colors are taken from the GenericDarkColors used in LookAndFeel. The defaults for links are based on this discussion: https://github.com/whatwg/html/issues/5426#issuecomment-904021675 (So they effectively match Chrome). Whether the dark colors should be exposed in about:preferences (like the light colors are) is TBD. With this patch, we pass all the tests in: /html/semantics/document-metadata/the-meta-element/color-scheme/ Use the colors to paint the default canvas background and the default colors. There are three "regressions", though they are really progressions: we now render the reference as the test expects (before we rendered a light canvas background even for the reference). Apart of these iframe tests (which we should look into, I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1738380), there are three remaining test failures. Two of them are due to `color: initial` not changing based on the color-scheme. Safari also fails these tests, and the thing they're really testing is whether system colors are preserved at computed-value time: https://github.com/w3c/csswg-drafts/issues/3847 Regarding that change, I'm not so sure the trade-offs there are worth it, as that not only complicates interpolation (we wouldn't be able to use system colors in color-mix among others, see https://github.com/w3c/csswg-drafts/issues/5780) plus it changes inheritance behavior in sorta unexpected ways, see: https://github.com/w3c/csswg-drafts/issues/6773 Which I just filed because apparently no browser implements this correctly. So for now will punt on those (keep matching Safari). There's an svg-as-image test: https://searchfox.org/mozilla-central/rev/f8576fec48d866c5f988baaf1fa8d2f8cce2a82f/testing/web-platform/tests/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html Which isn't using the feature at all and I'm not sure why is it supposed to pass (why prefers-color-scheme: dark is supposed to match that SVG image). This test fails in all browsers apparently: https://wpt.fyi/results/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html?label=master&label=experimental&aligned I sent https://github.com/web-platform-tests/wpt/pull/31407 to remove it and hopefully get it reviewed by some Chromium folks. Differential Revision: https://phabricator.services.mozilla.com/D129746
2021-10-29 22:58:25 +03:00
#include "mozilla/ColorScheme.h"
namespace mozilla {
namespace dom {
class Document;
}
struct PreferenceSheet {
struct Prefs {
Bug 1525107 - Make Canvas/CanvasText and Link colors color-scheme-aware. r=dholbert For that, add `.dark` version of the browser.display* prefs that control the light version of these colors. The default for background/foreground colors are taken from the GenericDarkColors used in LookAndFeel. The defaults for links are based on this discussion: https://github.com/whatwg/html/issues/5426#issuecomment-904021675 (So they effectively match Chrome). Whether the dark colors should be exposed in about:preferences (like the light colors are) is TBD. With this patch, we pass all the tests in: /html/semantics/document-metadata/the-meta-element/color-scheme/ Use the colors to paint the default canvas background and the default colors. There are three "regressions", though they are really progressions: we now render the reference as the test expects (before we rendered a light canvas background even for the reference). Apart of these iframe tests (which we should look into, I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1738380), there are three remaining test failures. Two of them are due to `color: initial` not changing based on the color-scheme. Safari also fails these tests, and the thing they're really testing is whether system colors are preserved at computed-value time: https://github.com/w3c/csswg-drafts/issues/3847 Regarding that change, I'm not so sure the trade-offs there are worth it, as that not only complicates interpolation (we wouldn't be able to use system colors in color-mix among others, see https://github.com/w3c/csswg-drafts/issues/5780) plus it changes inheritance behavior in sorta unexpected ways, see: https://github.com/w3c/csswg-drafts/issues/6773 Which I just filed because apparently no browser implements this correctly. So for now will punt on those (keep matching Safari). There's an svg-as-image test: https://searchfox.org/mozilla-central/rev/f8576fec48d866c5f988baaf1fa8d2f8cce2a82f/testing/web-platform/tests/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html Which isn't using the feature at all and I'm not sure why is it supposed to pass (why prefers-color-scheme: dark is supposed to match that SVG image). This test fails in all browsers apparently: https://wpt.fyi/results/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html?label=master&label=experimental&aligned I sent https://github.com/web-platform-tests/wpt/pull/31407 to remove it and hopefully get it reviewed by some Chromium folks. Differential Revision: https://phabricator.services.mozilla.com/D129746
2021-10-29 22:58:25 +03:00
struct Colors {
nscolor mLink = NS_RGB(0x00, 0x00, 0xEE);
nscolor mActiveLink = NS_RGB(0xEE, 0x00, 0x00);
nscolor mVisitedLink = NS_RGB(0x55, 0x1A, 0x8B);
nscolor mDefault = NS_RGB(0, 0, 0);
nscolor mDefaultBackground = NS_RGB(0xFF, 0xFF, 0xFF);
nscolor mFocusText = mDefault;
nscolor mFocusBackground = mDefaultBackground;
Bug 1525107 - Make Canvas/CanvasText and Link colors color-scheme-aware. r=dholbert For that, add `.dark` version of the browser.display* prefs that control the light version of these colors. The default for background/foreground colors are taken from the GenericDarkColors used in LookAndFeel. The defaults for links are based on this discussion: https://github.com/whatwg/html/issues/5426#issuecomment-904021675 (So they effectively match Chrome). Whether the dark colors should be exposed in about:preferences (like the light colors are) is TBD. With this patch, we pass all the tests in: /html/semantics/document-metadata/the-meta-element/color-scheme/ Use the colors to paint the default canvas background and the default colors. There are three "regressions", though they are really progressions: we now render the reference as the test expects (before we rendered a light canvas background even for the reference). Apart of these iframe tests (which we should look into, I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1738380), there are three remaining test failures. Two of them are due to `color: initial` not changing based on the color-scheme. Safari also fails these tests, and the thing they're really testing is whether system colors are preserved at computed-value time: https://github.com/w3c/csswg-drafts/issues/3847 Regarding that change, I'm not so sure the trade-offs there are worth it, as that not only complicates interpolation (we wouldn't be able to use system colors in color-mix among others, see https://github.com/w3c/csswg-drafts/issues/5780) plus it changes inheritance behavior in sorta unexpected ways, see: https://github.com/w3c/csswg-drafts/issues/6773 Which I just filed because apparently no browser implements this correctly. So for now will punt on those (keep matching Safari). There's an svg-as-image test: https://searchfox.org/mozilla-central/rev/f8576fec48d866c5f988baaf1fa8d2f8cce2a82f/testing/web-platform/tests/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html Which isn't using the feature at all and I'm not sure why is it supposed to pass (why prefers-color-scheme: dark is supposed to match that SVG image). This test fails in all browsers apparently: https://wpt.fyi/results/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html?label=master&label=experimental&aligned I sent https://github.com/web-platform-tests/wpt/pull/31407 to remove it and hopefully get it reviewed by some Chromium folks. Differential Revision: https://phabricator.services.mozilla.com/D129746
2021-10-29 22:58:25 +03:00
} mLightColors, mDarkColors;
const Colors& ColorsFor(ColorScheme aScheme) const {
return mMustUseLightColorSet || aScheme == ColorScheme::Light
? mLightColors
: mDarkColors;
Bug 1525107 - Make Canvas/CanvasText and Link colors color-scheme-aware. r=dholbert For that, add `.dark` version of the browser.display* prefs that control the light version of these colors. The default for background/foreground colors are taken from the GenericDarkColors used in LookAndFeel. The defaults for links are based on this discussion: https://github.com/whatwg/html/issues/5426#issuecomment-904021675 (So they effectively match Chrome). Whether the dark colors should be exposed in about:preferences (like the light colors are) is TBD. With this patch, we pass all the tests in: /html/semantics/document-metadata/the-meta-element/color-scheme/ Use the colors to paint the default canvas background and the default colors. There are three "regressions", though they are really progressions: we now render the reference as the test expects (before we rendered a light canvas background even for the reference). Apart of these iframe tests (which we should look into, I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1738380), there are three remaining test failures. Two of them are due to `color: initial` not changing based on the color-scheme. Safari also fails these tests, and the thing they're really testing is whether system colors are preserved at computed-value time: https://github.com/w3c/csswg-drafts/issues/3847 Regarding that change, I'm not so sure the trade-offs there are worth it, as that not only complicates interpolation (we wouldn't be able to use system colors in color-mix among others, see https://github.com/w3c/csswg-drafts/issues/5780) plus it changes inheritance behavior in sorta unexpected ways, see: https://github.com/w3c/csswg-drafts/issues/6773 Which I just filed because apparently no browser implements this correctly. So for now will punt on those (keep matching Safari). There's an svg-as-image test: https://searchfox.org/mozilla-central/rev/f8576fec48d866c5f988baaf1fa8d2f8cce2a82f/testing/web-platform/tests/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html Which isn't using the feature at all and I'm not sure why is it supposed to pass (why prefers-color-scheme: dark is supposed to match that SVG image). This test fails in all browsers apparently: https://wpt.fyi/results/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html?label=master&label=experimental&aligned I sent https://github.com/web-platform-tests/wpt/pull/31407 to remove it and hopefully get it reviewed by some Chromium folks. Differential Revision: https://phabricator.services.mozilla.com/D129746
2021-10-29 22:58:25 +03:00
}
bool mIsChrome = false;
bool mUseAccessibilityTheme = false;
bool mUseDocumentColors = true;
bool mUsePrefColors = false;
bool mUseStandins = false;
bool mMustUseLightColorSet = false;
// Sometimes we can force a color scheme on a document, or honor the
// preferred color-scheme in more cases, depending on whether we're forcing
// colors or not.
enum class ColorSchemeChoice : uint8_t {
// We're not forcing colors, use standard algorithm based on specified
// style and meta tags and so on.
Standard,
// We can honor whatever the preferred color-scheme for the document is
// (the preferred color-scheme of the user, since we're forcing colors).
UserPreferred,
Light,
Dark,
};
ColorSchemeChoice mColorSchemeChoice = ColorSchemeChoice::Standard;
// Whether the non-native theme should use real system colors for widgets.
bool NonNativeThemeShouldBeHighContrast() const;
void Load(bool aIsChrome);
Bug 1525107 - Make Canvas/CanvasText and Link colors color-scheme-aware. r=dholbert For that, add `.dark` version of the browser.display* prefs that control the light version of these colors. The default for background/foreground colors are taken from the GenericDarkColors used in LookAndFeel. The defaults for links are based on this discussion: https://github.com/whatwg/html/issues/5426#issuecomment-904021675 (So they effectively match Chrome). Whether the dark colors should be exposed in about:preferences (like the light colors are) is TBD. With this patch, we pass all the tests in: /html/semantics/document-metadata/the-meta-element/color-scheme/ Use the colors to paint the default canvas background and the default colors. There are three "regressions", though they are really progressions: we now render the reference as the test expects (before we rendered a light canvas background even for the reference). Apart of these iframe tests (which we should look into, I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1738380), there are three remaining test failures. Two of them are due to `color: initial` not changing based on the color-scheme. Safari also fails these tests, and the thing they're really testing is whether system colors are preserved at computed-value time: https://github.com/w3c/csswg-drafts/issues/3847 Regarding that change, I'm not so sure the trade-offs there are worth it, as that not only complicates interpolation (we wouldn't be able to use system colors in color-mix among others, see https://github.com/w3c/csswg-drafts/issues/5780) plus it changes inheritance behavior in sorta unexpected ways, see: https://github.com/w3c/csswg-drafts/issues/6773 Which I just filed because apparently no browser implements this correctly. So for now will punt on those (keep matching Safari). There's an svg-as-image test: https://searchfox.org/mozilla-central/rev/f8576fec48d866c5f988baaf1fa8d2f8cce2a82f/testing/web-platform/tests/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html Which isn't using the feature at all and I'm not sure why is it supposed to pass (why prefers-color-scheme: dark is supposed to match that SVG image). This test fails in all browsers apparently: https://wpt.fyi/results/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html?label=master&label=experimental&aligned I sent https://github.com/web-platform-tests/wpt/pull/31407 to remove it and hopefully get it reviewed by some Chromium folks. Differential Revision: https://phabricator.services.mozilla.com/D129746
2021-10-29 22:58:25 +03:00
void LoadColors(bool aIsLight);
};
static void EnsureInitialized() {
if (sInitialized) {
return;
}
Initialize();
}
static void Refresh() {
sInitialized = false;
Initialize();
}
static bool AffectedByPref(const nsACString&);
static Prefs& ContentPrefs() {
MOZ_ASSERT(sInitialized);
return sContentPrefs;
}
static Prefs& ChromePrefs() {
MOZ_ASSERT(sInitialized);
return sChromePrefs;
}
static Prefs& PrintPrefs() {
MOZ_ASSERT(sInitialized);
return sPrintPrefs;
}
enum class PrefsKind {
Chrome,
Print,
Content,
};
static PrefsKind PrefsKindFor(const dom::Document&);
static bool ShouldUseChromePrefs(const dom::Document& aDocument) {
return PrefsKindFor(aDocument) == PrefsKind::Chrome;
}
static bool MayForceColors() { return !ContentPrefs().mUseDocumentColors; }
static const Prefs& PrefsFor(const dom::Document& aDocument) {
switch (PrefsKindFor(aDocument)) {
case PrefsKind::Chrome:
return ChromePrefs();
case PrefsKind::Print:
return PrintPrefs();
case PrefsKind::Content:
break;
}
return ContentPrefs();
}
private:
static bool sInitialized;
static Prefs sChromePrefs;
static Prefs sPrintPrefs;
static Prefs sContentPrefs;
static void Initialize();
};
} // namespace mozilla
#endif