Re: Color prototypes

Andrew Thompson writes:
> > Bjoern Hoehrmann <derhoermi@gmx.net> schrieb/wrote:
> > >   @color brand rgb(22, 176, 64);
> > >   h1 { color: color(brand);
> > >        text-underline: single-accounting color(brand) }
> > 
> > Hm, you can already do something like that by using a pre- 
> > processor.
> 
> Every time someone suggests colour "prototypes" the working group, or others on 
> this list, suggest that route. 
> 
> I'm curious - when is the working group going to release CSS-PreProc, make it a 
> recommendation and make Macromendia and Adobe incorporate it into their tools? 
> I mean, get something out to the market which has a well known syntax so 
> O'Reilly and Prentice Hall can get it into the next edition of the Pocket Guide 
> or "for dumies" ?
> 
> I'm serious - I mean, I work with professional implementation designers. 
> They're *not* programmers. Are you seriously expecting them to understand how 
> to use "gcc -E"?
> 
> As a software developer I could use it. I could even script it for them or 
> write it myself in Perl. But that won't get a standard well accpeted, well 
> known, documented syntax out there. In other words, it won't get something that 
> people will actually be able to use from one job to the next. Some 
> organizations will be smart enough to enhance their process by using a 
> preprocessor and other tools, but that's not solving the problem.

I see your point, that it is useful to have a preprocessor that is
portable among authoring tools, but I stil believe it is outside the
CSS WG's scope, or even W3C's scope, since this is server-side
processing. (I believe we agree that browser should not have to deal
with macros.)

On the other hand, I've written some quite complex style sheets, some
over multiple files, but I have never felt the need for a preprocessor
(and I consider myself an experienced programmer...). The files are
always small enough that they don't need anything beyond a text editor
and for sharing colors and fonts between elements the existing
grouping syntax is usually adequate. And if not, just putting things
near each other solves the rest.

And also I fear the politics of it: if we design a new macro language,
everybody will laugh at us for reinventing the wheel. If we pick an
existing once, the m4 fanatics will hate us for choosing cpp and vice
versa; if we take JSP, the ASP programmers will be unhappy, and so
will those of PHP, SSI, Perl, etc. etc...

There is no technical work involved in it. It is purely a matter of
selecting an existing solution. W3C cannot help with that. If the
"market" doesn't converge on a solution, W3C cannot enforce it either.



Bert
-- 
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos/                              W3C/INRIA
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France

Received on Thursday, 27 September 2001 17:15:40 UTC