Re: CSS3: Color

On Saturday, Feb 22, 2003, at 15:44 America/New_York, Tantek Çelik 
wrote:

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


<snip> since you summarize well below

>
> Let me see if I understand what you are saying.

Yes, it looks like you're spot on:

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

I'd definitely keep the following, as they're pretty universal and 
clear:

GrayText, Highlight, HighlightText, InfoBackground, InfoText, Menu, 
MenuText, Window and Windowtext

Of course, Menu isn't always a flat color (OS X).

I'd drop/deprecate:

ActiveBorder, ActiveCaption, AppWorkspace, Background, ButtonHighlight, 
ButtonShadow, InactiveBorder, InactiveCaption, Scrollbar, all the 
ThreeD colors and Window Frame

For a variety of reasons: they're either very unlikely to be solid 
colors, have very specific Windows 95 L&F related meanings or have 
become obsolete because buttons aren't rendered with flat colors 
anymore (as you discuss below with the 'appearance' property)

I'm not sure about:

CaptionText, ButtonFace, ButtonText, InactiveCaptionText

The captions sound nice to keep, but in practice the default text color 
and Gray text probably cover these.
ButtonText is probably worth keeping, but then you'd have to keep 
ButtonFace - but that isn't really likely to be a flat color. Having 
said that, it would a flat color be on, for example, Palm OS, and it 
could be approximated on WinXP or OSX. Perhaps these are useful to keep.


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

Precisely. I don't think it is very usable right now.

Also, I'm not sure how you can "break" implementations when the 
definitions are so vague :) What I mean is, I haven't done an 
exhaustive survey, but I'd be surprised if the implementations that 
exist all agree on the colors on any given platform. In a sense, 
they're all "broken" because there is no obvious "correct" answer to 
conform to. I also suspect the number of documents using these 
properties is small.

I think clarifying the definitions that are not deprecated is a good 
idea. It increases the probability that implementors can agree what the 
correct colors are for a platform. I suspect there is very little to 
lose in terms of breaking things in practice.

<snip>

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

Yes. I guess that would make sense.


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

No, you're right...

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

Heh. Does Amaya still make them look like push buttons?

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

Well, I was vaguely aware of the CSS3 UI module, but I've obviously 
never read it closely enough. That's definitely a much better way of 
handling this stuff. I think I recall Ian Hickson talking about the 
earlier abandoned effort at one point. This appearance property is 
really a much better idea.

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

I agree completely. Lets drop them!

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 20:54:26 UTC