Re: A nit and an addition for the current draft

Steve Grimm:
 |Bert Bos:
 |>The intention is that color names are entered as keywords without
 |>quotes. The reasoning behind this is, that, presumably, the number of
 |>color names is small, so they can be entered in the parser's hash
 |I think that's going to prove confusing to lots of people, since it's
 |inconsistent with HTML (or at least, HTML as widely implemented.)  In
 |an HTML document, I can write
 |	<img src=foo.gif>
 |	<img src="foo.gif">
 |and they'll be interpreted the same way.  That's the expectation people
 |will have of the style sheet syntax, it seems to me.

There are other places where it is convenient to differentiate between
identifiers and strings. E.g., in properties that expect a text, such
as insert-before and label, a string is inserted literally, but an
identifier is interpreted as a character entity (ISO or WWW):

  LI: label = "type " folder 1em

is interpreted as a literal text "type ", followed by the icon for
`folder' followed by 1em of whitespace. The fact that the three items
have different types is exploited here. Note that `folder' cannot
always be replaced with "&folder;", since it is unlikely that the
entity will be defined in any DTD other than HTML.

It may be possible to convert automatically between strings and
identifiers in some contexts, but in general I think that automatic
conversions may be nice for simple expressions, but they cause trouble
as soon as you start writing more complex things. Have you never had
trouble with C converting floats to integers or vice versa?

For the background color it may be possible to allow strings and
identifiers interchangeably, if we split text-background into
text-background and text-background-url. Benjamin Sittler had a nice
idea about this:

Benjamin Sittler:
 |I think that background colors and images should not exclude eachother... 
 |instead, background images with "transparent" regions should show the 
 |background color in those regions, so that the above CSS could lead to 
 |white snowflakes on red as the background. This would seem to resolve the 

We'll have to check if colors and URL's can always be separated. Some
thinking to do here.

 |>For inline images, there is currently only text-line (provisional
 |>name). We forgot to specify that `border' applies to included material
 |>as well. This should be fixed.
 |Am I correct in assuming that it's intended to be used like this?
 |	(a) img : border-style = none


 |If so, I don't like the "normal" value of border-style, since what's "normal"
 |is context-sensitive.  Maybe "minimal" instead?

No, `normal' is not context sensitive. I'm afraid the explanation of
the border-* properties is rather incomplete. We wanted to keep the
document short and we hoped people would be able to guess what the
values meant. Here is some more info:

  raised, lowered, beveled, etched
    these cause 3D effects, using lighter colors on one side and
    darker ones on the other, like in Motif.

    another kind of 3D effect, using a drop shadow at the bottom and
    right side. We haven't specified exactly how the frame looks,
    e.g., does it use border-color or border-width?

    draw a frame using the color or pattern specified in border-color.

    don't draw a frame, don't even use border-offset to indent the

Note that `none' is equivalent to `normal' if border-width=0 and

 |In any case, I don't have a problem with it being supported under level 2;
 |my guess is that most browser writers, when they add stylesheets to their
 |browsers, will do all of level 1 and much of level 2.
 |>Btw. is a line break allowed before/after an image?
 |Unless it's in a <p nowrap>, I'd say yes.

But on the other hand, while we're waiting for Unicode, people might
want to use images as characters.

I've suggested some time ago that HTML defined another entity
(something like &sbsp; `soft break space'), equivalent to the
zero-width space of Unicode and the <wbr> element of Netscape. That
would give authors explicit control over breaking lines between

 |  (BTW, am I correct in thinking
 |that there's no nowrap attribute for anything but paragraphs in HTML 3?)

There's a nowrap attribute on P, H?, BLOCKQUOTE/BQ, DIV, TH, and
TD. Hakon and I haven't yet been able to agree on the equivalent
property in CSS. Any suggestions?

                          Bert Bos                      Alfa-informatica
                 <bert@let.rug.nl>           Rijksuniversiteit Groningen
    <http://www.let.rug.nl/~bert/>     Postbus 716, NL-9700 AS GRONINGEN