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