> As always, comments are welcome.
By now, you're probably hoping I won't. :-)
Anyway, it's looking good. Here's what I noted:
- For lists, you say that "the label should use the font and color
properties of the list element to which it belongs." Wouldn't it
make more sense to specify a "label" pseudo-class for this. This
would allow you to say:
OL LI:label { font-weight: bold }
- For font-weight and font-size, I appreciate that you've moved from
absolute numbers to relative ones. I'm a little concerned,
though, that it may not be intuitive that a bare positive number
means an increase. I would suggest either requiring "1
larger/smaller" ("1 bolder/lighter") or requiring that positive
increments be prefixed by a plus sign ("font-weight: +2").
- For font-style, would it be worth adding as a value something like
"contrasting"? By this I mean the "italics if you're in roman;
roman if you're in italics" that LaTeX uses for "\em". This is
probably how I'd want to define <EM>.
- For color, I'd still like to be able to specify a list of options
(or hear an argument why this isn't a good idea). Especially if
you're allowing the possibility of multiple color models I can see
people wanting to say
.company { color: pantone(4231) indian-red dark-red black }
- for background, what are the intended semantics if multile URIs
are specified? I presume that the first acceptable one found is
used, but the spec should say.
- for bg-position, you explain what "0% 0%" and "100% 100%" mean,
but I still don't know what, e.g., "14% 84%" means. My best guess
is that the point 14% across and 84% down the image is to be
placed at the point 14% across and 84% down the element. If this
is so, the spec should be clearer. If it is not, then the spec
should *certainly* be clearer.
- for text-transform, could we note that the actual transformation
in each case is language (and UA) dependent. For example, whether
"=E9" uppercases to "=C9" or "E" depends on the language (or even the=
particular dialect: "fr-CA" vs. "fr-FR"). Also a browser will
probably want to have more complex rules for what "capitalize"
means. (e.g., in "en-US", I probably would have a list of words
("the", "a", "of", etc.) which would not be capitalized except at
the beginning of the element, or following a colon or open quote.)
- for text-align, we should note that the actual justification
algorithm used is UA (and language) dependent. A UA may justify
by increasing word spacing, by letterspacing (reasonable in some
languages), by stretching characters (common for Hebrew), and may
even hyphenate.
- is text-indent necessary anymore? Can't we just say
X:first-line { margin-left: 3em }
- for padding, you say "the color of the padding area is controlled
with the 'background' property". Wouldn't it be reasonable to add
a "padding" pseudo-class.
- for margin, what does "auto" mean?
- the width property takes a percentage, but the height property
does not. Is there a reason for this?
- for the specification of colors, we now allow "rgb 1.0 0.0 0.0"
with the note that "to have room for other color models in the
future, the 'rgb' keyword is required in the latter notation."
This implies that other color models may be added prefixed by a
similar keyword. Unfortunately, there is no way for a UA to know
how many parameters a particular model takes, so it cannot skip
over unknown values. I would suggest that the rgb specification
be changed to one of (in decreasing order of preference):
rgb(1.0, 0.0, 0.0)
rgb[1.0, 0.0, 0.0]
rgb(1.0 0.0 0.0)
rgb[1.0 0.0 0.0]
rgb:1.0-0.0-0.0
with the specification that a keyword will be followed by a value
contained in a balanced set of parentheses/brackets, not counting
those in double-quoted strings (for the first four possibilities)
or will be followed by a colon and delimited by whitespace (for
the last).
----
Evan Kirshenbaum +---------------------------------=
---
HP Laboratories |Now every hacker knows
1501 Page Mill Road, Building 1U | That the secret to survivin'
Palo Alto, CA 94304 |Is knowin' when the time is free
| And what's the load and queue
kirshenbaum@hpl.hp.com |'Cause everyone's a cruncher
(415)857-7572 | And everyone's a user
|And the best that you can hope fo=
r
| Is a crash when you're through