Discussion: Project Status, and iro.js 6.0
jaames opened this issue · 6 comments
Status Update
It only takes a quick glance at this project's commit history to see that things aren't so active here anymore. That's not necessarily a bad thing, since it means iro.js is fairly stable!
The truth is I haven't had much time/motivation to work on iro.js since beginning my current job a couple of years ago, however for various reasons I'm probably going to begin looking for a new work sometime in January 2022. Since iro.js is still semi-popular and a nice portfolio piece (plus I just miss working on it), I think it's time that I give it some more love!
P.S. If you know anywhere that is remote-friendly and looking for a frontend developer that enjoys working on UI components and also has experience with design, 3D, art tools, etc - please let me know :)
Changes regarding support and feature requests
Unless you're a GitHub sponsor or using iro.js in an a large open-source project, I will no longer be taking general feature requests nor will I be providing support outside of bugs/issues.
This isn't necessarily a change that I want to make, because I like helping people out! However I've easily spent >100 hours providing free support (over email, particularly) for this library over the years, with people that are often either outright rude, waste my time with generic webdev questions they could search on Google, or just want me to develop some feature for their commercial product... for free.
Considering that apparently even a big LED panel manufacturer is willing to use iro.js yet stoop so low as to ask me to develop custom features for them for free (yes, really), I'm deciding that my time will be better spent doing other things.
Thank you for understanding
Iro.js 6.0
Now without further delay, my plans for the next major version of iro.js! I welcome any feedback here, especially from people that are actively using the library in their projects.
Schedule-wise I hope to begin working on this update sometime in Q1 2022, although things may happen quicker/slower depending on funding, my employment, etc.
Goals
Eyedropper API
The new JS Eyedropper API is now available in secure contexts in Chrome, Edge and Opera - I think it would be great to integrate this in iro.js!
All UI components can be resized dynamically, using only CSS
It should be much easier to adapt the color picker UI to different screen sizes, ideally without needing any JS at all so that you just add styles to your responsive CSS breakpoints. There are a few challenges here, for example any handles would need to be positioned using relative, percentage-based coordinates - but I think it should be possible!
Ring component
The only thing preventing this was figuring out how to use CSS to draw a ring that both had a gradient fill and also a hollow center showing the background underneath. But I think have a pretty good idea for accomplishing this using clip paths and a sneaky trick.
Circular saturation-brightness picker, similar to Procreate or https://paletton.com
I still need to wrap my head around the underlying math and how I'll render it using only CSS, but it's quite a nice way of presenting saturation-brightness and I haven't seen any other JS libraries that include it.
Custom sliders
This means that slider components would allow user-defined behavior for input handling, drawing gradients, moving the handle around based on the current color, etc. Ideally it would be available for all slider types (normal, circle, and the new ring ones).
Support for CSS Color Module Level 4
Or at least, some of it! I definitely want to support the new notation spec for rgband hsl, where commas and the "a" are optional. For example, hsl(0deg 100% 50%) or rgb(255 255 255 / 1) are both valid now.
In addition I'd like to add support for additional color spaces such as lab, lch, and possibly cmyk, with new slider variants for them too. I may also expose xyz since it would have to be used internally for conversion anyway.
Improved landing page and documentation
The iro.js docs are decent, but I'm not too sure if they're great. I've heard that some people still have trouble following them even though I've tried to be very careful about the flow. Perhaps I need to use more accessible wording and find a clearer way of visually presenting them. I'm happy to hear ideas here!
Additionally, it would be a smart idea to include docs for integrating iro.js into projects using React, Vue, Svelte, etc - at least if I don't get around to making native components for them.
Code organization and cleanup
Splitting off the "core" iro.js logic into a separate package (https://github.com/irojs/iro-core) was a good idea in theory, considering that I wanted to build iro.js implementations for React and Vue at one point, but it's made things more cumbersome both for me and any outsiders that want to contribute. Going forward, I think it makes sense to deprecate iro-core and move all of its logic back into one library.
I'm also better at writing code in general now, and much more familiar with Typescript, so I think I could do a good general cleanup pass on this too.
Stretch Goals
This is the part where I metaphorically shake the bucket. iro.js 6.0 is going to be cool, but if I can get funding of some kind, it could be really cool. These are some of the ideas on the table here:
- More new components:
- saturation-lightness triangle
- hue-lightness box
- color swatch grid
- color swatch ring
- Native iro.js implementations for popular libraries such as React, Vue, Svelte
- Webcomponent build, so that you can include iro.js in a project without using any JavaScript
- Support for text labels and other UI overlays
- Full UI testing using Playwright
More reference:
https://bottosson.github.io/posts/colorpicker/
I'd also like to look into better integration with color libraries like https://github.com/gka/chroma.js/, https://github.com/LeaVerou/color.js, and https://github.com/Evercoder/culori :)
As both a sponsor and maintainer of a large open source project that implements iro.js I can only say that iro.js supports everything I would ever want a color picker to do. Thank you so much for all you do ❤️
And yeah I feel you about the support thing. I don't know why people expect free support for free software. By helping you solve your problem, I helped a single user, one-off, done. I don't get anything for it. That is not reasonable if I could rather spend the same time improving the project for everyone.
Edit: Especially via mail or PM. If it's in an issue tracker or forum, my help might at least be valuable for someone else with the same problem as the person who initially contacted me.
HI James, pursuant to this discussion, something I'm looking into is Integrating HSLuv, or a version of it, into IRO. Among the advantages over HSL or HSV, is that HSLuv is more perceptually uniform, but also, there is a distinct usability advantage in that the L* control is completely independent of the S and H controls, so when L* is brought down to black at zero, the hue and saturation controls don't move, thus moving L back up from 0 the hue and sat are maintained.
There's a demo at HSLuv.org, one thing that is unique is it does a good job of determining the maximum boundaries for going back into sRGB with no clipping. A problem with out-of-the-box CIELUV and CIELAB is the gamuts are way larger than sRGB, so a practical problem is restraining to the available destination (sRGB).
@Myndex HSLuv is indeed very interesting and something I would like to add to iro.js! I think it should be possible to integrate at least as sliders, but it's components like the wheel that worry me -- implementing something like HSLuv.org's "wheel" in straight SVG / HTML doesn't seem achievable. It would be possible with the HTML5 canvas API, but that's something I really want to avoid using since it isn't congruent to my goal of a totally responsive and 100% HTML color picker.
....but it's components like the wheel that worry me -....
Hi @jaames
Yea, the wheel is probably challenging, but I don't think needed..., but there are benefits to just adapting the sliders, a big one being that when L* is brought to zero, the S and H are not also zeroed out, as they are with HSV. The second benefit is that HSLuv is much more aligned with perception, and HSV isn't.
Though there are more modern models, the interesting thing about HSLuv is the way the gamut is constrained to sRGB while in LUV space... A problem with the large perceptual models is that if you choose a color in them, it then needs to be gamut mapped down to the much smaller sRGB space. HSLuv seems to do this well except for saturated blue, which is probably due to the blue error in CIE 1931...
Just to give an update on the status of the project - it's not abandoned, but can be considered as being on a hiatus for a while.
Like many places, the UK is currently going through a cost of living crisis with energy bills in particular rising extremely sharply (over 6x what they were last year... yikes). Unlike the average tech industry worker, I am not earning very much from my day-job, so over next winter I will have to take on extra work in order to cover bills.
I will be fine, so please don't feel like you have to donate or anything! However this does mean I won't be able to dedicate as much time to open source as I would like, especially the time-consuming projects that I no longer use but a lot of people depend on - like iro.js.
Not sure when/if that situation will improve. I'm not quite ready to pass over to another maintainer as of yet, and may look into other options for funding my work on the project (sponsorware, selling commercial licenses akin to metafizzy, paid official integrations with frameworks like react/vue, etc) if people are open to something like that.