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
|problem.
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
Correct.
|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.
shadow
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?
normal
draw a frame using the color or pattern specified in border-color.
none
don't draw a frame, don't even use border-offset to indent the
text.
Note that `none' is equivalent to `normal' if border-width=0 and
border-offset=0.
|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
images.
| (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
--
Bert Bos Alfa-informatica
<[email protected]> Rijksuniversiteit Groningen
<http://www.let.rug.nl/~bert/> Postbus 716, NL-9700 AS GRONINGEN