- From: Brad Kemper <brad.kemper@gmail.com>
- Date: Tue, 2 Aug 2011 21:47:15 -0700
- To: Alan Gresley <alan@css-class.com>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Brian Manthos <brianman@microsoft.com>, Markus Bruch <macinfo@arcor.de>, "www-style@w3.org" <www-style@w3.org>
On Aug 2, 2011, at 7:17 PM, Alan Gresley <alan@css-class.com> wrote: > On 3/08/2011 9:51 AM, Tab Atkins Jr. wrote: >> On Tue, Aug 2, 2011 at 4:44 PM, Alan Gresley<alan@css-class.com> wrote: >>> I totally agree with Tab here regarding a 2-hexadigit variant. The expansion >>> rule is different and could be confusing to authors if any method was >>> spec'd. I'm also against having a 4-hexadigit as a shortcut for 8-hexadigit >>> (last two digits for alpha). >> >> Bwuh? Are you against an 8-digit hex variant as well, or just against >> the 4-digit variant specifically? If the latter, why? 4-digit hex is >> expanded to 8-digit hex in exactly the same way that 3-digit expands >> to 6-digit. >> >> ~TJ > > > I support an 8-digit hex with an extra two hex places for alpha (#RRGGBBAA). I believe having a shortcut for this is extra confusing an unnecessary. I disagree. I think it would be confusing and inconsistent to have a short form of #RRGGBB (#RGB) to go with the long form, and NOT have a short form of #RRGGBBAA (#RGBA) to go with the long form. I don't feel there is much need for gray(n) or #H gray. Gray(n%) would be kind of convenient and easy to learn as an alternative to hsl(), as Tab mentioned. GrayA(n%,a) wouldn't be terrible, but it feels to me like it looses a bit of the simplicity that made me like the Gray(n%) idea.
Received on Wednesday, 3 August 2011 04:47:46 UTC