Description
Problems with W3CColors
Currently W3CColors reads RGB values and names through resource files, which seems overkill if translations are not needed. This limits the performance optimization potential due to relying on archaic resource interfaces. Also the resources contain ANSI 4-bit (16) colors, which means W3CColors is technically misleading as it is not just the W3C colors anymore.
Even in case translations would be needed at some point they could be mapped by the standard/neutral name in resource files separately from the color handling.
Proposal
Replace the resource-based implementation with more lightweight alternative, e.g. enum or static fields with appropriate W3C color data.
Enum implementation prototype
To my surprise just mirroring the W3CColors methods and replacing call sites to use the new implementation that utilizes enum got ~90 % there.
There is some clunkiness with alternative color names if those need to be supported, e.g. Aqua vs Cyan, Fuchsia vs Magenta, etc. The enum names can be extracted properly but mapping RGB value back to the enum would by default select "one of the enums with matching value".
The enum
The truncated enum implementation. RGB as the numeric value so the color can be directly parsed from the enum.
/// <summary>
/// Represents the W3C color names with their RGB values.
/// </summary>
/// <remarks>
/// Based on https://www.w3schools.com/colors/color_tryit.asp page.
/// </remarks>
public enum W3cColor
{
/// <summary>
/// Alice blue RGB(240, 248, 255).
/// </summary>
AliceBlue = 0xF0F8FF,
/// <summary>
/// Antique white RGB(250, 235, 215).
/// </summary>
AntiqueWhite = 0xFAEBD7,
/// <summary>
/// Aqua RGB(0, 255, 255).
/// </summary>
Aqua = 0x00FFFF,
// snip...
/// <summary>
/// Yellow green RGB(154, 205, 50).
/// </summary>
YellowGreen = 0x9ACD32
}W3CColors replacement
The interface for new static W3CColors alternative. Uses PascalCase naming (XmlNode vs XMLNode) in case the original W3CColors should be preserved and marked as deprecated. Also probably could use more distinguishable name from both W3CColors and the W3cColor enum.
/// <summary>
/// Helper class for transforming to and from <see cref="W3cColor"/> enum.
/// </summary>
public static class W3cColors
{
/// <summary>
/// Gets read-only list of the W3C colors in alphabetical order.
/// </summary>
public static IReadOnlyList<string> GetColorNames () // ...
/// <summary>
/// Tries to parse W3C color from the given name.
/// </summary>
/// <param name="name"></param>
/// <param name="color">Contains the successfully parsed <see cref="W3cColor"/> value.</param>
/// <returns>True if parsed successfully; otherwise false.</returns>
public static bool TryParseColor (string name, out Color color) // ...
// TODO: Add out parameter for alternative names to TryNameColor to solve the issue with multiple enums with same numeric values?
/// <summary>
/// Tries to match the given color RGB value to a W3C color and returns the name.
/// </summary>
/// <param name="color">Color to match W3C RGB value.</param>
/// <param name="name">Contains name of matching W3C color.</param>
/// <returns>True if match; otherwise false.</returns>
public static bool TryNameColor (Color color, out string? name) // ...
}The ANSI 4-bit colors would be handled separately. They could have similar helper class and then call that in ColorJsonConverter and Color.Format to restore feature parity.