All good changes.
> Currently, I'm working on incorporating more of the comments from this
> is (especially from Evan) as well as the feedback from the
> workshop. The document is likely to split into two: level 1 and level
> 2. The first of will be submitted as an I-D ASAP.
>
> Changes that we are considering in level 1:
>
> - dropping context sensitivity: this will lower the threshold for
> implementors as well as keeping the syntax open.
I don't think that this is a good idea. The implementation overhead
isn't *that* great, and people are going to want to distinguish things
like EM within H1 from EM within P. (I still recommend that the syntax
be changed from "(H1)EM" to something like "H1::EM" or "H1/EM",
though.)
> Lists can be
> discribed using a new-non-inherited property, list-style, that
> applies only to the children of the element:
>
> OL { list-style: upper-alpha }
> UL { list-style: "red-bullet.gif" }
I think that something like this is needed. I still lean toward the
template notation I suggested before ["%a. ", "%1)", "(%A)"], as it
allows specification of the punctuation to go around the numbering as
well.
> - replacing "," with ";" as the declaration delimiter -- it matches
> the '{}'s better
Please do. This will make it easier to use comma separated lists in
values.
[other good suggestions deleted]
> As always, comments welcome.
Since you asked...
o I'd recommend that comments be changed to terminate on EOL.
HTML has shown that it's tricky to try to get people to worry
about the parity of the number of dashes. At the very least you
may want them to start with "--<ws>" and end with "<ws>--".
Languages with EOL-terminated comments tend to be easier to
develop in, since you can more safely comments out blocks of
code which contain comments. This is especially true when the
same delimiter is used for both the start and end.
o I like the notion of allowing specification by class independent
of tag, but you run into two problems by using the same notation
for both classes and tags: 1) the set of tags will grow over
time and may collide with user-defined classes in legacy
documents, and 2) classes are not (IIRC) restricted to being
single tokens. That is, <P CLASS=3D"Important Stuff"> is legal.
Since you are already allowing [ID=3D"abcd"] in level one, why not
just use the same mechanism and say that [CLASS=3D"Important
Stuff"] is level one as well?
o I don't like the fact that the document's "important" assertion
is to be given more weight than my "legal" one.
o I still think that color needs to take a precedence list, and
I'd say the same for background. There will be clients which
can change color but not import a background, and it should be
possible to say
background: "bg.gif" dark-blue
o I like the collapsing of font-size-index into font-size. Is
there any reason to retain "<number>" as one of the possible
values? Since you're not even keeping the Netscape range of
0..7, with 3 being "medium", it would seem that the enumerated
tokens would be sufficient. I'd certainly recommend adding
"[<number>] larger | [<number>] smaller" to the set of possible
values, though. You might also want to put a note to the effect
that an implementation may (or should?) refuse to go larger than
"xx-large" or smaller than "xx-small".
o font-family needs a generic value of "fixed" or "typewriter" to
handle PRE and TT. Alternatively, perhaps font-spacing with
values "fixed" and "variable".
o For font-weight, I am again not sure what value the number is
playing, and I would suggest "[<number>] lighter" and
"[<number>] bolder".
o For bg-style, I like the idea, but I am uncomfortable with a
value that begins with "x-", as that space is generally reserved
for experimental extensions. Perhaps "repeat-x" and "repeat-y"?
o I think I've figured it out, but perhaps it would be a good idea
to put in some words explaining the interaction between
font-leading and text-spacing.
o text-decoration should probably be multi-valued, as, e.g.,
"blink" and "line-through" seem as though they could peacefully
coexist. I'm also not sure why the color of the decoration is
based on the color of the text. (aside: what do you mean by
"based on"? the same? contrasting?) I see that the common case
may well be to have text and decoration the same, but consider
P {color: black}
EM {color: red}
[class=3D"so"] {text-decoration: line-through}
<span class=3Dso>Here is some <em>struck out</em> text</span>
I don't think that it makes sense for the line to change color
for the emphasized words. On the other hand, I can see wanting
to say that "this style has words struck out with a red line".
Perhaps, at least it should be specified that when the
text-decoration is inherited, its color is inherited as well.
o What does the <number> in text-position mean? Perhaps allowing
"sub" and "sup" to be followed optionally by <length> or
<percent> might make more sense.
o I'm a little uncomfortable with "text-transform: capitalize".
The only place that I can really see it being useful is in
contexts like <CITE class=3Dbook>, but even here not *all* words
get capitalized. (Short words like "of" and "the" tend not to,
unless they're at the beginning of the title, or the beginning
of an embedded quotation, or ...) Also, in multi-lingual
contexts, the notion of what is a word is problematic. I'd
recommend just sticking with "uppercase", "lowercase", and
"none". Even these can be troublesome, as, for instance, I
believe that French French capitalizes "=E1" as "A", while
Quebequois French capitalizes it as "=C1". What exactly is the
rationale for this attribute?
o text-effect would seem that it could reasonably be multi-valued,
as "drop-cap" and "alt-firstline" work well together, and indeed
are often seen together in print. Of course, this opens up the
problem that they both reference the same properties (alt-font,
etc.) Perhaps these should be changed to "cap-font", etc. and
"first-line-font", etc. The same question arises for the font
used for the numbers referenced by "list-style" and will be for
"insert-before", "insert-after" (and their needed cousins
"before-line" and "after-line"). Perhaps some more general
mechanism should be designed at this stage.
o Also, the discussion of text-effect talks about "the first
alphabetical letter". Leaving aside the question of what a
non-alphabetical letter might be (you probably meant
"alphabetical character"), this leaves open the question of what
a browser is supposed to do with
[class=3Ddc] {text-effect=3Ddrop-cap}
<p class=3Ddc>15 June 1968 was my brother's birthday...
<p class=3Ddc><q>What?</q> asked Alice...
----
Evan Kirshenbaum +---------------------------------=
---
HP Laboratories |Politicians are like compost--the=
y
1500 Page Mill Road, Building 4A |should be turned often or they st=
art
Palo Alto, CA 94304 |to smell bad.
kirshenbaum@hpl.hp.com
(415)857-7572