W3C home > Mailing lists > Public > www-style@w3.org > September 1996

Comments on Working Draft 26-July-96

From: <lee@sq.com>
Date: Sun, 1 Sep 96 01:23:20 EDT
Message-Id: <9609010523.AA11247@sqrex.sq.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:53:45 GMT