Conditional application of style hints

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.

 - 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

 - if the user has the ability to easily turn various style sheets on
   and off, he can correct obvious legibility problems when they
   appear

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

Regards,

-h&kon

Hakon W Lie, W3C/INRIA, Sophia-Antipolis, France
http://www.w3.org/hypertext/WWW/People/howcome/













 > 
 > 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
 > 
 > Where we allow an additional name to be assigned to a style element, and
 > allow other style elements to depend on the success of the first one.  Sort
 > of a dependency tree, if you will, which I think is an appropriate way to
 > think about this problem.  The above example would cause <em class=darkred>
 > to produce dark red text, and <em class=lightred><a> to produce green text,
 > only if the browser is able to render <em class=lightred> as requested.
 > 
 > 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:
 > 
 >           didbg := *: back.image = "http://www.xyz.com/mygif.gif"
 > !didbg -> didbg := *: back.color = #000000
 >  didbg ->          *: 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?
 > 
 > An aside: when URLs are specified in a style sheet, what should they look
 > like?  Just the raw address?  The angle-bracketed URL: format?  Can they be
 > relative, and if so, are they relative to the URL of the original document
 > or the style sheet's URL?  That should all probably be addressed in the
 > spec.
 > 
 > -Steve
 >

Received on Monday, 10 July 1995 04:33:55 UTC