...
> As always, comments are welcome.
Here are mine, in no apparent order. First, overall, it's coming
along nicely.
But on to the nits and suggestions :-) :
o I think that it is going to be necessary to add at least
rudimentary numbering style for lists to level one. People keep
asking "how do I get unbulleted lists", "how do I substitute my
own URL for the bullet", etc. With HTML 3 now pretty much
officially dead, it is unclear when the extra attributes on UL,
LI, etc. will be added, and they clearly belong in a style sheet
anyway. Perhaps something like
number-form = uppercase alpha | lowercase alpha |
uppercase roman | lowercase roman |
decimal |
url : <url> |
char : <char>
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.
o I think that it will be important to allow specification by a
particular id even in level one. Perhaps something like
"TAG(id)". (This is unambiguous even with the current scheme,
because context sensitive definitions cannot have an
unparenthesized tag before a parenthesized one.)
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)".
o I'm a little unclear as to why "*" is a synonym for "HTML". I
realize that it was in the past, but we're already breaking all
old parsers by adding the braces. On second thought, I suppose
that it will be useful to be able to specify "*.CLASS". Is this
the reason for retaining it?
o I like the notion of allowing there to be a preset list of colors.
I'd encourage the draft to abstract colors in the same way that it
does font families. That is, attributes like "text-color" should
take a list of colors. This would allow specification of a set of
fallbacks:
text-color = pantone(542) firebrick #fe0705 dark-red red
o On the subject of colors, since lists tend not to be delimited,
there is a potential problem with the "3 number" rgb form.
Perhaps this should become "(255 0 0)" so that it could be seen as
one element.
o On the subject of preference lists, perhaps it would be a good
idea to add a delimiter, as
text-color = pantone(542) | firebrick | #fe0705 | dark-red | red
font-family = new-century-schoolbook | serif
o I'm not sure I see why definitions need to be punted to level 2,
and I see a considerable maintenance simplification by allowing
them. It would seem to be relatively straightforward to say
something like
define color important =
pantone(542) | firebrick | #fe0705 | dark-red | red;
and then say
text-color = $important
in several places. This would allow a single change if the
desired color changes.
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.
o There is syntax for "A.link" and there is syntax for "A.CLASS".
Is it possible to say "A.CLASS.link"? Perhaps rather than
"A.link", what we want is a pseudo *tag* "A-unvisited" and
"A-visited". The semantics would be that the "A-(un)visited"
attributes override the "A" attributes.
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".
o "font" is specified to include a "font-size". It would be useful
if this could be allowed to be a font-size-index (since the two
sets are disjoint, or would be if the index numbers were preceded
by a character such as "#"). This would allow you to talk about
font = large helvetica bold
o Come to think of it, since the sets are nearly disjoint, I don't
see any real reason not to dispense with font-size-index
altogether and just define font-size to take
<length> | #<number>| up <number> | down <number> |
xx-small | x-small | small | medium | large | x-large |
xx-large
This would get rid of the ambiguity that arises when both are
specified.
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.
o Since "text-line" became "text-decoration", the values "under",
"over", and "through" are unintuitive. Perhaps they should be
renamed "line-over"/"overbar", "line-under"/"underbar" and
"line-through".
o Also, text-decoration should probably allow more than one to be
specified, as it is reasonable to have boxed, struck-out text, for
example.
o For text-transform, "capitalize" should probably be "capitalized"
for symmetry with "uppercase" and "lowercase". Unless there are
other transformations you have in mind, this should probably be
changed to text-case taking "initial-caps | upper | lower | none".
Also, should there be a note here reminding implementers that such
transformations should be relative to the current value of the
LANG attribute. (Capitalization only makes sense with respect to
a particular language.)
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 -- }
o On the subject of prefixes, the fact that it looks as though
Netscape is likely to be about to unleash the ability to post HTML
usenet messages on the masses, it will probably be necessary to be
able to specify something like
BLOCKQUOTE { line-prefix = "> " }
o The set of generic font families almost certainly needs "fixed".
o In the "Level 1 ambitions" section, you talk about recommending a
"C" tag. The i18n draft introduces a tag for this purpose, called
"SPAN". It's primary use is to hold LANG and DIR attributes, but
it is expected to hold CLASS attributes when they are added.
So, did anybody make it this far?
----
Evan Kirshenbaum +------------------------------------
HP Laboratories |Voting in the House of
1500 Page Mill Road, Building 4A |Representatives is done by means of a
Palo Alto, CA 94304 |little plastic card with a magnetic
|strip on the back--like a VISA card,
kirshenbaum@hpl.hp.com |but with no, that is, absolutely
(415)857-7572 |*no*, spending limit.
| P.J. O'Rourke