Re: CSS3: Color

On 2/22/03 10:52 AM, "Andrew Thompson" <lordpixel@mac.com> wrote:

> 
> 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.

Certainly those two in particular tend to still be solid colors on today's
platforms.

Are you suggesting keeping a particular subset of the CSS2 system colors?

> Anyway, is the working group deliberately keeping to the same old vague
> definitions that have always been used?
> 
> eg,
> 
> Scrollbar
> Scroll bar gray area.

The definitions have been stable for many years now, and referenced by
additional specs (SVG 1.0, SVG 1.1), so yes, the default action in such
cases is to leave the definitions alone, even if they are vague.


> 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?

Are you requesting a more specific description for these system colors?

> 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?

I can research this and try to come up with one, but yes, any change in
definition (even one more specific) risks making previously conformant
implementations non-conformant, and therefore I am hesitant to alter these
definitions at this time unless there is a good reason to do so.


> 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).

Let me see if I understand what you are saying.

You are proposing to either:

a) Drop or deprecate (which one?) most of the CSS2 system colors, while
keeping a small handful (specifically Window, WindowText, InfoText and which
others?)

b) Revise their definitions to be more specific (which may 'break' some
implementations, but may also improve the usability of this feature).

Is that correct?  Could you be more specific about what you would want in
choice a)?  And what you would want dropped or (more likely) deprecated?


>>>> 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.

Yes, it happens.


>> 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.

Ok, glad we're agreed that they're not interesting for implementers.


>> <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.

(Sorry - just a poor attempt at humor on your .sig ;-)

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

LOL.

> 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.

Ok.


> 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.

Couldn't you just wrap that <object> element in a hyperlink to achieve that
affect?  That seems more semantically correct also.

> 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.

No problem.  Thanks for clarifying your example - I think I understand what
you were getting at.

A few years back the CSS working group tried pretty hard to figure out how
to turn an arbitrary element (like <span>) into something that looked and
behaved (from a dynamic interaction point of view) like a <button>.  We
walked down the path of trying to figure out the colors, backgrounds,
borders, padding etc. that one would need.

It turned out to be quite a futile exercise, because, as pointed out, the
display of user interface controls on platforms have become far richer than
the CSS layout model can easily represent.  Thus we abandoned an effort to
try to model the individual components of controls, and instead added the
'appearance' property in CSS3 UI.

 http://www.w3.org/TR/css3-ui/#appearance

Now, as for hyperlinks, you _could_ make the argument that they are *still*
simple enough for their styling (color, background-color, text-decoration,
font info) to be represented by CSS properties.  But is a hyperlink that
much different than a button?

I could easily see some OSs (and perhaps some UAs for that matter) rendering
hyperlinks much more richly by default than the typical "underlined blue
text" default.  Then we would run into the same problem with they Hyperlink
colors as we ran into with the other hundreds of new system colors we tried
to come up with.

But really, if you are trying to make an arbitrary element (like a <p>) look
like a hyperlink, you should use the 'appearance' property:

p { appearance: hyperlink }

> 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.

In this case I think they are not only not very useful for authors (this is
the first I have heard of an author actually trying to make a particular
non-hyperlink element look like a hyperlink by referring to system
defaults), but also both complicated and insufficient to achieve the full
effect.  I think 'appearance: hyperlink' would work better than any attempt
at defining just hyperlink _colors_.

Tantek

Received on Saturday, 22 February 2003 15:31:20 UTC