Beta Testing of new ColorHelper of 3.0

[facelessuser]

Feel free to try out the current beta and discuss, give feedback,etc.

Instructions

https://facelessuser.github.io/ColorHelper/installation/#install-3.0-beta

Let me know if you run into hiccups or something doesn't work.

Planned Changes

• Underlying color object should return a new color instance when applying "fit".
• Some underlying object methods should have an "in place" option to modify the current color. "fit" and "mix" are good candidates for this.
• Clean up and settings for specific file types. Need to set good defaults for them and verify they all still work and/or improve them if they are broken.
• Minor code cleanup. Particularly in the area of managing the panels.
• Decide if we want to add any more color spaces.
• Are there any other custom color classes we should implement now? Or leave that up to the user to create there own?
• Update documentation.
• Possibly make a beta release and advertise on Sublime forum to get more testing.
• Get color dependency on package control.
• Handle color functions that specify fallback colors: color(display-p3 0 1 0, rgb(0 100 0)). Looks like this is getting dropped from CSS spec 🎊.
• ColorHelper is meant to find instances of single colors. But some fallbacks are only valid when they are inside a color function. How do we handle those? In this case (color(display-p3 0 1 0, 0 1 0)) the fallback is assumed to be srgb, but we can't just add a pattern to find random numbers and treat them as colors. The underlying library that handles color is meant to define and manipulate single colors, not to return an array of colors for a single color instance. Basically, we need to decide if we are just going to ignore such instances or provide more complexity to find such colors. Looks like this is getting dropped from CSS spec 🎊.
• Look into premultiplied mixing of transparent colors.
• Look into phantom issues on ST3.

Changes (so far)

3.0.0

• NEW: New supported color spaces: lch, lab, display-p3, rec-2020, xyz,
  prophoto-rgb, a98-rgb, and hsv.
• NEW: rgb, hsl, and hwb all support the new CSS format rgb(r g b / a).
• NEW: All instances of blacklist and whitelist are now known as blocklist
  and allowlist respectively.
• NEW: Outputs when inserting or converting can be controlled in settings file.
• NEW: Color triggers (what color helper searches for before testing if the text
  is a color) can be configured in settings file. This can allow a user to not trigger
  on certain formats.
• NEW: If desired, users can provided a custom color class object to use for certain
  files that can augment one or more supported color space's accepted input and output
  formats.
• NEW: Improvements to scanning. Scanning will only occur in the viewable viewport.
  Text that is not visible, both vertically or horizontally, will not be scanned until
  it scrolls into view.
• NEW: New option preview_on_select to show color previews only when the cursor is
  on the color or selecting the color (currently only applied to one selection).
• NEW: New color edit tool which allows a user to get a live update of the color as
  they alter the coordinates, and allows the user to mix it with one other color. The
  result can be inserted back into the file, or will be handed back to the color picker
  if called from there.
• NEW: New color contrast tool which allows a user to see the contrast ration and
  see a visual representation of how the two colors contrast. The resulting foreground
  color can be inserted back into the file, or will be handed back to the color picker
  if called from there.
• NEW: Only one color rule (defined in the settings file) will apply to a given view.
• NEW: Renamed color_scan option to color_rule.
• NEW: Colors that our out of gamut will be gamut mapped. On over of the preivew
  (on ST4) it will indicate that it has been gamut mapped. This can be disabled via
  show_out_of_gamut_preview, and instead a fully transparent color swatch with a
  "red-ish" border will be shown (color may vary based on color scheme). On mouse over
  it will indicate that it is out of gamut (on ST4).
• NEW: Sometimes when dealing with an out of gamut color, due to needing to work in
  a certain color space (contrast tool and color picker only apply spaces easily
  translated to sRGB), ColorHelper will have to gamut map a color. Two forms of gamut
  mapping are provided lch-chroma and clip. preferred_gamut_mapping controlls
  which method is preferred with lch-chroma being the default.
• NEW: ColorHelper will now gamut map colors in some scenarios, either due to
  necessity, or by user setting.
• NEW: New generic option is defined which provides a default input and output for
  files with no rules. Users can use the color picker, and other color tools, from any
  file now. Scanning is disabled by default and can be enabled if desired. generic can
  be tweaked to provide whatever fallback experience the user desired.
• NEW: New command added to force scanning in a file that may have scanning disabled.
  Also can force a file with scanning enabled to be disabled.
• NEW: Color helper will now recognize transparent.
• NEW: Color picker rainbow box will adjust based on the saturation of the currently,
  selected color.
• NEW: Color picker will give a clear indication when you are at the end of a color
  channel.
• NEW: Provide user_color_rules where user can append rules without overwriting the
  entire rule set. If a rule uses the same name as one of the existing default rules,
  a shallow merge will be done so the values of the top level keys will be overridden
  with the user keys and/or any additional keys will be added.
• NEW: Smoother behavior of color previews when editing code.
• REMOVED: Color completion. It mainly got in the way. The palette can be called any
  time the user needs it already.
• REMOVED: Hex shaped color picker option has been removed.
• REMOVED: Removed "current file palette". ColorHelper will no longer scan the entire
  current file and generate a palette. This only worked in a limited number of files and
  added much more complexity.
• REMOVED: Various options from rules sets. These are now controlled by the color
  class object that is being used. For instance, input and output format of colors in the
  form #AARRGGBB instead of the default #RRGGBBAA would need need to use the new
  example ColorHelper.custom.ahex.ColorAhex custom color object to read in and output
  hex colors with leading alpha channels.
• FIX: Insert logic issues.
• FIX: ColorPicker now will always work in the color space of the current mode.

[facelessuser]

Need to add a discussion label or a beta label 🤔 .

[michaelblyons]

You know you can tag a beta release with semver pre-release conventions, and only people with your package name in the "install_prereleases": [...] of Package Control.sublime-settings will download it.

The one "gotcha" is if you are planning to make >10 pre-releases in a row. See wbond/packagecontrol.io#99

There may also be something funky with dependencies. I just haven't work enough with them to know.

[facelessuser]

Yeah, the new color library dependency is not yet ready (close, but not yet) and not added to package control. I just wanted initial feedback. It I get a lot of action, I may create a beta release. If I don't, I'll finish it up quietly, ship it and then see what kind of complaints I get.

[facelessuser]

Now that I have Sublime min-contrast() working, added the ability to specify a minimum contrast in the contrast tool.

[facelessuser]

Some min-contrast fixes got pushed. Mainly for handling extreme cases (when contrast cannot be achieved etc.). It seems the way the algorithm works, if the ratio is impossible for the given color to reach, it turns into white. That's simply because whether we mix black or white is dependent on whether our luminance is less than or greater than the calculated required luminance. In extreme cases, this seems to always turn into white, even if the black yields the best contrast. Once the limits of that color's luminance range are met, the algorithm will yield white. Regardless, that is just the way it is and I'm fine with it as it seems to match Sublime.

[facelessuser]

Updated opening post with planned things. Right now, unless I get feedback for any more new things, or I happen to come up with something, I'm going to work on polishing and getting the color dependency on finished up and on Package Control. So nothing in the list is of any real note. The dependency changes may require users of the beta branch to update the dependency when I get that work done, but other than that, there should be no real big changes.

Once the dependency is live, we can consider a public beta. I may advertise it on the Sublime Forum as I really am interested if anything I axed affects anyone, or if there are ways to improve this I haven't thought about.

I'm not really sure how everyone uses it or what they want to get out of the tool. I know there are things I'm simply not willing to support, such as color variables as those can be external to the current file, found all over the current file, and indexing all of that and adding knowledge for how to find that info (in all of its file specific formats) is something I'm just not interested in. That kind of thing is better suited for LSP servers.

[facelessuser]

One limitation that still exists is the fact that you can only use one color class type per view.

This means if the color class you have loaded for a given view recognizes colors one way, an embedded language that recognizes colors differently and needs a different color class won't work.

Sublime tmThemes are an example of this. In the main part of these files, it recognizes sRGB colors with color names defined in X11, but in regions such as popup CSS, it uses web color names. If you just use one color class in the file, in some places you'll get bad color previews.

Now there is no syntax I know of that'll provide a different scope we could trigger off of for tmThemes, but it is just an example.

Now, I can't promise I'll allow multiple color classes in one view, but I think we could clean things up a little and have color rules reference a color class profile that could be reused in multiple rules. Theoretically, we could allow a rule to specify multiple combinations of scopes and color classes, and depending on the point where the color is found, it could qualify to be used with one color vs another. If we don't do some refactoring, this will never be possible, so it is probably worth doing the refactor now and evaluate.

[facelessuser]

Updates have been made to both the plugin and the underlying color library. To upgrade to the latest beta, one must fetch the latest coloraide dependency, and fetch the latest plugin on the feature/next branch.

At this point, I think I'm going to run the plugin through some testing and probably start looking towards maybe a public beta. I think everything is in place now. I think I've refactored enough now as well. Maybe I'll do some more in the future, but I need a break 🙂.

[facelessuser]

Got some round trip conversion tests into coloraide to shake out the rest of the conversion bugs. We had a few more that were overlooked in some of the less tested color spaces. I'm now pretty confident in the color space conversions. They seem to match our reference implementation and now we are ensuring round trip conversions are good. Coloraide 0.1.2 is recommended to get all the color conversion fixes.

I went through and made sure proper dialogs pop up when doing cancels via escape or using the back links on the dialogs. Cleaned up some passing around of colors between dialogs and such. Hopefully there are no regressions due to any of the changes.

---

Just an FYI, precision will affect whether some colors read as in or out of gamut when it comes to color previews. It's impractical to print out full precision (I guess technically we adjust precision and scale).

We can see here that when using full precision, our conversion still has our LCH value in the "srgb" gamut. But when we output the string (which uses a default precision/scale of 5) and read it back in (much like what you get when converting in your document with ColorHelper), we see that the color reads as out of the "srgb" gamut, which we use to preview the color.

>>> c = Color("blue").convert("lch")
>>> c.coords()
[29.567582570569506, 131.20704008299427, 301.36852485669147]
>>> c.in_gamut("srgb")
True
>>> c = Color(Color("blue").convert("lch").to_string())
>>> c.coords()
[29.568, 131.21, 301.37]
>>> c.in_gamut("srgb")
False

So if you are converting between color spaces such as LCH and SRGB, you will find that previews may warn that they are slightly out of gamut. If you convert back, the colors are "fit' to their own gamut by default, so it will usually convert back reasonably.

This is just the nature of the colors and the color spaces. The only way to avoid such things is to always be working in full precision, but nobody wants to insert long ridiculous colors 🙂.

[facelessuser]

rec-2020 will now be known as rec2020 to match the latest editor's draft and to match the reference implementation.

I'm considering bumping default precision up to 6 to account for most gamut translation issues. Granted, the user can set the output to whatever they want, but maybe 6 is a good default.

[facelessuser]

Reduced some troublesome cases when scanning. For instance, We shouldn't treat { as hex. We shouldn't treat -red as red, stuff like that.

[facelessuser]

Been writing docs, but got held up as I've been considering some cases in the color library. I've kind of been playing with the idea of implementing an interpolator which we can use for mixing or for interpolating colors between two colors. This is also causing me to (re)consider how I am handling null hues (hues associated with achromatic colors).

Currently, we handle this on the fly, and when doing certain operations, we do an achromatic color check and treat the hue as null during certain operations. We basically trigger on achromatic or very, very near achromatic to handle slight differences when converting between color spaces.

May libraries handle this a little different, and some times a little different from each other as well. A common similarity is that they use NaN for a hue that is null. That means we have to carry around NaN everywhere and add logic everywhere to make sure you treat it has zero in cases where you don't need to treat it as null. In our case, it seems just doing an achromatic check on the fly when we need to may fulfill the same role and be easier for users to work around.

With that said, often you are allowed to inject nulls in other channels as well which can allow you to hold a channel constant during a mix if one channel has a NaN and the other does not.

One reference we looked at seems to always be updating the hue if the color every looks achromatic. Another accepts whatever you manually give it, but on coverts, you may end up with NaNs. I find the latter a little more confusing, but I also kind of understand that they are trying to respect whether a user inserts a NaN or omits NaN.

Now ColorHelper doesn't read in NaNs currently as they aren't (at least not anywhere in the current spec) specified as a thing you can specify, but maybe it would be useful in the color mixing tool.

Anyways, I've been a little hung up here as often when you are writing documentation, you consider things a little more as you try to describe it. Once I figure out how I want to move forward, I should be able to pick up steam again.

[facelessuser]

Some more changes were made. Walked back the option to set the gamut mapping method. We will use the default (which is honestly superior to clipping, but there are still some times that clipping is useful). If it is desired to use some other gamut mapping method, one would need to override the class and provide a custom class.

We are interpolating our colors based on the color-mix spec mentioned here (except for the channel-specific adjusters to mix just single channels). This may be available in the future, but not currently. The reason I mention this is that when a color with a larger color space is requested to be mixed in a smaller color space, it is gamut mapped to the smaller space based on the spec.

We also use gamut mapping when outputting the CSS string form by default. This can be disabled if desired in most cases except when outputting hex as hex has clear constraints.

Conversion can optionally fit a color during conversion.

So, by default, all these methods now use whatever is the default for the color class, except for the fit method which does the actual fitting. This is to allow a user to manually fit before doing an operation if they absolutely need to 'clip' instead.

None of this matters too much to ColorHelper as the user doesn't have access to most of this. They can adjust string output though, but now they can simply turn off or on mapping on string output. If they want to control gamut mapping, they'll have to provide a custom color class instead.

This helps clean up some handling. Now we don't constantly have to check the user's preference, we just use the, frankly, better mapping method.

The class exposes the gamut mapping methods for a number of functions but doesn't currently expose a way to control it specifically. It just gets more convoluted as anything we have that calls such functions then also has to expose the methods and becomes kind of a mess. So, I've decided to make it a class variable. If one were to override the class and set it to some other supported gamut mapping method.

---

Currently, I'm not going to introduce NaNs globally through the code yet. We still apply an achromatic check on certain operations and will avoid mixing a hue in cases where we feel the color is achromatic.

We could use NaNs, as some libraries do` to map off channels we wish to not mix etc. Or we could just provide a way to mix specific channels, or specify specific channels to mix in current methods. That is something we can decide later in the color lib, but not necessarily needed to get ColorHelper out the door.

---

Both the latest coloraide lib and ColorHelper are available.

[facelessuser]

Finally got the ColorAide documentation: https://facelessuser.github.io/coloraide/. It's not fully complete, but enough that it can be used as a reference for output string options and such.

With that in place. I can finish up ColorHelper documentation in preparation for the public beta.

[facelessuser]

The latest docs are done. Time to look into pre-releases on Package Control. Unfortunately, coloraide is not yet on Package Control. Maybe we'll have to vendor it to get the beta out...

[facelessuser]

Code changes are now on the main branch. As soon as Package Control gets our dependency merged, we can pull the trigger on an official beta release through Package Control, unfortunately, my hands our tied until that happens. I don't want to change them all the references to a vendored version just to change them all again when the dependency is available.

Now we wait 🤷

[facelessuser]

https://facelessuser.github.io/ColorHelper/installation/#install-3.0-beta

You have to use the channel repo file mentioned in the docs to get the dependency, but it works. Once the dependency is available in PC officially, the repo file can be removed from Package Control settings.

[mickimnet]

Hello Isaac (@facelessuser),

I'm currently trying out the 3.0-beta in Sublime Text Version 3.2.2., Build 3211. I did the installation via Packagecontrol.io as requested on the #install-3.0-beta section. I do mainly color schemes & themes for different stuff.

I love to see the colors in Sublime Text while I work on the configurations. I keep track of all my used colors in a .markdown file and edit .toml, .bash and .fish files--besides the .sublime-color-scheme.

I did get the plugin to work with .toml, .bash and .fish, but not with .markdown. That worked in the previous ColorHelper version (2.7.0). I enabled debug, but I don't get any output in the console.

How can I help figure out why it is not working?

Thanks and take care
Mick

[facelessuser]

@mickimnet is this because you had a custom rule that no longer highlights colors in Markdown? Or that an old rule incidentally used to highlight colors and Markdown and no longer does due to the reworking of rules? I imagine it is the latter.

[facelessuser]

@mickimnet I'm not seeing an issue with Markdown. I would need more information.

• Are you using a Markdown syntax other than the default? And if so, which one?

As you can see, colors are working Markdown for me:

[mickimnet]

Hello @facelessuser,

sorry, I could have provided more information and explanations. My bad 😞

Let me reiterate:

I'm not talking about inline code blocks in Markdown--I replicated the code snippet from your screenshot and it works with my settings--, I'm referring to plain Markdown content, like:

|                          |               |               Color value                |||
|           Name           |     Color     |          HSL           |    HEX    | Shell |
| -----------------------: | :-----------: | :--------------------- | :-------: | :---: |
|          myth_foreground |    Whiteish   | hsl(0, 0%, 93%)        |  #EEEEEE  |  253  |
|          myth_background |    Blackish   | hsl(0, 0%, 7%)         |  #111111  |  233  |
|          myth_find_hl_bg |      Sand     | hsl(47, 100%, 79%)     |  #FFE792  |  222  |
|            myth_comments |      Grey     | hsl(290, 3%, 43%)      |  #6F6A70  |   59  |
|                myth_main |     Orange    | hsl(38, 100%, 50%)     |  #FFA200  |  214  |

My current settings for the ColorHelper beta v3.0 -- I'm using MarkdownEditing for the syntax definitions (with the GFM part):

        {
            "name": "Markdown",
            "syntax_files": [],
            "extensions": [".markdown"],
            "base_scopes": [ "text.html.markdown", "text.html.markdown.gfm" ],
            "color_class": "css-level-4",
            "scanning": [
                "meta.paragraph.markdown",
            ],
        }

My point is, that above Markdown section was highlighted with the current v2 version of ColorHelper, with the same syntax package and the following settings:

        {
            "syntax_files": [],
            "syntax_filter": "whitelist",
            "base_scopes": ["text.html.markdown"],
            "scan_scopes": [
                "meta.paragraph.markdown",
            ],
            "allowed_colors": ["hex", "hex_compressed", "hexa", "hexa_compressed", "rgb", "rgba", "hsl", "hsla", "gray", "graya", "hwb", "hwba"],
            "extensions": [".markdown"],
            "use_hex_argb": false,
            "compress_hex_output": true
        }

Hope that makes it more clear and helps.

Thank you and take care!
Mick

[facelessuser]

So, things changed in regards to rules. I believe before, ColorHelper allowed multiple config rules to stack, that is no longer the case with ColorHelper 3.0. So, what is happening in your case is that the HTML rule is getting selected instead of your Markdown one, that is because the HTML rule only checks if the first character in the view has the desired base scope. You can change that to look for syntax file's instead or other various things. In the example below, I just override the HTML rule to exclude your Markdown scope:

    "user_color_rules": [
        {
            "name": "Markdown",
            "syntax_files": [],
            "extensions": [],
            "base_scopes": ["text.html.markdown", "text.html.markdown.gfm"],
            "color_class": "css-level-4",
            "scanning": [
                "meta.paragraph.markdown",
            ],
        },
        {
            "name": "HTML/CSS",
            "base_scopes": [
                "source.css",
                "text.html -text.html.markdown"
            ]
        }
    ]

[mickimnet]

Oh! I didn' t knew that. Thank you very, very much. It works now!

[mickimnet]

Hello @facelessuser,

I found another issue, I cannot quite put my finger on it:

Sometimes (it happens regularly, but I didn't found a pattern so far), the display of the colors doesn't work for the head of the file. See:

Most of the times it happens, if the content is smaller than the viewport of the file. The colors get drawn/displayed, if I'm able to scroll the viewport (either horizontally or vertically).

Can I provide further information?

Take care,
Mick

[facelessuser]

@mickimnet

• so the view needs to have no scrollbars or can it happen even if there is a scrollbar?
• Do the colors update if you edit something?
• What OS are you on?

[mickimnet]

@facelessuser

1. I can happen even if the view has a scrollbar, but only for the first 10-20 lines (and the color boxes are drawn as soon as I move the code out of the view and back in)
2. No, only if I scroll--either horizontally or vertically
3. macOS Catalina 10.15.7

I just open two files, with the following results (the screenshots include the viewport--missing non existing lines, the tab bar and the status line):

As far as I can tell it isn't related to the type/scope of the file.

[facelessuser]

Are you using hardware acceleration? Does it work better (after a restart) when you modify that setting in the Sublime preference file?

Is this ST3 or ST4?

[facelessuser]

Updated opening post with more tasks to look into.

[mickimnet]

Hello @facelessuser,

I've to admit, that I'm a bit lost at the new configuration options. Today, I updated my Sublime Color Scheme with geometrical based colors (small adjustment, big improvement) and was trying to get the colors displayed in the .sublime-color-scheme JSON format, to no avail. :(

I'm back on Sublime Text Version 3.2.2., Build 3211 and am using the following configuration option:

    "user_color_rules": [
        {
            // Sublime Color Schemes (based on Sublime Default)
            "name": "Sublime Color Schemes",
            "syntax_files": [ ".sublime-color-scheme" ],
            "base_scopes": [ "source.json" ],
            "color_class": "sublime-colormod",
            // "color_class": "css-level-4",
            "scanning": [
                "string.quoted.double",
            ],
        },

I tried also with-out the following (switched one of at a time):

• "syntax_files":
• "base_scopes": [ "source.json" ]
• "scanning":

Thanks and take care
Mick

[facelessuser]

@mickimnet

"syntax_files": [ ".sublime-color-scheme" ],

syntax_files wants the syntax file used, not the extension. There is an extensions option if you want to specify extensions. TBH, I should probably remove extensions though. Extensions are used to trigger a syntax file, it makes far more sense for ColorHelper to trigger off syntax files being used as opposed to an extension as ColorHelper won't trigger on an unsaved buffer as the buffer won't have an extension.

ColorHelper supports Sublime Color Schemes out of the box already if you are using the PackageDev plugin. I personally recommend that as it has better scoping which makes it easier for us not to highlight false positives.

We provide a rule for PackageDev in the default setttings, This will handle color-mod functions too: color() (though the above picture doesn't show this simply because those color functions are using variables).

        {
            "name": "PackageDev Sublime Schemes/Theme",
            "syntax_files": [
                "PackageDev/Package/Sublime Text Color Scheme/Sublime Text Color Scheme",
                "PackageDev/Package/Sublime Text Theme/Sublime Text Theme"
            ],
            "color_class": "sublime-colormod",
            "color_trigger": "(?i)(?:\\b(?<![-#&])(?:color|hsla?|hwb|rgba?)\\(|\\b(?<![-#&])[\\w]{3,}(?!\\()\\b|(?!<&)\\#)",
            "scanning": [
                "source.css-color -meta.function-call.var.sublime-color-scheme",
                "meta.css.sublime-color-scheme meta.property-value.css -comment -string.quoted.single.css -string.quoted.double.css"
            ]
        },

[mickimnet]

🤦🏻 Sorry, I'm dumb. Thank you very much! I thought I had "extension" in it and not "syntax_files". Sorry again. Will check out PackageDev later.

[facelessuser]

Be aware that I may remove the extension setting as it really isn't a practical way to specify the view for ColorHelper. Really, syntax should be used instead which is often set by the extension. So indirectly you end up triggering off of the extension.

[mickimnet]

Good to know. Will change the settings. Thank you very much! If you need further testing on Sublime Text 3, please let me know. Happy to help.

[facelessuser]

Sure. I haven't tested ST3 too well except as a sanity check. It's good to know though that I need a bit more testing there.

[facelessuser]

Coloraide has been available on Package Control for a while. Looking to update it very soon to handle the color form when multiple color options are provided color(<some color>, <some fallback>). We'll basically just need to target <some color> as the color for the whole function.

One thing to note is previously the spec allowed sRGB colors to omit the color space when using the color() form, but now they require it, which makes me very happy. I may be able to target each color in a color function individually as well so you can change the single color inside the function, or the whole function (though the whole function may forget all the fallbacks, but maybe in the future I can solve that too).

[facelessuser]

New beta.02 is out.

• Some fixes for PackageDev.
• Dropped gray() as it has been removed from the level 4 CSS color spec.
• Fixes to the underlying color lib (may need to run "Satisfy Dependencies" from your command palette).
• Tweaked event timing logic.
• Fix 0xahex color class.

Still more things to do before a stable release 🙂.

[facelessuser]

Sounds like the CSS people are thinking about dropping fallbacks for colors. This means it is looking like I shouldn't waste time on that 🙂.

This greatly simplifies what I had in the pipes. So, I think this means I can focus on looking into any polish needed on ST3 (I'd like to have it work as well as it does on ST4).

The only other thing on my list is probably simplifying the conversion logic in Coloraide. I know that the package, from which Coloraide takes inspiration, mainly uses XYZ as the common path for most of the conversions. We do the same, but they also seem to have a way where each color class has color-specific conversions to get them to XYZ, and the library just finds the best path. I'd like to do something similar if possible to help reduce some of the logic in the conversion part.

[facelessuser]

Beta 3 is out with a number of bug fixes. Fixes down in the coloraide dependency and in the actual plugin.

[facelessuser]

A couple of things I plan on addressing in beta 04 is fixing some of the mixing logic. Apparently, we are not quite following the mix logic in CSS level 5 in regards to handling the multiple percentages.

When adding the two percentages together, if they do not meet 100%, we need to set p1 = p1/p1 + p2 and p2 = p2/p1 + p2..

Additionally, we should not clamp percentages between [0,100]. With that said, they are still working out specifics of how to handle negative percentages, so we may clamp negative percentages to 0 for now.

What this means is that you could technically mix a color with 110% in the future. Now, mixing beyond the range of [0,100] may not get you what you want, but it should be possible.

Some are arguing that percentages greater than 100 should also be clamped. If that decision is made, we will do the same here. Regardless, there is an open issue discussing this at the CSS working group, and I am waiting to see how that discussion goes.

---

We are also working on premultiplied transparent colors as well. I'm not sure if this will be the default in mixing or not, but it appears to be the way color level 5 is going. While support may soon be in the underlying library, we may wait to expose such behavior.

[facelessuser]

Our mix logic better matches latest draft of color-mix. The logic that is, not syntax. The syntax actually seems much more simple in later drafts:

color-mix(in lch, red 40%, blue)

Adjuster logic is moved to color-adjuster() which I haven't touched yet, and definitely not needed right now.

So, after reading the color-mix spec, there are two cases that I'm not exactly sure how to handle:

color-mix(in lch, red 0%, blue 30%)
color-mix(in lch, red 0%, blue 0%)

With a case like:

color-mix(in lch, red 0%, blue)

You would assume to use blue and just convert it. But with color-mix(in lch, red 0%, blue 30%), do you do the same? Do you mix it at 30% with black 🤷. I'm assuming the former, but I don't really know.

When given something like below, you assume both are mixed at 50% because nothing is specified.

color-mix(in lch, red, blue)

But with

color-mix(in lch, red 0%, blue 0%)

Do you do the same? Because both colors have zero, so you shouldn't use either, but since they are excluded, and you have to return something, do you just assume the percent's as undefined and return them mixed at 50%? Or do you return something like an opaque black? We are going to assume 50%, but I'm not sure if that is correct.

[facelessuser]

Just to reiterate, while we are modeling logic after color-mix logic, we are still keeping the syntax:

color percent + color percent @space

Could we change in the future to the following?

in space, color percent, color percent

Sure, but we haven't. I'm not even sure whether the CSS spec knows what they are settling on, but currently that is kind of what they are doing, except they also allow percent and color in any order, so this is also valid:

in space, percent color, color percent

I'm not quite sure why they have to be so loose with their syntax 🤷 .

[facelessuser]

I'm convinced the CSS working group doesn't know what they want yet. I was digging into conversations and such in their issues. We ended up sticking with roughly what we had before except it won't clamp 100. If totals exceed 100%, the values are scaled.

There is no decision on what to do when the total is less than 100%, so we scale until we know better.

There is no decision on what to do when the percentage is negative, so we clamp anything less than zero.

That is what we'll stick to until at some future time the CSSWG decides what to do.

[facelessuser]

This might very well be the last beta, but Beta 04 is out. Also, run Satisfy Depedencies just in case Sublime doesn't update coloraide.

• Fixes a contrast tool regression
• Adds premultiplied alpha when mixing colors in the edit tool
• Edit tool will now allow you to do color @colorspace so you can quickly see what a value converts to in another space. The mix is also output in the specified @colorspace.

I ended up basically setting mix logic back to the way it was. I don't know if the CSS WG will have a decision on mixing by time I get an official release out, but I've noted in the docs that there are still some incomplete things in the algorithm due to the CSS WG still working it out. They mention they may figure it out by next week, but 🤷.

I've tested it in ST3 and ST4. I think the underlying color lib is good enough at this time. I'm pretty excited about getting 3.0 out the door. Hopefully, people like the new version as much as I do. I think it is now in a state I can maintain without dreading to work on it. Color support is much, much better, supporting colors of the future.

I appreciate the feedback I've gotten in the time I've been running the beta. Unless I run into bugs, I only expect maybe some minor changes, if any, between now and the final release. Maybe the mixing algorithm 🤞, and maybe subtle changes to some of the popup panels, but maybe not.

[facelessuser]

I may just make the color mixer take one percentage. Instead of trying to mimic the color-mix syntax (which may change), we can just implement it in such a way that holds true to the method, but not to the syntax. The interpolation/extrapolation in the positive and negative direction is actually easy and doesn't change no matter how the resolve the two percentages. In all actuality, it is the very fact that they are using two percentages that make this difficult.

In reality, color-mix takes the two percentages and resolves them such that you have one percentage that applies to the secondary color. They phrase it that the two percentages have to add up to 100%, but things get messy when you are trying to resolve -50% and 130%. The color spec guys want to extrapolate in the negative direction as there are valid use cases, but if you have two percentages, and you don't bound their relation, or if you bound them to 0 - 100, but still have to handle values that exceed this in both directions, how do you scale that to get your one percentage?

By only requiring one percentage, you take out all of this nonsense, and can just pass the percentage directly to the interpolation algorithm. Problem solved.

[facelessuser]

I actually understand the current algorithm for mixing now. It does work for negatives and everything...except if you two percentages that sum to zero. Then you get a divide by zero. So I understand what they meant to do, they just didn't think about the corner case of p1 + p2 = 0. I've pointed out the flaw and we'll see what they say.

While I originally misunderstood the normalizing of the percentages, my original statement of using one percentage instead still holds true.

[facelessuser]

So I did end up releasing a Beta 05 with the correct algorithm for mixing percentage resolution. It all works as stated in the spec now, but it does have an issue p1 + p2 = 0. This causes a divide by zero, and gives us an undefined state. For now, this will not mix anything.

I do see why they did what they did. This way, you can attach a percentage to the color you want, and that part is intuitive. Attaching a percentage to both colors is a little less intuitive if the values do not sum to 100%, but they handle it by normalizing the values, treating them as weights on each color, which is fine. It works out and the mixing becomes extrapolation instead of interpolation. Again, not an issue, but maybe surprising if you are thinking about color mixing as mixing paint.

You can see the algorithm here at work. It's really not complicated: https://codepen.io/facelessuser/pen/eYBLWjd.

Really, if they keep things the way it is, they just need to mention what to do when p1 + p2= 0.

[facelessuser]

Wasn't planning on it but while going over the coloraide lib, and thinking about trying to finalize the API and such, I decided to go back on a decision I made early on and have reintroduced NaNs back into colors for null hues. People using libraries like this are used to this behavior, and since the CSS spec mentions it, I added it back. This means I had to update ColorHelper to account for and check for these cases. This just gives more people power when using coloraide as they can also mask off channels with NaN for interpolation, something that ColorHelper won't see.

The only way this noticeably affects ColorHelper is that when using the color picker with HSL or HWB colors, when saturation is 0 in HSL or W + B >= 100 in HWB, you can't change the hue, and it always shows as zero. This makes sense as Hue is now null, and we just use zero on string output. Before, we were calculating null hue on the fly, so we were able to keep the input value. Now, just due to how things serialize and come back to the popup, this is just how it is going to be. I don't feel like working around this. If people really complain, I can probably output the colors with a visible NaN to show what is happening.

So Beta 06 basically has the following:

• Add support for latest ColorAide (make sure to update). Beta 06 ensures ColorHelper accounts for null hues. It also makes sure ColorHelper supports some API changes.
• A small minimum contrast bug fix.

I'm not touching the ColorAide lib anymore before the final release, and I'm not touching ColorHelper. Unless a bug surfaces in Beta 06, this is probably the release candidate.

I don't expect the CSSWG to address my current confusion next week, but if they do, whatever the resolution is, I'll ensure it is in the final release.

[facelessuser]

I think I plan on making the final release on Friday next week, with any reported bugs fixed. There would have to be something major to keep me from pulling the trigger.

[facelessuser]

ColorAide dependency is now at 0.1.0a6. A number of fixes. Just run Satisfy Dependencies to pick it up if PC doesn't do it for you.

On a side note, the CSSWG, while not committing to yet to the current percent algorithm, at least acknowledge they need to define p1 + p2 = 0 if they stick with the current plan. They have not yet said what that case should return, only that they need to define it.

[facelessuser]

Looks like we had an issue parsing compressed hex values with alpha in, but not on output. Basically, we were taking things like #1238 and parsing it as #11223308 which is wrong.

The dependency was updated to 0.1.0a7 to fix this issue. No changes to ColorHelper itself.

[facelessuser]

We are poised for release! I've spent the last number of days (when I had a chance) getting things as stable as possible. There will be a few bug fixes in the next release, which will be the final 3.0 release.

• Had a small bug when reading a ST color-mod blend when the space was specified as hsl.
• Small issue with color panel rendering with some related panels in the color picker.

All of these will be fixed tomorrow.

We'll see how the greater audience responds. I'm expecting some flack on why certain things were removed, but that is the price of me moving forward with this project. Some buggy things had to go.

[facelessuser]

Went ahead and tagged the release. It should be available in the next couple of hours. Now we get to see what people think outside of the beta test group.