W3C home > Mailing lists > Public > www-style@w3.org > February 2003

Re: CSS3: Color

From: Andrew Thompson <lordpixel@mac.com>
Date: Sat, 22 Feb 2003 13:52:44 -0500
Cc: <www-style@w3.org>
To: Tantek Çelik <tantek@cs.stanford.edu>
Message-Id: <D41E0A49-4696-11D7-8B9A-000A27D7D9DC@mac.com>


On Wednesday, Feb 19, 2003, at 01:37 America/New_York, Tantek Çelik  
wrote:

> On 2/18/03 6:56 PM, "Andrew Thompson" <lordpixel@mac.com> wrote:
>>>
>>
>> Well, I was going to stay out of it this time, but since you asked...
>> Neither current mainstream OS (Win XP or Mac OS X) is in any way
>> adequately covered by the system colors. Both use textures, shadows,
>> highlights etc in ways the System Colors don't capture. I don't know
>> enough about Gnome or KDE to comment on these.
>
> Absolutely.  We even tried to extend the system colors to cover many  
> more
> types of user interface elements and states etc. in a previous draft.
> However modern user interfaces use far more than just color (or fonts)  
> for
> the appearance of OS widgets.  Hence we decided to stick with the  
> short list
> from before rather than extending it in a way which was still far from
> adequate.

Then perhaps they should be rationalized further, down to those things  
that are universal. Arguably that's a very small set indeed: Window and  
WindowText would seem the more useful.

Anyway, is the working group deliberately keeping to the same old vague  
definitions that have always been used?

eg,

Scrollbar
	Scroll bar gray area.

What does this correspond to? What's the gray area of a scrollbar?

ThreeDLightShadow
	Light color for three-dimensional display elements (for edges facing  
the light source).

Is this a shadow or a highlight? Going back to history, its fairly  
clear these colors are an attempt to represent the 4 colors used to  
make a Win95 button look 3D - so I'm guessing this is the darker of the  
2 colors on the top and left sides of the button. However I've never  
been sure, and I'm sure that's true for most people.

ButtonHighlight
	Dark shadow for three-dimensional display elements (for edges facing  
away from the light source).

Why would the Highlight be a dark shadow color on the side facing  
*away* from the light source. This makes no sense, a highlight should  
be lighter than the main color, surely?

I'm trying to understand whether these definitions have never really  
been altered to make them easier to understand.

* Is it that no one is really sure what they mean?

* Are people just leaving them alone out of some sense of maintaining  
backwards compatibility?

Personally I'd say that these definitions either need to be revised so  
that they actually make sense (ie, avoid calling any colors a highlight  
and a shadow at the same time). Alternatively we should drop everything  
that's ambiguous and just keep those colors that are well defined and  
more or less meaningful on all platforms (ie, Window, Window Text, a  
few others like InfoText).


>>> Do the original requestors of this functionality still care about it,
>>> or was
>>> my suggested implementation workaround accepted as an alterative?
>>>
>>>  http://lists.w3.org/Archives/Public/www-style/2002Sep/0061.html
>>>
>>> You've got (just under) 10 days to speak up.  If no one objects I am
>>> leaning
>>> towards dropping the CSS3 hyperlink colors.
>>
>> Well, on reading I'd assumed the utility of these keywords is to  
>> enable
>> me to style some arbitrary element in some way such that it looks more
>> like a hyperlink to the user - at least it uses the same colors. eg, I
>> suppose I could have an <object> element that behaves similarly to a
>> hyperlink when the embedded content is clicked on. I might want to
>> style it with in the appropriate colors borders so it looks like a
>> hyperlink to the user.
>>
>> I took at look at your proposed alternate Tantek, and I'm not sure how
>> I'd achieve something like that using your user stylesheet scheme. I'd
>> assumed something like that was the use case for this feature.
>
> You've missed the point(s).

Well, yes probably, but you've missed the point I was trying to make  
too.

>
> The alternate that I provided is for _implementers_ seeking to  
> understand
> how to properly reflect user preferences for hyperlink colors via style
> rules prepended to the user style sheet.

> You're speaking from the perspective of an author.  Authors simply do  
> what
> fantasai suggested:

Actually, I did understand that you were speaking about implementers. I  
was trying to give an example of why these properties might be  
interesting to authors. If they're not interesting to authors, then I  
agree they should be removed for the reasons you give.

> <blockquote
>   
> cite="http://lists.w3.org/Archives/Public/www-style/2003Feb/> 0105.html">
>   That's it? This is what you're adding color names for? Why, that's  
> easy
>   to do even now. Just don't override the user's link colors.
> </blockquote>
>
> And as far as borders go, border-color has the initial value of "the  
> value
> of the color property" so there is again no need to set it to anything.
> Simply set the 'border-style' to something other than 'none' and the
> appropriately colored border should show up.
>
> The "C" in CSS stands for Cascading.  Using a system with a cascade  
> means
> sometimes the answer is to *not* do something, to *not* interfere with  
> the
> default/user-preferred style rules which are already cascading into  
> place,
> rather than *doing* something, and then *doing* something else on top  
> to fix
> it up.  Sometimes less code works better than more.  Often in fact.
>
>> AndyT (lordpixel - the cat who walks through walls)
>
> Especially when walking through walls.

Thanks for the lecture. It'll certainly help me appreciate the cascade  
of dust in the drywall much more fully.

I see exactly what fantasai and yourself are saying here. Yes, its  
pointless to explicitly style an anchor element back to the user's link  
colors, and one could border an anchor and get the same color on the  
border.

What I said was:

"Well, on reading I'd assumed the utility of these keywords is to  
enable me to style some arbitrary element in some way such that it  
looks more like a hyperlink to the user "

The key words here are "arbitrary element". To take a pointless but  
concrete example, how would I make the background color of a paragraph  
element the same color as the text in an anchor element?

ie,
p { background-color: Hyperlink; }

Is there another way to say this without using the Hyperlink colors?

I tried to give a concrete example where an author might want to do  
this:

" I suppose I could have an <object> element that behaves similarly to  
a hyperlink when the embedded content is clicked on. I might want to  
style it with in the appropriate colors borders so it looks like a  
hyperlink to the user."

However I guess that wasn't clear enough. Apologies.

Assuming there's not another way that an author could achieve the same  
effect that I have missed (very possible!) then that leaves us here:

If you don't believe an author would ever want to do something similar  
to the example I gave, then the colors have no utility to authors.  
Further, since you've demonstrated implementors don't need these  
keywords, you've made the case for removing them. Conversely, if you  
agree an author may want to do something along these lines, then that's  
a case for keeping these colors in the specification. They should only  
be there if they're useful to authors.


AndyT (lordpixel - the cat who walks through walls)
A little bigger on the inside

         (see you later space cowboy ...)
Received on Saturday, 22 February 2003 13:53:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:19 GMT