[email protected] (Evan Kirshenbaum) writes:
>Here are mine, in no apparent order. [...]
And here are some second-level comments, followed by a few first-level
comments of my own.
> o I think that it is going to be necessary to add at least
> rudimentary numbering style for lists to level one. [...]
>
> number-form = uppercase alpha | lowercase alpha |
> uppercase roman | lowercase roman |
> decimal |
> url : <url> |
> char : <char>
> [...]
Hmm. Are you suggesting using a style parameter named `number-form' for
both ordered and unordered lists? That seems counterintuitive. I'd
suggest either using a more neutral name like `list-annotation' or
splitting it into `number-form' and `bullet-form'.
I'd also suggest instead of (or perhaps in addition to) `char : <char>'
the option `dingbat : <dingbat>', where <dingbat> picks up the iconic
entities from <UL DINGBAT=...>. Perhaps also `none' for unbulleted
lists, and `normal' or `default' for whatever the rendering agent would
have put there anyway.
> or perhaps better
>
> number-pattern = <pattern>
> number-url = <url>
>
> where <pattern> is a string substituting "%A", "%a", "%I", "%i",
> "%1", "%u" for the above. This would allow specifying things like
> "(%1)" or "%a.". It would also allow the i18n extension to
> "%א" to number in Hebrew, etc. once 10646 is accepted as the
> document character set.
I like.
> o The element declaration "(X)Y,Z" would appear to be ambiguous.
> I'd suggest that it might be worth changing the notation to use
> "::" for scoping a la C++ and Perl. This would allow you to
> disambiguate between "X::Y,Z" and "X::(Y,Z)".
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'.
> o I'm a little unclear as to why "*" is a synonym for "HTML". [...]
Indeed. In fact, I was under the impression that "*" was originally
intended to be a wildcard representing _all_ classes.
> I would suggest allowing "define color", "define size", and
> "define font" in level one, and perhaps "define effect", which
> takes a brace-delimited set of attributes which are all applied
> unless explicitly overridden.
Hmm. How exactly would "define color fred = red" differ from
"define fred = red"?
> o There is syntax for "A.link" and there is syntax for "A.CLASS".
> Is it possible to say "A.CLASS.link"?. [...]
Similarly, what of <P CLASS=STANZA.COUPLET>, which appears as an example
in <URL:http://www.w3.org/hypertext/WWW/MarkUp/html3/docbody.html>? The
syntax doesn't seem to allow `P.STANZA.COUPLET {...}'.
> o In order to be able to correctly customize BIG, SMALL, SUPER, and
> SUB, font-size-index needs to be able to be specified to be a
> relative value such as "+2", "-1" or (my preference) "up two" and
> "down one".
In previous versions of this draft, this was expressed as
`font-size-index = font-size-index + 2' or `font-size-index -= 1'.
> o I notice that for text-color, there is no way to override the
> context's choice to go back to the user default. Perhaps "none"
> should be allowed.
This might even answer a point of my own; see below.
> o The introduction of the Q tag in the i18n draft will probably make
> it desirable to be able to specify
>
> Q { prefix = "«" -- left guilmet --,
> suffix = "»" -- right guilmet -- }
Those would be `insert-before' and `insert-after' from level 2, I
believe.
And now a few of my own comments:
- 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.
- 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.
- Something I've often though would be useful would be a way to say in
a style sheet, "don't accept settings of (this style parameter/any
style parameters) for this element from incoming style sheets". For
instance, I use the setting `A {text-background = light-grey}',
which I think looks nice against Arena's sandy-yellow background.
On the other hand, most people seem to use something like
`A {text-color = blue}', which mixes with my own setting and looks
pretty strange. I'd like to be able to say something like
`A {text-color = default !important}' so that the browser would
ignore A:text-color settings in incoming style sheets.
- Are `color' and `background' now aliases for `text-color' resp.
`text-background', or is this just a typo? I like this; using
`text-background' to set the background of, say, a table always
struck me as a little wrong.
- Thanks for the yacc grammar; that will be a great help.
-sbigham