Right now we just return an empty object for the default theme is applied, but we could return some actual values from the browser css.

If we agree that we should get values for other built-in themes (dark, light), why would we not get values from default as well?

getCurrent should always return theme data that an extension can use to theme itself, there is no reason not to.

(In reply to Shane Caraveo (:mixedpuppy) from comment #3) > getCurrent should always return theme data that an extension can use to > theme itself, there is no reason not to. Well, the default theme(s) does more than what the theming api can do, which makes it hard to return theme data.

(In reply to Tim Nguyen :ntim from comment #4) > > getCurrent should always return theme data that an extension can use to > > theme itself, there is no reason not to. > > Well, the default theme(s) does more than what the theming api can do, which > makes it hard to return theme data. Can't we just return values that the theming API *can* do? I would expect that would be the case for all three built-ins, since I assume they all do more than what the theming API can do...

(In reply to David Durst [:ddurst] (REO for 63) from comment #5) > (In reply to Tim Nguyen :ntim from comment #4) > > > getCurrent should always return theme data that an extension can use to > > > theme itself, there is no reason not to. > > > > Well, the default theme(s) does more than what the theming api can do, which > > makes it hard to return theme data. > > Can't we just return values that the theming API *can* do? I would expect > that would be the case for all three built-ins, since I assume they all do > more than what the theming API can do... Sure, but that wouldn't necessarily make a representative result of how the theme is displayed. An example is the default theme on macOS, right now querying `frame/accentcolor` would return #eeeeee (light gray) even though we use dark vibrancy (black blended with whatever is behind the window), which is obviously wrong. Of course, we can always return hardcoded values, but that also maintaining them over the releases.

Personally, I think that's OK. Because a developer can only apply what's available in the theming API, when/if we're looking to leverage the theming API to make other extension UI look consistent (sidebars, etc), being able to get the existing values is substantially better than guessing at all the values that are involved. If your point is that those values, once retrieved, don't actually provide the visual result -- I would argue it's still closer than giving nothing. That ".get-in-order-to-.set elsewhere" idea was the impetus behind this request for Light and Dark in the first place (with Default following on because it seems weird to leave it out). From the extensions POV, these values are in a css file, so we could use those -- and we've talked about being able to update/parameterize that css file based on the user's selection of another built-in (since its current state is matching/derived from "default"). This would allow the browser_style property to be more meaningful. If that were the case, I would probably care less about getting theming API analogue values from getCurrent; it would seem inconsistent (to me), but for extensions the goal would be achievable.

(In reply to David Durst [:ddurst] (REO for 63) from comment #7) > That ".get-in-order-to-.set elsewhere" idea was the impetus behind this > request for Light and Dark in the first place (with Default following on > because it seems weird to leave it out). I would take that a few steps further...it's not weird, it's broken. "default" can mean different things on different platforms/etc. Having a consistent programmatic way to get relatively consistent appearance is a good thing.

Adding 1455960 to see also because of the browser_style impact.