Re: [css3-color] #rrggbbaa annotation

seems like if you expect to have colo(u)rs change, or more particularly you find the same constant several times in your code, you want to define your own named colo(u)rs, and then change one definition...(or use a variable, or something, waffle waffle...)


On Mar 26, 2010, at 11:32 , Tab Atkins Jr. wrote:

> On Thu, Mar 25, 2010 at 6:01 PM, Alberto Lepe <dev@alepe.com> wrote:
>> If I want to do a massive change of color from #56726C to #88936C,
>> replacing #HEX annotation its very easy, while replacing rgba() it is
>> more difficult as it may have differences in spaces like
>> rgba(86,114,108,0.5); and it would be necessary to convert #HEX values
>> to rgb() values in order to match the same color. If there could be a
>> #rrggbbaa annotation, the replacement could be done in seconds:
>> 
>> background-color: #56726C80
>> 
>> will become:
>> 
>> background-color: #88936C80
>> 
>> Easy! don't you think?
> 
> Precisely right.  Hex notation is the easiest thing to do
> search-and-replace on, unless you are *very* good at enforcing a
> particular format in writing your rgb().
> 
>> Otherwise, I should start writing everything in rgb() and rgba()
>> annotation and forgot completely about #rrggbb annotations which I
>> have been using for the last 10 years.
> 
> I've contemplated doing this exact same thing, despite the annoyance
> it would cause to try and retrain myself into thinking about colors in
> decimal.  (Thinking in %s would probably be a lot easier, but my
> toolchain doesn't naturally express colors in %s.)  So far, though, I
> haven't used transparent colors enough to justify this, and I'd prefer
> to not have to if I can avoid it.
> 
> (I also find rgb/a() notation incredibly ugly when nested into other
> functional notations, such as in a *-gradient() rule.  Functional
> notation is always ugly when nested (in CSS, at least), and so can't
> always be avoided, but I *greatly* prefer using named colors or hex
> notation when writing gradient rules.)
> 
> ~TJ
> 

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Saturday, 27 March 2010 00:12:17 UTC