From 77e154e97cc095801e74aebee0dd413007c8aaa5 Mon Sep 17 00:00:00 2001 From: Elm UI Automation Date: Sun, 3 May 2020 10:52:58 -0400 Subject: [PATCH] adjust note about color alpha --- notes/discussion/ColorWithoutAlpha.API.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/notes/discussion/ColorWithoutAlpha.API.md b/notes/discussion/ColorWithoutAlpha.API.md index 9a4496f..0e50dfc 100644 --- a/notes/discussion/ColorWithoutAlpha.API.md +++ b/notes/discussion/ColorWithoutAlpha.API.md @@ -6,8 +6,8 @@ If we separate out alpha from the core color type, we can 1. Have a unified `Color` type that works in all contexts, including in webGL situations where transparency may be handled differently, or not at all. -2. Encourage people to use actual color mixing functions where possible or to enumerate their colors concretely. - - The point here is that alpha mixing can sometimes lead to colors that don't look great or are unexpected. +2. Encourage people to use actual color mixing functions where possible and to enumerate their colors concretely. + - The point here is that color mixing is situation dependent. Why not just mix a color explicitly in a way where you know it looks good? 3. With a totally opaque color type, we can calculate contrast for accessibility evaluation easily. An alpha channel means we'd have to emulate browser mixing to do that, which I'm not sure is consistent.