Support dark/light images

[nickygerritsen]

We run into issues with logos and banners a lot where they only work great on either a dark or light background.

I think it would be great if we have a way of having image 'versions' or something, where we can say they work on a light or dark background and we can support both at the same time.

[niemela]

I believe we almost added this a while back. I still think the solution we were heading towards then still works:

• Add an additional property to the file reference object, maybe variant? (Not a great name, but I don't think we should use type, and most other ideas I thought of were IMO worse: "comment", "context", "appearance", "hint", "usage", "theme")
• Specify for the logo properties, that using variant: light means that the logo is intended to work on a light background, variant: dark means that the logo is intended to work on a dark background.

[eldering]

* Add an additional property to the file reference object, maybe `variant`? (Not a _great_ name, but I don't think we should use `type`, and most other ideas I thought of were IMO worse: "comment", "context", "appearance", "hint", "usage", "theme")

I think variant (and most of the other options) are too generic and would easily clash with something else in the future, and also not clearly express the intent of this property. What about color-mode referring to light/dark mode, or something similar?

[niemela]

I think variant (and most of the other options) are too generic and would easily clash with something else in the future, and also not clearly express the intent of this property. What about color-mode referring to light/dark mode, or something similar?

My thinking was exactly that (but opposite), i.e. I wanted it to be more generic. This could (and IMO should) be a generic property specifying what variant of "the thing" this is (hence that that is my favorite option so far). This is after all a property on the file reference, not the image reference.

If we want to be more specific, wouldn't theme or maybe style be better?

[eldering]

My thinking was exactly that (but opposite), i.e. I wanted it to be more generic. This could (and IMO should) be a generic property specifying what variant of "the thing" this is (hence that that is my favorite option so far). This is after all a property on the file reference, not the image reference.

But then it feels like this variant property may become a dumping ground of any tag/label/description that anyone finds useful. Then does it become a comma-separated list or such if there are multiple non-exclusive tags/labels besides light/dark? I feel it doesn't help with clarity of how to use this field and what you can expect there.

If we want to be more specific, wouldn't theme or maybe style be better?

I find that still a bit vague: for both one might expect values such as "modern", "shiny", "rounded", etc. So I'd rather make the name a bit longer and more explicit.

[niemela]

But then it feels like this variant property may become a dumping ground of any tag/label/description that anyone finds useful.

Yes, it could.

I would rather have one tag/label/description field then specifying multiple (but more specific) such fields.

Then does it become a comma-separated list or such if there are multiple non-exclusive tags/labels besides light/dark? I feel it doesn't help with clarity of how to use this field and what you can expect there.

We did discuss this at the meeting. This problem appears even for the main specific use case (dark/light images) that started this. In reality it is certainly the case that some images work only on light background, some only on dark, while some work perfectly fine on both. There is also the fact we might not yet have verified whether they work on light and/or dark yet (this can be avoided at large high resource contests like the WF, but in practice at smaller contest it could definitely be the case). How should we handle this with the variant property? (possibly using a different name, but let's ignore that for now).

I'm leaning towards something like this. Setting the property to "dark" means that it works well on dark backgrounds, same (but opposite) for "light". With this semantics, an image known to work on both should have both values, and an image that is unknown whether it works on either (or in a system that does not handle or know about this) should have neither.

There are two good(-ish) ways to support multiple values. Either we can say that every file reference can have only one, and if you need a file to be available under many you have many file references to the same file. The other is to make variant an array of string.

If we want to be more specific, wouldn't theme or maybe style be better?

I find that still a bit vague: for both one might expect values such as "modern", "shiny", "rounded", etc. So I'd rather make the name a bit longer and more explicit.

The darkmode/lightmode setting in most (many?) apps is literally called "theme", so that seems specific enough to me. I agree that style is more generic (or vague), although I find the examples you mention actually useful (e.g. rounded). But, again, if we want more generic and usable in more cases, we should probably go all the way to variant instead of just style?

[eldering]

There are two good(-ish) ways to support multiple values. Either we can say that every file reference can have only one, and if you need a file to be available under many you have many file references to the same file. The other is to make variant an array of string.

If we want to be more specific, wouldn't theme or maybe style be better?

I find that still a bit vague: for both one might expect values such as "modern", "shiny", "rounded", etc. So I'd rather make the name a bit longer and more explicit.

The darkmode/lightmode setting in most (many?) apps is literally called "theme", so that seems specific enough to me. I agree that style is more generic (or vague), although I find the examples you mention actually useful (e.g. rounded). But, again, if we want more generic and usable in more cases, we should probably go all the way to variant instead of just style?

I'd prefer an array of strings then, but then also I think this field should be renamed to tags or labels or so, to make it clear there can be multiple and they're not necessarily mutually exclusive. The name variant would suggest that, I think.