RE: Introducing property codependency.

> -----Original Message-----
> From: www-style-request@w3.org [mailto:www-style-request@w3.org]On
> Behalf Of Ian Hickson
> Sent: Wednesday, October 21, 1998 1:55 PM
> To: www-style@w3.org
> Cc: www-style
> Subject: Introducing property codependency.
>
>
> On Wed, 21 Oct 1998, Sue Sims wrote:
> > Action Sheets
> > <URI:http://www.w3.org/TR/NOTE-AS>
> > I haven't found a submission for the MS behavior proposal.
>
> Action Sheets look _very_ interesting.
>
> Of particular relevance to www-style and CSS3 are points two and three of
> the "Open Issues" around three quarters of the way down the above quoted
> page.
>
> A BIG problem with CSS at the moment is the potential clashing of colours.
> Any stylesheet which defines a few different background colours and a few
> different foreground colours has to define *every* possible combination
> separately. For example, on my page my links are colour coded (Internet,
> External, Page or Mail) and I have different backgrounds for the header,
> the footer, new sections (highlighted), sections in CODE or PRE, and so
> on. In case you don't realise the extent to which this is a problem, I had
> to separate my link colours into a separate CSS file because it was
> getting impossible to handle. [1]

I mean no offense by this--I always think it is encouraging to see people
experimenting with new UI ideas--but I think this is more of a design
problem than it is a CSS problem. Users aren't accustomed to link color
indicating the "proximity" of the link destination. And IMO, text color
isn't a sufficiently striking indicator to jar the user's memory in the
desired regard.

Some conclusions I've reached about text colors for links:

Except for "button-like" areas, avoid using multiple different link colors
on the page. It is generally practical to make modifications to the value
(as in HSV) of the color, but that's about it. (Which reminds me: How about
adding an hsv() functional notation for color in CSS3? Yes, it's just a
matter of convenience. But it *would* be convenient, and it should be
trivial to implement.)

If the above is violated, forget about expressing anything with the link
text color other than that the text is a link.

Variations in the color of links that are *not* demanded by the background
aren't good for expressing much except what users have grown to expect: that
the link has already been visited, or that it hasn't. The "active" color
really doesn't express anything, it's just a cool effect. (If the link is
"active" there is a good chance the user is already aware of it since he
would have the cursor over the link with the pointing device button
depressed.) Same with hover, though it is useful for drawing attention to
links.

Getting back to the problem of indicating "external" vs. "local" links... I
think some kind of icon is the most desirable approach. But can we do this
without disrupting the flow of text? And can an icon be subtle?

I think so.

I propose creating a small, transluscent (courtesy of PNG) simple icon. This
could be used something like this:

	A:link.external, A:visited.external {
		background-image: url("external.png");
	}

You'd prolly wanna add background-position and background-repeat properties
at your discretion; I'd probably opt to have the image not repeated, and
displayed at the far right of the text box.

Elaborate color-coding is useful for information-dense things like charts
and maps. But one has to do some thinking or have a firm familiarity with
the data and representation method in order for it to be intelligible. I
think for documents, color is most useful for drawing attention and creating
contrast. I think we need to be very careful about expressing information
with color alone.

> One way around this problem would be to use something similar to one
> of the issues mentioned in the CAS proposal. What one could introduce
> is the ability to link properties IN DIFFERENT RULES together, in such
> a way that if one is overruled, then the other will be ignored too.
>
> i.e., property codependency.
>
> Comments? [2]
>
> -------------
> [1] You want to see what I mean? Look at my main CSS file:
>    http://www.bath.ac.uk/%7Epy8ieh/media/homepage.css

In which you include:

#IE4GANGSCREENPAGE #GANGSCREEN {
  background: black url(res://shdocvw.dll/ierocks.gif)
  fixed no-repeat center center;
  width: 414px; height: 352px; margin: 0em 0em 0em 1em;
  overflow: auto; border: solid black medium;
  color: white; padding: 2em; text-align: center; }
#IE4GANGSCREENPAGE #GANGSCREEN PRE {
  font: 14px "Verdana", "Arial", sans-serif;
  color: white; padding: 0em; margin: 0em;
  font-weight: bold; background: transparent none; }
#IE4GANGSCREENPAGE #GANGSCREEN STRONG {
  color: yellow; font-weight: inherit;
}

/* I cringe at the specificity of those rules... */

Me too.<g> Part of what you have there is entirely superfluous. Since an ID
is guaranteed to be unique for a document, giving an ID-selector a context
is totally unnecessary. The above selectors could be simplified to

#GANGSCREEN { ... }
#GANGSCREEN PRE { ... }
#GANGSCREEN STRONG { ... }

This is kinda like doing

P#myP { ... }

That's perfectly valid CSS, but it is overspecifying--and, IMO,
overcomplicating--things.

#myP { ... }

... is quite sufficient.

> and then the related file which only deals with the link colour
> clashes:
>    http://www.bath.ac.uk/%7Epy8ieh/media/links.css
> They are about the same size!!!

<shrug> Just about any style sheet, or set of style sheets, I've created
that I would consider "robust" has at least one "monster" in the bunch. Such
is the nature of CSS. The reality of "cascading" demands that one
defensively specify any property on any element that might be important in
achieving the desired visual effect. It gets long sometimes.

> [2] I won't bother citing examples, because every time I show an
> example of how a new idea could be implemented, the discussion becomes
> one of appropriate syntax rather than potential of the idea!!!

Whoops.<g> I kinda like the idea you're putting forth, but I don't think the
example you've provided does a good job of illustrating its necessity.
Context-specific selectors allow the result you're looking for (though the
means is different). I'll grant you that it can get a bit long sometimes,
but I'm really not sure that what you're proposing would be significantly
more compact.

Braden

<http://www.endoframe.com>

Received on Wednesday, 21 October 1998 23:22:09 UTC