- From: Steven Grimm <koreth@hyperion.com>
- Date: Thu, 13 Jul 1995 01:55:57 -0700
- To: howcome@w3.org
- Cc: www-style@www10.w3.org
I wanted to give other folks a chance to chime in; here's my take on the problems you point out: > - complexity: the syntax and implementation can get quite > complex. And we want to keep things simple, right? Definitely! I think the grouping syntax devised by Mike Meyer passes the syntactic simplicity test; my intuition is that it's also going to be easy to implement, but of course I say that without having actually done so. > - 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. That's true; on the other hand, I think the chance for abuse here is no worse than in many other places in the Web. Inconsiderate authors will always find a way to make their pages annoying to some of the user base, no matter how much it's discouraged by the markup language. I would also argue that that specific case has to be dealt with by the browser no matter what; such a user will presumably also want enlarged graphics and other atypical display elements. > - 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? This is probably the stickiest of the three problems, and I don't have an easy answer except to say that in the end, this is going to have to be decided by the browser, possibly with user assistance. Once the spec starts getting into issues like that, it'll go nowhere fast, if only because there's such huge variance in platforms out there. For instance, a text-only or monochrome browser might treat all color settings as automatic successes for the purposes of grouping. > - fallback values: When the "back.image" fails, "back.color" will > be utilised My problem with this approach is that it risks littering the spec with all sorts of little special cases, which then have to be hardcoded into every browser out there. Letting the author specify fallbacks keeps the spec and the implementation simpler in the long run, it seems to me. In that specific case, the fallback is pretty obvious; in the case of something like font types, there might not be a clear, universally acceptable rule, and letting the author control what happens will probably make everyone happy. You also run into the "What constitutes a failure?" question you mentioned above. For instance, if I have to dither a 24-bit color background image down to two colors, is that a failure? In that respect simple fallback measures aren't much of an improvement over grouping. > - if the user has the ability to easily turn various style sheets on > and off, he can correct obvious legibility problems when they > appear I think you want that whether you have grouping or not. Even with grouping, the user (e.g. the visually impaired user in your example) should be able to override the document. I think of it in terms of layers: the user's defaults, then the document's style hints, then the user's overrides, in increasing order of precedence. > These alternatives only address your specific example. What other > real-life situations do we have where the notion of cascading style > sheets will fail? That's probably one of the more extreme examples, since most style sheet botches will result in a document looking strange, but not becoming completely illegible. As for other situations... off the top of my head, it seems like you might want to group font size hints, for example, if you want <h1>Some big text</h1> <h2>Some medium text</h2> <h3>Some small text</h3> to get progressively smaller for some reason, you'd probably rather not have your <h2> font search fail and leave you with a tiny font surrounded by two much larger ones. Not as compelling as the background color example, I know. -Steve
Received on Thursday, 13 July 1995 04:56:07 UTC