Skip to content

Conversation

@niemela
Copy link
Member

@niemela niemela commented Sep 15, 2025

Fixes #202

@deboer-tim
Copy link
Member

No concern with what's here so far, but I think we need an addition to the contest package format as well - otherwise there is no persistence of this data. We already added variant there, but needs to cover multiple variant strings, and currently same image variant is expected to be x.

@niemela
Copy link
Member Author

niemela commented Sep 15, 2025

No concern with what's here so far, but I think we need an addition to the contest package format as well - otherwise there is no persistence of this data.

There is persistence. You are always allowed to have a file reference object in the JSON files, and that would store the variant info.

We already added variant there,

Yes, and since that's not exactly the same thing, we probably should not call it the same?

but needs to cover multiple variant strings, and currently same image variant is expected to be x.

What do you think about saying that the variant may not include _, and that the "variant" (needs anew name) specified in the CPF is the WxH concatenated with all variants, separated by _. So, a 160x160 image suitable on light would be logo.160x160_light.png, and a 56x56 suitable on both would be logo.56x56_light_dark.png?

Contest_API.md Outdated
| mime | string | Mime type of resource.
| width | integer ? | Width of the image. Required for files with mime type image/\*.
| height | integer ? | Height of the image. Required for files with mime type image/\*.
| variant | array of string | Intended usage hints (e.g. `light`, `dark` for images).
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe I'm the only one, but I don't think variant is a good name here as to me it suggests that the options are mutually exclusive. Also, given that this is a list of options, I'd go for a plural terms, so for lack of better, I'd say tags.

@deboer-tim
Copy link
Member

No concern with what's here so far, but I think we need an addition to the contest package format as well - otherwise there is no persistence of this data.

There is persistence. You are always allowed to have a file reference object in the JSON files, and that would store the variant info.

Yes, but we often have files without json or incomplete json, so would be preferable to have both options, just like we do with x.

We already added variant there,

Yes, and since that's not exactly the same thing, we probably should not call it the same?

Agreed, and I'm ok with modifying either term.

but needs to cover multiple variant strings, and currently same image variant is expected to be x.

What do you think about saying that the variant may not include _,

+1

and that the "variant" (needs anew name) specified in the CPF is the WxH concatenated with all variants, separated by _. So, a 160x160 image suitable on light would be logo.160x160_light.png, and a 56x56 suitable on both would be logo.56x56_light_dark.png?

Generally, yes. We only say 'should' for the x so probably just the same thing here.

Variant is allowed to be anything today (and I think we want to keep that?) so I think server just looks for its known variants after splitting up the variant string by '_'.

nickygerritsen
nickygerritsen previously approved these changes Sep 29, 2025
deboer-tim
deboer-tim previously approved these changes Sep 29, 2025
Copy link
Member

@deboer-tim deboer-tim left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a few minor suggestions, but approving.

@nickygerritsen nickygerritsen added this to the 2025-09 milestone Oct 13, 2025
@niemela
Copy link
Member Author

niemela commented Oct 13, 2025

Discussed on the meeting today. I will fix the outstanding comments and then merge. Comment if you disagree...

@niemela niemela dismissed stale reviews from deboer-tim and nickygerritsen via 4d9f6fe October 27, 2025 18:20
Co-authored-by: Jaap Eldering <eldering@users.noreply.github.com>
| mime | string | Mime type of resource.
| width | integer ? | Width of the image. Required for files with mime type image/\*.
| height | integer ? | Height of the image. Required for files with mime type image/\*.
| variant | array of string | Intended usage hints (e.g. `light`, `dark` for images). No meaning must be implied or inferred from the order of the elements.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I slightly prefer tag, but ok either way.

organizations/kth.se/logo.160x160.png
organizations/baylor.edu/logo.56x56.png
organizations/baylor.edu/logo.160x160.png
organizations/tudelft.nl/logo.dark.56x56.png
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should maybe add a one example with multiple variants/tags?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, we should. I suggest doing it later.

@niemela
Copy link
Member Author

niemela commented Oct 27, 2025

We discussed this at the meeting. I will merge after the meeting it gets approved.

@niemela
Copy link
Member Author

niemela commented Oct 27, 2025

I will change name to tags and, then merge after approval.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Support dark/light images

6 participants