- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 25 Jan 2016 15:48:54 -0800
- To: Xidorn Quan <quanxunzhen@gmail.com>
- Cc: Rik Cabanier <cabanier@gmail.com>, Simon Fraser <smfr@me.com>, Mark Straver <mark@wolfbeast.com>, www-style list <www-style@w3.org>
On Mon, Jan 25, 2016 at 3:29 PM, Xidorn Quan <quanxunzhen@gmail.com> wrote: > On Tue, Jan 26, 2016 at 6:22 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: >> On Mon, Jan 25, 2016 at 11:17 AM, Rik Cabanier <cabanier@gmail.com> wrote: >>> On Mon, Jan 25, 2016 at 10:58 AM, Tab Atkins Jr. <jackalmage@gmail.com> >>> wrote: >>>> On Mon, Jan 25, 2016 at 10:53 AM, Rik Cabanier <cabanier@gmail.com> wrote: >>>> > Are you worried about the computed value of the 'transparent' keyword in >>>> > the >>>> > gradient? If so, that one doesn't resolve to an rgba color. >>>> >>>> Sure it does. (Or it should be doing so, for consistency - colors >>>> should be computed in computed values.) >>> >>> It does not. I tried Edge, Safari 9, latest Chrome and Firefox. >> >> Then that's a bug, either in the specs or the implementations. There >> is absolutely no reason a color should serialize differently based on >> whether it's bare or wrapped in a gradient function. > > Given all impls current agree with the same behavior here, I guess we > can probably make 'transparent' a keyword value in gradient function > to simulate premultiplied effect, and revert the general cases to > non-premultiplied... If and only if there's not a significant number of gradients out there that currently write out transparent with rgba() syntax, or that use near-transparent colors that'll significant change behavior here. And we (Blink) must store the input string somewhere so we can output it back literally, because I *know* that we parse that into an #AARRGGBB 4-byte int and operate on it like that. So it doesn't matter whether you type "transparent" or "rgba(0,0,0,0)", you get 0x00000000 either way. ~TJ
Received on Monday, 25 January 2016 23:49:41 UTC