Dimension dropdown: different values for 20%

[jfeltesse]

See the two values for 20% in the screenshot: which one is it?

Version 2.8.0.

[sindresorhus]

The percentages in parens are rounded. The 20% one there is actually 20.83%, but that wouldn't look very nice. I'm happy to consider suggestions on how we can make that clearer.

[jfeltesse]

What's the rationale for having two separate sections in the first place?

[sindresorhus]

The first is a predefined list of common sizes and the second are exact percentages.

[kornelski]

Maybe deduplicate them by percentages? (put in a hashmap using rounded percentage as the key)

[kornelski]

The list could also use trimming: don't suggest HD resolutions (lots of GIF viewers are unprepared for that, e.g. QuickLook grinds my machine to halt even on 720p GIF), or resolutions below 100px.

[sindresorhus]

Maybe deduplicate them by percentages? (put in a hashmap using rounded percentage as the key)

They have different purposes. Someone might want exactly 25% of the original or someone might want an exact size.

The list could also use trimming: don't suggest HD resolutions (lots of GIF viewers are unprepared for that, e.g. QuickLook grinds my machine to halt even on 720p GIF), or resolutions below 100px.

That really depends on the FPS. I often use 960 for GIFs when there's little movement and low FPS.

[jfeltesse]

Sorry for the late reply.

Are there examples of the use case for wanting "exactly xx%"?
I have no data alright, but I'd assume most, if not all, of the people primarily care about the size in pixels, and while having the % it corresponds to is very helpful, it doesn't drive the decision between multiple sizes.

If it's legit use case and the current layout ought to be kept, the one quick fix I can imagine is to add ~ to denote the % may not be exact (e.g. "800x450 (~20%)") but I'm not sure if it's universally recognized as meaning "approximately".

[sindresorhus]

Are there examples of the use case for wanting "exactly xx%"?

When you record on a retina screen (2x), you might want to scale to 50% exactly to get the same size as 1x.

I have no data alright, but I'd assume most, if not all, of the people primarily care about the size in pixels

You're assuming that everyone cares about the exact pixel size. That is rarely the case for me. I just want it smaller, and having some quick predefined "steps" are useful.

[jfeltesse]

It doesn't look like a simple solution is going to come off this issue so allow me to close it for now. I had opened this issue thinking it was some rounding bug but now I understand it's simply two different approaches.

Thanks for the tool and your other repos btw (using Ky on some projects)!

[sindresorhus]

We can keep it open until we figure out a solution.

[janbrasna]

I think the "(~##%)" approximation symbol works intuitively enough now. 👍

What might help to differentiate what's the primary value & what's secondary is: contrast, as in:

… but i have no idea about such feasibility in Swift/UI.

---

PS: If you replace the "x" character with the correct "×" multiplication sign it helps the readability too. I've opened a PR #213 for it however I'm not 100% sure I can just slap such character in the String() format specifier 🤷‍♂️

[sindresorhus]

@janbrasna That's a good idea.

I'm also wondering if it would help if we aligned them as columns:

10 x 10    (4%)
100 x 100  (40%)

[31aditya0193]

@sindresorhus may i open an issue for column alignment and fix up a quick PR?

[sindresorhus]

may i open an issue for column alignment and fix up a quick PR?

I'm no longer sure that's the best solution since it will look ugly when it's shown in the unopened dropdown. And it's impossible to perfectly align them unless we use monospaced font, which it's a no-go.