RE: Introducing property codependency.

> -----Original Message-----
> From: www-style-request@w3.org [mailto:www-style-request@w3.org]On
> Behalf Of Ian Hickson
> Sent: Thursday, October 22, 1998 6:13 AM
> To: braden@endoframe.com
> Cc: www-style@w3.org
> Subject: RE: Introducing property codependency.
>
>
>
> On Wed, 21 Oct 1998, Braden N. McDaniel wrote: (reorderd)
> >> 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.
> > <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.
> RIGHT!!! *THIS* is what I am getting at. This is what we should try to
> solve.
>
> I spent around an hour yesterday, after my post, trying to figure out
> ways (syntaxes) of doing it.
>
> > 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.
> I haven't as yet proposed anything.
>
> 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. IMO, assumptions like these valid more often than not
with well-constructed HTML documents.

> Ok, so the above doesn't look too bad. It's only got two background
> colours. My stylesheets have ended up sometimes with 6 or more
> background colours -- and if just *one* of the inline elements has a
> text colour, that means I have to list it SIX times!
>
> 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. I'm inclined to regard as a *feature* the fact that CSS's
syntax is unweildy for this application.

> (Note -- this isn't as academic as it sounds. Sitewide sheets may well
> have this many backgrounds, with only two or three used per page.
> There is no way to know which will be used, though. And inline styles
> -- well, :link, :visited, :active, :hover, :focused, to start with.)

I'm inclined to doubt that you would find a set of that many colors that
could be applied over *different* backgrounds effectively. I think in most
cases you'd have to make (at least subtle) changes to the text colors to
maintain their effectiveness, and it is my impression that the need for this
would be incompatible with any possible consolidation through "codepenency."

> And now for some less relevant points...
>
> > [snip color of links discussion]
> > 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.
> Noted.
>
> > 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.
> Now would be a good time for me to point out that background-position
> is currently not allowed on inline elements.

Whoops. Thanks. I suppose this would limit us to the left side.

[snipped for brevity]

> > #GANGSCREEN { ... }
> > #GANGSCREEN PRE { ... }
> > #GANGSCREEN STRONG { ... }
> 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. This is very subjective, though.

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.

Braden

<http://www.endoframe.com>

Received on Saturday, 24 October 1998 14:43:01 UTC