W3C home > Mailing lists > Public > www-style@w3.org > October 1998

RE: Introducing property codependency.

From: Ian Hickson <py8ieh@bath.ac.uk>
Date: Sun, 25 Oct 1998 23:21:37 +0000 (GMT)
To: braden@endoframe.com
cc: www-style <www-style@w3.org>
Message-ID: <Pine.GSO.4.04.9810252303470.22449-100000@amos.bath.ac.uk>
On Sat, 24 Oct 1998, Braden N. McDaniel wrote:

>> The challenge is to simplify a stylesheet like the following:
>>    P { color: black; background: white; }
>>    Q { color: black; background: yellow; }
>>    P A:link { color: blue; background: white; }
>>    P A:visited { color: navy; background: yellow; }
>>    Q A:link { color: blue; background: white; }
>>    Q A:visited { color: navy; background: yellow; }
>> ...so that there are only four rules, but without compromising the
>> 'safeness' of the rules. In other words, one cannot simply make it:
>>    P { color: black; background: white; }
>>    Q { color: black; background: yellow; }
>>    A:link { color: blue; }
>>    A:visited { color: navy; }
>> ...since with this sheet we are faced with the possibility of
>> another stylesheet in the cascade applying a background to the A
>> element, and making the document.
> How about
> 	P { color: black; background: white; }
> 	P Q { background: yellow; }
> 	P A:link { color: blue; background: white; }
> 	P A:link { color: navy; background: yellow; }
> Now, this doesn't mean exactly the same thing as your example, but
> it will have the same effect as long as my assumption holds true:
> that Q will always appear inside a P. 
I don't understand how your css will work. Could you explain it?

> IMO, assumptions like these valid more often than not with
> well-constructed HTML documents.
I need something that will _always_ work. Already now I have limited
myself, so that External links can't appear in Headers, for example.
To do the foreground/background comprehensively using just my three
different backgrounds and five different foregrounds is currently

>> With 6 different inline colours and 6 different background colours, I
>> need 36 different rules! It becomes UNMANAGEABLE!
> I perceive terminal design flaws in such a setup, so I don't think
> it's a realistic example. 
It's one I'm *using*!

I have the following styles:

The main text has a two inch left margin. The main text is black on
white. Links have three colours, one for :link, one for :visited, and
one for :hover, :focus and :active. I *have* to declare those colours,
otherwise user defined link colours may clash with my background.
(This *has happened*. My default colours settings a few weeks back
were black bg, silver fg, and white links. 90% of pages become
unreadable: silver on white text with white on white links (because
many only specify bgcolor=#ffffff)).

Now my left margin can contain information. There are two types:
comments and sidebars. Comments are black on yellow, sidebars are
green on yellow. I can also have Worked Example sections, which are
black on silver across the page.

So: What combinations of colours should I declare?

           Normal  :link  :visited  :hover

Sixteen! I also have my EM having a special color. Twenty! I may want
to highlight areas of text. Twenty five! Also, some documents have a
specially coloured colophon. Thirty! My documents also have subtly
coloured headers and footers. Thirty Five!

That is thirty five *rules* -- and around fifty or more different
selectors. This is ridiculous. There must be some way in which we can
extend CSS so that this amount of redundancy is removed.

> I'm inclined to regard as a *feature* the fact that CSS's syntax is
> unweildy for this application.
I do not.

The above is loosely based on something I do already do:
However, this stylesheet is not robust since it does not declare all
thirty odd required colours. 

>> No. In this case, the stylesheet is used by *every* page on my
>> site. I may have more than one gangscreen, but only one is IE's
>> gangscreen.
> Ahh. I think a CLASS is more appropriate here, even if there may
> only be one GANGSCREEN per page. 
I agree with you, the reason that this particular case is done by ID
is purely historical.
> In fact, I avoid using ID selectors in site-wide sheets at all. ID
> selectors aren't much different conceptually from using the STYLE
> attribute, so I'm inclined only to use them with style sheets tied
> to a specific document.
I agree entirely.

In this case, the styles were originally in the file's <STYLE> block.
However, I later viewed the file in Netscape.

Ian Hickson
Received on Sunday, 25 October 1998 18:21:40 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:26:48 UTC