- From: Bert Bos <bbos@mygale.inria.fr>
- Date: Mon, 2 Sep 1996 21:55:18 +0200 (MET DST)
- To: lee@sq.com
- Cc: www-style@w3.org
lee@sq.com writes:
> Comments on WD-CSS1-970726 by Liam Quin -- personal contribution
> These comments do not reflect the position of any organisation.
> I am sending them to www-styl@w3.org, as requested in the Abstract.
Thanks, Lee. Your comments certainly help. Many of the things you
mention are typos or unclear formulations. We will try to correct them.
Many of the other issues, especially those related to fonts, have been
discussed in the context of the HTML ERB, and I think you will find
them resolved in the forthcoming draft.
Other issues could be the subject of future extensions.
>
> They reflect the latest publicly available version of CSS1 up until we
> moved office and lost WWW and ftp access :-)
>
> Lee
>
>
> 1.4 Class as Selector
> In the example
> .punk { color: green } /* all elements with CLASS green */
> does this not select elements with CLASS="punk" rathr than "CLASS=green"?
> I think the comment is wrong.
OK.
>
> 2.4 The first letter pseudo-element
>
> Note that font-size 200% is not correct for a 2-line drop cap.
> The baseline of an n-line drop cap must align with the baseline
> of the nth line of text; the cap-height of the drop cap must align
> with the cap-height of the first line of text.
> Since the relative proportion of cap height to font size depends on the
> actual font, you can't specify a point size for an initial drop cap in
> advance.
>
> I suggest using (for example)
> font-size: 3 dclines
> or, better,
> drop-cap-lines: 3
Yes, there is currently almost no control over the way large initials
align with the text.
>
> In the paragraph beginning
> The UA defines what characters... Normally, quotes that precede the
> first letter should be included
> note that it is normal North American and UK trypesetting practice
> to drop a leading quote mark before an initial cap, or to keep it in
> the smaller size. (this was discussed on TYPO-L or TYPETALK recently,
> by the way -- I forget which).
>
> It is considered an error to make the leading quote large except for
> a pull-quote, where both leading and trailing quotes must be large (and
> the same size as each other!).
>
> I cannot comment on the practice in other parts of the world and other
> languages and scripts.
>
>
> 5.2 Font properties
>
> ``The term italic is not appropriate for sans-serif fonts''
> Note that there are in fact sans serif fnts that have a true Italic;
> the `a' `f' and `g' letterforms in particular are usually very different.
> I suggest
> ``The term oblique is used to designate a face that is derived by
> a shear transformation from another face; this transformation is
> usually accompanied by hand editing to make optical corrections.
> Many sans-serif fontshave an oblique face instead of an italic.''
> Some fonts (e.g. Bitstream Lydian) may have a Cursive as well as an Italic.
The next draft will have more precise wording.
> You should allow a string here as well as the fixed keywords.
The font name cannot be specified in CSS1, only the family name and
the font properties. The name of the font has been kept out on
purpose. You cannot split a font name into family name, style name and
weight name, since in general font names aren't constructed that
way. CSS1 only uses the family name and the abstract font
properties. That does impose some restrictions, such as if a font has
two different italics, you can only get one. Extensions are being
worked on at the moment in the context of the Fonts WG, but they are
not as simple as allowing more values on the CSS1 properties.
>
> 5.2.1 Font encoding
> Note that if you allow arbitrary font encodings, you will make it so that
> a web page becomes unreadable and unsearchable if it uses a non-default
> encoding. Unicode, ISO10646 and SGML entities would all be preferable.
> See the HTML Internationisation draft...
> Perhaps this is what this section is trying to say -- it would be clearer
> if instead of saying what not to do with Symbol, it said how one is
> supposed to access the Greek letters.
Unreadable Web pages is exactly what this section tries to avoid. If
that is not clear, than we do indeed need a better example. I'll see
if I can add the complementary example: how to get Greek text.
>
> 5.2.3 Font Family
> The font family name Zapf-Chancery should actually be Zapf Chancery.
> There is no hyphen in the name; some computer systems require one
> for historical reasons, but the transformation is automatic, and on
> most such systems the hyphen is replaced with a space in font menus.
OK
>
> Last paragraph -- If you want to get taken seriously by the
> pre-press industry, don't say that Helvetica looks almost identical
> to Univers!! They are closer to each other than Univers and Times.
But they do look similar, don't they? We can change that sentence.
>
> 5.2.4 font-weight
>
> This section needs re-writing, I think.
It's been extensively rewritten for the next draft.
> (1) it isn't really practical to map existing font families to the
> list of nine names given here.
> Font families don't have nice regular sets of names.
Not names, no, but most families do have different weights and most
don't have more than nine (another restriction in CSS1 that the Font
WG will remove). (Btw. the draft you're looking at only has seven, the
next will have nine.)
>
> (2) What do you do with a multiple master font that has a continuous
> spectrum of weights, such as Adobe Jenson or Tekton?
> You should allow a numerical weight value in that case -- perhaps
> a floating point in the range 1 to 9.
>
> (3) what happens if there is no bold weight, and the style sheet
> asks for one? Is `an approximation strategy' to use <blink>,
> or to use another font, or to use smearing or artificial emboldening?
> This needs to be specified further, I think.
It will be specified in the upcoming draft. Latest ideas are to use
the normal font instead.
>
> (4) I think you should allow a string as well as a fixed list of keywords.
See above.
>
> Short of inventing a new font format, it won't be possible to
> determine an automatic ordering for weight -- especially for Type 1
> fonts, which is most commercial high-quality fonts today in practice.
> And the weight can currently be any string -- some of them are
> cute little jokes, and some are simply incompatible, but that
> should not mean that the font can't be used.
>
> I don't mean to imply that TrueType fonts are necessarily of low
> quality, by the way -- Ariel, for example, probably has unsurpassed
> technical quality. But the publishing and pre-press worlds mostly
> use Type 1 fonts today, and most commercial fonts sold by major
> vendors are in Type 1, or Type 1 and TrueType, not just in TT.
The CSS1 properties of TrueType fonts (at least those for OS/2 &
Windows) can often be determined automatically. For other fonts
somebody (or a program loaded with heuristics) will have to provide
the information.
>
> 5.2.5 font style
>
> Note that font style and weight are not entirely orthogonal.
> You might have a font like Monotype Blado with only italic, or one like
> Poliphilus with roman and italic but no bold.
> Many fonts with small caps (or companion Adobe Expert Sets) do not
> have small caps in the italic face, but some do.
Then it looks like Monotype Blado will have only one font-style: normal,
and no italic or oblique.
The new text will split small-caps from italic, and give rules for
each what to do if the style is unavailable. Electronic slanting is
allowed.
>
> There seems to be a typo with a || in the syntax.
> Why can't I combine normal with small-caps???
It's not a typo, you can really only have either normal, or one or
more of the others. Normal + small-caps is a contradiction.
However, small-caps will be split off, leaving `normal|italic|oblique'
for the font-style.
>
> Note that small cap fonts usually map lower case letters to
> small caps, and upper case letters to capital letters, so that you
> can do CapsWithSmallCaps. Hence, if there are no small caps
> available, the user agent should map lower case letters to
> artifically generated small caps, and leave upper case letters
> unchanged.
Our `small-cap' means what is sometimes referred to as
`caps-and-small-caps'. That means that one expects uppercase to look
the same as in the roman fonts, while lowercase shows different
glyphs.
>
> However, it is also useful to be able to say that if no small caps
> are available, a given string is to be set in capitals. For example,
> HTML should be set in small caps, but if there aren't any, it would
> not be appropriate to use `html'.
>
> I suggest that in addition to small-caps, you have caps-small-caps,
> which uses MixedCase as I have described; small-caps would then turn
> lower case to upper case if there were no small caps available.
> For example, a text browser can't fake small caps, and neither can
> a Braille printer. But see under 5.4.5 below for another approach.
That's a good point. I've been using the following construction
myself:
<acronym>HTML</acronym>
ACRONYM {
text-transform: lowercase;
font-style: small-caps }
but the danger is that one property may be working while the other
fails, leaving exactly the wrong result in the output. A way of
ensuring that the two operations are interdependent seems called
for. I think you interpreted `small-caps' to be that atomic operation?
>
> Good algorithms for generating small caps from a normal face are
> * make the cap height be the same as that of "i", or set it to
> the x-height + 1/3 of (cap height - x height).
> Note that ascender height and cap height are significantly different
> for Old Style (and some other) fonts.
>
> * make the letters 10% wide
Something like that will explicitly be allowed in the new text.
>
>
> 5.2.6 line height
>
> It is very useful to be able to associate line height with an inline
> element. There are three cases:
> (1) vertical space before (above the fist line containing the
> start of) the element
> (2) vertical space within the element, if it spans multiple lines
> (3) vertical space after the last line of the element.
>
> In cases (1) and (3), the space used should be the maximum of all
> that apply.
>
> This is useful, for example, for a superscript.s, to say that if the
> prevailing vertical line space is less than a certain amount, extra space
> must be added to make room for the superscript.
Yes, line-height will be changed to apply to inline elements in the
upcoming draft.
>
> misc font:
> Where do values such as Condensed and Expanded fit in? (Condensed means
> that the font is a narrower version than normal; sometimes this is done
> `mechanically" (algorithmically) as with Apple's old corporate font,
> Garamond Condensed 80%. Sometimes it is done optically, as in the
> redrawn version, Apple Garamond). Expanded means wider, except of
> course for Century Expanded, where it means that for a given size,
> the letters are taller, so it's basically the same as condensed. But
> for all other fonts I'm aware of, Expanded means it's been made wider.
These variants currently cannot be selected from CSS1.
>
> There are a number of other properties that are useful:
> outline (like PostScript false charpath stroke)
> inline (also sometimes called Engraved)
> shadow (although this is best done by the renderer with a different colour)
> swash (e.g. Caslon Italic Swash Caps, good for drop caps!)
Ditto. I expect some proposals from the Font WG for the next version
of CSS.
>
> In X Windows, these usually get put into the `added style' field; for a
> Type 1 font they're usually tacked on to the font name somewhere, but
> they are syntactically distinct from the family.
>
> I would suggest that they be allowed in 5.4.3 `text-decoration'.
Text-decoration is not part of the font-selection mechanism. It is
used to add lines, blinking, maybe shadows, and other effects that are
independent of the font. (I know that the Mac allows fonts with
built-in underlines, we don't handle those.)
>
> 5.4.1 word spacing
>
> A percentage of the default would be a good thing to have available here,
> inherited as for line height. Note that 1 em is a very strange value
> for word spacing -- 1 en would be a better example.
>
> Most typographic software allows the specification of three values here.
> (1) minimum word space
> During justification of a line, you can cram as much as will fit on
> the line until you get the word space down to this value --
> but no more!
> (2) preferred word space
> Use this whenever possible
> (3) maximum word space
> if justification would increase the word space beyond the maximum,
> the line should be set quad left (left-justified, right-ragged)
> using the preferred word space.
It's on our list for the CSS High-Quality Printing extensions.
>
> 5.4.2 letter spacing
>
> This ties in to two other areas.
> (1) tracking: the amount of letter spacing should vary on the point size.
> It would be nice to specify this automatically...
> especially as the actual point size used may not be what the
> style sheet editor expected.
> (2) ligatures: I haven't noticed these being discussed, but naturally
> if you have an fi ligature, it should be used. You might say that
> HTML documents don't need ligatures, but if you let the pre-press
> community use fonts, they will use ligatures by embedding the
> character codes in the documents (as is done with Quark today, for
> example) unless there is proper support in the spec.
> Automatic ligatures must be disabled if letter spacing is used.
> There should be user-level control for disabling and enabling of
> automatic ligatures. I hope OpenType will do a better job of
> specifying ligature maps than Type 1, where apart from fi and
> fl, the applications have to guess that ssi is a ligature in
> Caslon Alternates, for example.
Unicode has a few ligatures, unfortunately. There is probably a reason
why they have to be in there, but in general they should not be
used. Ligatures should be automatic, and as far as I know OpenType has
all the needed information. That's the only way to ensure that
ligatures will be used when possible, and not used when letter-spacing
is non-zero, or when hyphenation is turned on.
I'm not sure we need a property to turn automatic ligatures off. If an
author wants to ensure that two letters are not combined, he can put a
zero-width-non-joiner in between. Turning ligatures off doesn't seem
very useful as a style (unless the style is `simulate poor
wordprocessor output'.)
>
> ``The letter spacing may be influenced by justification'' -- possibly,
> I suppose. In German typesetting, letter spacing is sometimes used
> to indicate emphasis. If you allow letterspacing to be used for
> justification, please make it explicit: you need minimum, preferred
> and maximum letterspace ammounts.
We didn't want to go into too much detail as to what the formatter is
allowed to do to justify lines. E.g., OpenType fonts can have tables
that replace letters by other letters, if that makes the justification
easier. But requiring that info to be used would be asking too much of
many browsers. It would also slow down the formatting.
>
> 5.4.4 vertical align
>
> middle... half the x-height
>
> Why not half the cap-height? This seems a little arbitrary; why not
> provide both middle and MIDDLE? (assuming the values are case sensitive!
> I can't see anything about that anywhere, although obviously
> element and class names can't be if they're SGML NAMEs)
Values are case-INsensitive in CSS. I think we already added that to
the upcoming draft.
You think it would be useful to add a keyword for centering on
capitals?
>
>
> top and bottom... unresolvable
>
> how should the formatter indicate the error? how should the
> unsolvable situation be resolved?
> I suggest adding:
> ``in such cases, the UA may choose to ignore any or all conflicting
> alignment values; a suggested resolution is that the values be
> removed one by one until a resolution is possible. The order
> of such removal is unspecified. An error-checking UA should
> alert the user to the error.''
Does this change anything? It is only suggested behaviour anyway.
>
> 5.4.5 text transform
>
> How do capitalise and uppercase and lowercase work with respect to
> internationaliation? This is a function of both script and language --
> e.g. consider the undotted I in Turkish, which looks like "I",
> but when converted to lower case is an i with no dot.
>
> You say it's human language and UA dependent, but there must be a way of
> specifying language for that to be helpful, it seems to me.
We assume the formatter will know the language through some
unspecified channel. The language may come from the HTTP headers, or
from the LANG attribute in HTML.
We are aware that uppercase and lowercase may be hard to implement
correctly for all languages (which is another way of saying that the
reader may be surprised once in a while). E.g., in French it is common
to omit the accents from uppercase letters; how is the formatter going
to add the missing accents without resort to AI?
>
>
> On another note... I suggest adding `invert', converting upper to lower
> and lower to upper. This is useful in conjunction with small caps,
> so that you can give text in UPPER CASE for the case that there is
> no small caps font, or if the browser doesn't use styles, or for
> search engines, but, if small caps are used, you need the text to be in
> lower case to turn into small caps in a true small caps font.
We already have uppercase, lowercase and capitalize. Adding invert is
no problem, but is it really useful?
>
> 5.4.6 text align
>
> Actually a percentage does apply, at least in some systems.
> It is a percentage of the line length (prevailing measure, including
> indent). Lines are to be left justified unless they are longer than
> this amount, in which case they are justified.
I know, and ideally we also want control over how much spaces are
stretched in non-justified text, plus control over the alignment of
the last line of a paragraph. But for CSS1 this would be a bit too
much. No reason to exclude it from future extensions, however.
>
> There is a corresponding negative percentage for doing right
> justification.
>
> How do left and right justification work for Hebrew text, or other
> right-to-left languages? Are they interpreted backwards? I assume so.
In general, left means left and right means right, so left-aligned
Hebrew text would be just that: left-aligned text. It doesn't change
its meaning to `end-aligned'.
>
> 5.4.7 text indent
>
> Why only the 1st line? Why not specify n lines? Seems a little
> arbitrary, that's all. Not important.
Another thing we left out of CSS1. There must be something left to add
later...
>
> Question:
>
> How can I get the book/magazine style chapter opening where the first
> 3 words, or the 1st half of the 1st line, are in Caps-Small-Caps, after
> an initial drop or raised cap?
> I can achieve the first three words case with explicit markup, of course,
> just as I could with a DSSSL expression. The latter case is generally
> done now (quite often too) with a table and <FONT SIZE=2> and caps.
> But it is non portable, confuses search engines and Braille converters,
> and is screen-size-specific (resize your screen to this width...)
I'm not sure there is actually a style sheet for any magazine that
says: capitalize the first three words. I'd think it was more
something like: capitalize the first few words. The result would
depend on whether the editor thought 2, 3, 4, or even 5 words looked
the best.
We haven't considered any way of addressing the content of elements
word by word or even letter by letter (except for two exceptional
cases: first-letter and first-line). It's hard to know how much this
capability is needed, but our current estimate is that it won't be
too much of a problem to rely on extra mark-up in the document
instead.
>
> 5.5.3 border-url
>
> Why only 1 image and not 8? Most border fonts have 8 characters that
> are used for the border -- one for each corner, and one for each side.
> For that matter, why can't I specify a font and a string?
Using characters for the border is a whole different model. Using 8
images is quite possible but again something for the longer term.
>
> 5.5.4 width
>
> Any reason (apart from complexity) not to support cropping (truncation)
> of images? Need to give an origin of the copped, visible rectangle,
> I suppose. Well, OK, then people would want oval vignettes, etc...
> But you could also transmit a single image, and use different parts
> of it at various parts of your document, dramatically reducing
> download time (only 1 image header, only one HTTP connection, and
> maybe overlapping parts).
The HTML ERB is currently discussing a proposal to do just that,
including the ovals. It will not be part of CSS1, but probably of the
next version.
>
>
> 5.6.1 display
>
> block/inline/list-item/none
>
> `the last rule turns the display of images off'
> Can I replace an IMG with the contents of the ALT attribute,
> but have the ALT text block formatted?
>
> This rule doesn't seem to be the same as `turn images off' in most
> browsers at all, because of the treatment of ALT text. Or do you
> mean to imply that if visibility is none, the contents of the elemnt,
> or the associated image if there is one, should be replaced by the
> contents of that elemnts's ALT attribute? If so, how does one disable
> the ALT text from the style sheet? Is ALT to be inspected only for
> IMG elements, or for all elements? Please clarify.
Something that we wanted to do, but this also has to wait. Introducing
a special property just for turning on ALT seemed the wrong thing to
do. We'd rather delegate this feature to the HTML parser for now and
in the meantime work on a more general solution for dealing with
attributes.
>
> 5.6.2 list-style
>
> Note that `disc' (or `disk' in North America) is not the same as
> `bullet', as a bullet in a condenssed or italic or oblique font is
> not circular!
>
> One should be able to specify a character from a font at a given size
> and weight, together perhaps with ALT text.
Yes, also on our list of future extensions.
(I've seen `disc' in American texts as well, including in Netscape's
attributes. Are you sure this a British versus American distinction?)
>
> 6.1 length units
>
> ``Child elements inherit the computed value, not the relative value''
>
> Except for line spacing (and word spacing and letter spacing if you
> allow percentages there)
Line-spacing does inherit the computed value (it has a numerical
factor as well, in case you want to inherit the relation, instead of
the value). For word-spacing and letter-spacing we would have to look
at this rule again.
>
> Relative units -- If you have xheight, why not also cap-height,
> ascender-height, descender depth and underline-position?
I don't think they are used for determining the thickness of a border,
the size of a margin, etc. like ex is.
>
> It would also be convenient to have percentages of the display width
> and height (i.e. the window or page size).
On rereading, it seems to be less clear from the draft than we
thought... The intention is that the `canvas' is the parent of the
HTML element with respect to the width. The canvas height is not
accessible in CSS1.
>
> What about en (0.5 em)?
No real problem, but since 2en=1em, en doesn't seem to add much.
> What about Fournier and Cicero Points for use in Europe?
Most countries recommend using SI units instead, but it is true that
these units are still used. We can add them easily, of course,
although it may add some confusion (3 different points, a pica and a
cicero, aka augustijn). Will anybody implement them?
>
> finally, why on earth is pica spelt pc and not pica/picas?
I remember that we allowed both pica and picas earlier, but then we
dropped all alternative spellings for 2-letter units. Unfortunately,
there seems to be no abbreviation for pica that is universally
accepted. I've seen both pc and pi. We could drop pc and allow
pica/picas...
>
> 6.3 colour units
>
> Why not allow #AABBCC as per HTML today? This would to be very
> convenient for people making style sheets to match existing HTML
> documents. I can see a market for little hex --> decimal conversion
> utilities coming, though... :-(
Ah, you're looking at the damaged version of the document. As soon as
your connection is open again, try re-loading it. Hex colors are
definitely allowed.
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/pub/WWW/People/Bos/ INRIA/W3C
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 93 65 77 71 06902 Sophia Antipolis Cedex, France
Received on Monday, 2 September 1996 15:55:50 UTC