Skip to content

Support alpha in hexadecimal colors #3052

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

vmcj
Copy link
Member

@vmcj vmcj commented Aug 6, 2025

This is as a basis to detect problematic colors coming from the primary.

I can't think of any place where any consumer would ever want to display the colors with some opacity. So I wonder if it's intentional that the spec links to a document which has this.

@vmcj vmcj force-pushed the hex_shorthand_alpha branch from d0b078e to 83e8167 Compare August 6, 2025 20:25
@@ -349,6 +352,12 @@ public static function convertToColor(string $hex): ?string
*/
public static function parseHexColor(string $hex): array
{
// Ignore alpha in hexstrings
Copy link
Member

Choose a reason for hiding this comment

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

Why silently ignore the alpha channel?

Copy link
Member Author

Choose a reason for hiding this comment

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

It might indeed a bit harsh to do this silently. Do we ever think we need the alpha channel? Otherwise I think I'll add a optional boolean for this behaviour (optionally also returning rgba instead of rgb), alternative is to check all calling functions and handle this there.

Copy link
Member

Choose a reason for hiding this comment

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

It's unlikely that we need it. But I'm either for supporting it properly or not allowing it at all to avoid user confusion.

Copy link
Member Author

Choose a reason for hiding this comment

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

The spec allows for sending such a string "#ff00ffaa" so we need to store it. I think my fix already makes that we never pick it up but I'll think about this some more. Maybe just supporting it is easier in that case.

@vmcj vmcj force-pushed the hex_shorthand_alpha branch 6 times, most recently from 892068e to ebf94a2 Compare August 9, 2025 07:28
No functional change intended.
@vmcj vmcj force-pushed the hex_shorthand_alpha branch from a63d9fb to d1a8c57 Compare August 9, 2025 13:43
The Alpha is allowed by the CLICS spec but we don't really use those in
the UI normally. The only place where we have to fully ignore the alpha
is for the luminance. In that case we now by default merge it with a
white background most likely this will be the same for either background
but this was not tested.

As bonus we now also test for the shorthand (#ABC) versuse (#AABBCC).

The functions using the strings have moved from the TwigExtension to
utils as the they don't really depend on Twig itself. This makes testing
easier and can use this in the future for other elements.
@vmcj vmcj force-pushed the hex_shorthand_alpha branch from 5369d0c to f4e085c Compare August 9, 2025 14:46
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.

2 participants