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

RE: Introducing property codependency.

From: Braden N. McDaniel <braden@shadow.net>
Date: Sun, 25 Oct 1998 23:41:04 -0500
To: "Ian Hickson" <py8ieh=www-style@bath.ac.uk>
Cc: "www-style" <www-style@w3.org>
Message-ID: <002401be009a$d6e57c80$01000080@bonezero>
> -----Original Message-----
> From: Ian Hickson [mailto:py8ieh@bath.ac.uk]
> Sent: Sunday, October 25, 1998 6:22 PM
> To: braden@endoframe.com
> Cc: www-style
> Subject: RE: Introducing property codependency.
>
>
> 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; }

Sorry, I made an error here. Last line should be

	P A:visited { 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?

Per your original example:
* Paragraphs are always black on white.
* Quotes are always black on yellow.
* Links in paragraphs *and* links in quotes are always blue on white.
* Visited links in paragraphs *and* links in quotes are always navy on
yellow.

My styles just assume that quotes will always reside inside paragraphs:
* Paragraphs are always black on white.
* Quotes in paragraphs are always black (inherited from P) on yellow.
* Links (which may or may not be in quotes) in paragraphs are always blue on
white.
* Visited links (which may or may not be in quotes) in paragraphs are always
navy on yellow.

> > IMO, assumptions like these valid more often than not with
> > well-constructed HTML documents.
> I need something that will _always_ work.

It will always work as defined in a compliant viewer. If you plan on using
the Q element *not* inside P, then the styles I gave are inadequate. If you
*don't* plan on using Q not inside P, then there is no reason my styles
won't be a perfectly adequate replacement.

Generally speaking, I've found that the better the markup is, the more
concise the style sheet can be.

> Already now I have limited
> myself, so that External links can't appear in Headers, for example.

But is this a problem with CSS, or with your chosen mechanism for
representing external links?

> To do the foreground/background comprehensively using just my three
> different backgrounds and five different foregrounds is currently
> unworkable.

Why? Because you think it is too much work, or because the
foreground/background colors are not really compatible?

> >> 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*!

And I think it is isolated and not fairly representative of likely use.

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

Yup.

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

<shrug> People don't identify comments versus sidebars versus whatever based
on color. They identify them based on their spatial relationship to the main
content. I'm not immediately sure how I would distinguish between a
"comment" and a "sidebar". Maybe just length. But I most likely wouldn't at
all, regardless of the color.

> So: What combinations of colours should I declare?
>
>            Normal  :link  :visited  :hover
>  Normal
>  Comment
>  SideBar
>  Example
>
> 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!

Whoa. If you are using the same foreground color in all places, why can't
you specify it just once?

For example, if, in my doc, I have P elements with classes Normal, Comment,
SideBar, and Example, but *all* the P text in the doc should be black, this
style would do the trick:

P { color: black; }

If I wanted all link text in all P elements (regardless of class) to be red,
this should do it:

P A:link { color: red; }

> 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 not convinced that we need any extension to avoid the redundancy you're
talking about.

Braden

<http://www.endoframe.com>
Received on Sunday, 25 October 1998 23:50:53 GMT

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