- From: <lee@sq.com>
- Date: Sun, 1 Sep 96 01:23:20 EDT
- To: www-style@w3.org
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.
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.
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
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.
You should allow a string here as well as the fixed keywords.
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.
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.
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.
5.2.4 font-weight
This section needs re-writing, I think.
(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.
(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.
(4) I think you should allow a string as well as a fixed list of keywords.
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.
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.
There seems to be a typo with a || in the syntax.
Why can't I combine normal with small-caps???
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.
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.
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
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.
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.
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!)
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'.
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.
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.
``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.
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)
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.''
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.
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.
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.
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.
5.4.7 text indent
Why only the 1st line? Why not specify n lines? Seems a little
arbitrary, that's all. Not important.
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...)
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?
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).
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.
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.
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)
Relative units -- If you have xheight, why not also cap-height,
ascender-height, descender depth and underline-position?
It would also be convenient to have percentages of the display width
and height (i.e. the window or page size).
What about en (0.5 em)?
What about Fournier and Cicero Points for use in Europe?
finally, why on earth is pica spelt pc and not 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... :-(
I hope these comments help.
Lee
Liam Quin, lee@sq.com (Liam R. E. Quin)
The barefoot programmr
Received on Sunday, 1 September 1996 01:24:07 UTC