Re: Gradient color

Thus spake Daniel Glazman:
 
> I have to disagree with you. It can also be a browser boolean option
> like the existing "dither images" saying "refuse gradient
> backgrounds". When a web server contains a great image with a too wide
> colormap the browser cannot handle, it is the same thing, and such
> images exist in the web. In fact, the web is full of this kind of
> images.

And when used as backgrounds for text, the results are unhappy. Sad but
true: many, many users are completely unaware that their "agent" has such
settings, and terms like "dither" and "gradient" are fairly specialized.
Requiring users to reconfigure their defenses for every overblown design is
friendly to neither users nor authors. It seems much more sensible to me to
empower authors to make better choices. I may well wish to specify a
gradient background if I know the display supports enough colors; failing
that, I'd like to specify one or more alternates for the UA to select based
upon my parameters - not the user, based upon his or her level of knowledge
and care.

> I understand that if the rendering engine knows the context, the
> algorithm can be more (or less) efficient. But this is not IMO a good
> reason why gradients should be left away. The problem you're
> mentioning is related to the rendering medium, not to the styles.

To end users, there is no difference. Styles can now be parameterized with
@media, but the media types are far too coarse IMO, with at least as much
variation within media types as across them. I'd like to see media
specified in more descriptive, quantitative terms: physical, color, and
audio resolution, typographical rendering policies, connection throughput,
processing speed and available memory, and of course extensive user profile
information, captured in a user style sheet.

But first, a CSS1 implementation would be nice. <g>

__________________
Todd Fahrner
mailto:todd@lowbrow.com
http://www.verso.com/agitprop/

Received on Sunday, 10 May 1998 23:15:06 UTC