> >The ambiguity should be removed, but is the increased complexty in
> >notation worth it? I would suggest interpreting (X)Y,Z { A = B } as
> >
> > (X) Y { A = B }
> > Z { A = B }
>
> That'll work too. As long as the ambiguity is settled. And we wouldn't
> lose any expressive power, since we could still say `(X) Y, (X) Z {...}'.
Exactly.
> >"*" is not a synonym for "HTML", it's a synonym for the top-level
> >element. In HTML, this happens to be "HTML", but many authors omit it
> >and I believe "*" is more intuitive. [...]
>
> This is a bit of an ambiguous parse. Do you mean that if the author
> doesn't explicitly include the <HTML> open tag, then "*" becomes a
> synonym for something else ("BODY", perhaps?)
No.
> or do you mean that "*"
> is in fact a synonym for "HTML" but you're referring to it here as "the
> top-level element" because some authors actually don't know that
> there's an HTML element at the top level?
Partly. This is true when handling HTML documents, but HTML authors
often omit it.
> Or do you mean that this
> style sheet language could just as easily be used with other SGML-based
> languages, in which case "*" would become a synonym for the top-level
> element of whatever sort of document it was used with?
Yes.
> > > > o There is syntax for "A.link" and there is syntax for "A.CLASS".
> > > > Is it possible to say "A.CLASS.link"?. [...]
>
> Another interesting corner case here is <A CLASS=link>, for which
> `A.link {...}' is ambiguous. I'd say have the pseudo-class take
> precedence in this case.
So one cannot manually force an anchor element from one pseudo-class
to another? Good point.
> > > - When was the cascade order changed so that `author important'
> > > overrides `reader important'? This is IMHO horribly wrong; the
> > > reader should always have ultimate say in matters of rendering.
>
> >This is an issue of much debate. Before, the author was not allowed to
> >specify "!important". That was changed to make the syntax fully
> >symmetrical. Note, however, that the specification describes how style
> >sheets can be turned on and off in e.g. a pulldown menu. So if the
> >incoming style sheet abuses its powers, one could turn it off (and
> >acknowledge the warnings that come through the !legal construct). Does
> >this make you happier?
>
> Somewhat. I still think the reader should be able to say to his
> browser something like, "I don't care how insistent the author is about
> his font size, I can't read anything smaller than 16pt and that's
> final!".
Those who went to the style sheet workshop at the Darmstadt conference
know that I tried to defend this view against the publishers. They see
things a bit differerent and are concerned about users turning content
(ads, warnings, legal small-print) off. I believe the compromise
outlined in the current proposal (author's assignment win, but the
whole style sheet can be turned off) ensures a proper balance.
> Oh, while we're on the subject of backgrounds, I've noticed that in the
> current version of Arena, setting `P {background = ...}' sets the
> background only behind the text itself, instead of setting the
> background of the whole box containing the paragraph as implied by the
> draft. Is this the intended effect, or just a coverage failure in the
> implementation?
It's a quick hack that only sets the background when rendering
text. We're working on the real thing. I've come to like the look of
the quick hack, but it cannot be expressed in the current proposal.
Regards,
-h&kon
Hakon W Lie, W3C/INRIA, Sophia-Antipolis, France
http://www.w3.org/hypertext/WWW/People/howcome/