Re: Conditional application of style hints

> There needs to be a way to tell the browser, "only apply attribute X if
> you can apply attribute Y too."  Otherwise we'll run into situations where
> documents will be unreadable because a particular browser (perhaps due to
> platform limitations) can only present half the style hints, and the half
> that *are* presented don't make sense without the others.

There's another situation that calls for a similar solution, that's a
direct result of cascading style sheets. If you have two radically
different style sheets that get cascaded (one from the author, and one
from the reader) such that you get half your styles from one and half
from the other, you're going to have similar problems.

The obvious solution is to not do cascading, and you either use a
complete style sheet or you ignore it all. Cascading - used properly -
sounds far to usefull for that. This solution doesn't completely solve
the problem, either.

How about grouping style elements? Rather than a simple "do this one
if you can do that one, otherwise not", it's a collection of "Do all
of these, or none of them".

> I'm not sure what the best syntax for this would be.  Maybe something like:
> hasred := em.lightred:  font.color = #FF0000
> hasred -> em.darkred:   font.color = #800000
> hasred -> (a(em.lightred, (em.lightred(a: font.color = #00FF00

One possible syntax would be an optional "group" designator (in this
case, preceeding) the element and class values, so the above becomes
something like:

hasred&em.lightred: font.color = #FF0000
hasred&em.darkred: font.color = #800000
hasred&a: font.color = #00FF00

Declares the "hasred" group, and you only do hasred if you can do all
of them. This potentially allows groups to be scattered throughout a
style sheet, which makes parsing more of a pain. Possibly a grouping
syntax (do we want to invoke SGML for this?), ala:

[
	em.lightred: font.color #FF0000
	em.darkred: font.color #800000
	a: font.color #00FF00
]

You can then basically exclude cascading by wraping your entire style
sheet in '[' and ']' if you wish.

> A slight extension of this would also allow fallback behavior to be
> specified.  For instance, if you want a black background on machines that
> can't display your dark background image, you might do:

The same kind of thing can be done with groups. Just choose an
"alternate" seperator (say |)

> 
>           didbg := *: back.image = "http://www.xyz.com/mygif.gif"
> !didbg -> didbg := *: back.color = #000000
>  didbg ->          *: font.color = #FFFF00

Becomes:

[
	*: back.image = "http://www.xyz.com/mygif.gif"
	*: font.color = #FFFF00
|
	*: back.color = #000000
	*: font.color = #FFFF00
]

> I'm sure someone else can come up with a better syntax!  Does anyone agree
> that this is something that needs to be addressed?

Obviously, I agree. I don't think that introducing explicit variables
is a good idea; it seems like overkill. I believe that groups - once
you allow nested groups - can handle your tree semantics, like so:

[
	*: font.color = #FFFF00
	[
		*: back.image = "http://www.xyz.com/mygif.gif"
	|
		*: back.color = #000000
	]
]

As a final example, you can specify a set of header fonts you want
used easily:

[
	h1: font.size *= 2, font.style = bold
	h2: font.size *= 2, font.style = italic
	h3: font.size *= 1.5, font.style = bold
	h4: font.size *= 1.5, font.style = italic
	h5: font.style = bold
	h6: font.style = italic
]

In which case, you either get your chosen header styles, or the users,
but all headers will come from the same style sheets. This is much
simpler than doing the same thing with variables and conditionals.

	<mike

Received on Sunday, 9 July 1995 20:48:32 UTC