Re: Conditional application of style hints
Subject: Re: Conditional application of style hints
From: Mike Batchelor <firstname.lastname@example.org>
Date: Mon, 10 Jul 1995 09:21:00 -0400 (EDT)
From email@example.com Mon Jul 10 09: 21:10 1995
In-Reply-To: <199507100833.KAA08668@www4.inria.fr> from "Hakon Lie" at Jul 10, 95 10:33:38 am
X-Mailer: ELM [version 2.4 PL24alpha3]
Hakon Lie once wrote...
> Steven Grimm writes:
> > 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.
> You bring up an important issue. Up to now, I have avoided the issue
> due to:
> - complexity: the syntax and implementation can get quite
> complex. And we want to keep things simple, right?
> - chance for abuse: authors may be tempted to group everything by
> default, i.e. "Unless you take all my hints, you won't get
> any". A visually impaired reader may be denied double-sized fonts
> due to this.
A visually impaired reader is ideally using a UA that is already doubling
the font sizes for him. And for the first style sheet specification, I
think an all-or-nothing decision is acceptable. I can imagine that many
readers will turn off all style sheet processing. A reasonable UA that
implemented style sheets would have its local style sheet, and the
author's style sheet, and the reader would be able to turn off one, or the
other, or both. A more sophisticated UA would allow the reader to have
his own local style sheet, and specify which of his style choices an
author may override, and which ones should never be overridden by the
So I guess my point is that this is a browser issue.
> - hard to define: how do you define when a hint has succeded? If a
> browser uses the color #F00 instead of the requested #E00, is that
> a success or failure?
> > For example, I was playing around with style sheets in Arena 0.97 and
> > tried to put a background image in my document as described in the draft
> > spec. "back.image" doesn't seem to be implemented yet. Unfortunately,
> > font.color is, and my colors assumed that the background image would be
> > loaded.
> Your example is a good one. I think there are some simple alternatives
> to introducing a new grouping mechanism; these don't solve the
> problem, but will make it easier to live with:
> - fallback values: When the "back.image" fails, "back.color" will
> be utilised
That could work well. But it should be the UA that defines the fallback
policy. The author can supply both a back.image and back.color, and the
UA can decide whether to use author's back.image/back.color, or the local
back.image/back.color, according to user preference.
A really sophisticated UA would remember style preferences for recently
> - if the user has the ability to easily turn various style sheets on
> and off, he can correct obvious legibility problems when they
> - Some heuristics could be built into the browser to avoid the
> obvious problem of no-contrast text.
> These alternatives only address your specific example. What other
> real-life situations do we have where the notion of cascading style
> sheets will fail?
%%%%%% firstname.lastname@example.org %%%%%% http://www.clark.net/pub/mikebat/www/ %%%%%%