- From: Scott Bigham <dsb@goldfinch.cs.duke.edu>
- Date: Mon, 16 Oct 1995 22:15:43 -0400
- To: www-style@w3.org
Hakon Lie <howcome@w3.org> writes:
>Scott ( > > ) and Evan ( > ) write:
Well, actually, it was the other way around, but that doesn't matter
much.
> > > o The element declaration "(X)Y,Z" would appear to be ambiguous.
> > > [...]
> > Or perhaps two grouping connectors: ',', which binds tighter than
> > patterns, and ';', which binds looser. Thus `(X) Y,Z' would be
> > equivalent to `(X) Y; (X) Z'.
>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 {...}'.
>"*" 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?), 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? 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?
> > > 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.
> > - 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!".
> > - On a similar note, and though this may just be an implementation
> > issue, Arena's method of using the initial page's style sheet as the
> > default style causes problems with the "!important" reader/author
> > symmetry. That is, if I put `body {background = white !important}'
> > in my home page's style sheet to override backgrounds from incoming
> > style sheets, then anyone viewing my home page will receive that
> > setting as `author important', which is not what I want.
>So, your startup page and home page are the same? If so you'll have a
>problem, yes. A simple command-line argument in Arena should allow you
>to change this behavior in the future.
Something like "arena -style the/style.file"? That's pretty much what
I was leading up to suggesting; that or putting it in a browser
configuration file of some sort.
> > - Are `color' and `background' now aliases for `text-color' resp.
> > `text-background', or is this just a typo? [...]
>I meant to change "text-color" into "color" throughout the document
>exactly for this reason. It only happened in the list of properties,
>thought, but will be updated in the next release. Similarly,
>"background" is the preferred way of referring to the background. Do
>we need aliases?
Nah, I don't think so.
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?
-sbigham
Received on Monday, 16 October 1995 22:15:51 UTC