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

Re: Comments on Working Draft 26-July-96

From: Bert Bos <bbos@mygale.inria.fr>
Date: Wed, 4 Sep 1996 16:57:57 +0200 (MET DST)
Message-Id: <199609041457.QAA16053@mygale.inria.fr>
To: lee@sq.com
Cc: www-style@w3.org
lee@sq.com writes:
 > Bert, thanks for replying in such detail.
 > A few clarifications, where my comments were not clear...
 > > there is currently almost no control over the way large initials
 > > align with the text.
 > I think if you specify number of lines rather than size, the language
 > is no more complex, but the result may look much better, as the intent of
 > the user is made explicit.  If you use a size, people will use sizes like
 > 58pt, knowing this generates a 3-line drop cap with the font they are using.
 > On another device, it may well not work properly...

We had that at one point. Something like it may come back again some

 > >>  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.
 > Sorry, I wasn't clear.  I meant to suggest allowing a string for a font
 > property to match, so that you can use Frederick Slanted or Lydian Cursive.

Now I'm confused. I haven't seen Frederick Slanted or Lydian Cursive,
but from the names I would assume the first one will have an
font-style of 'oblique', the second 'italic'. What do you need the
string for?

 > >  > 5.2.1 Font encoding
 > > 
 > > 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.
 > I think that would help a lot.

Done. A new draft should be ready in one or two weeks.

 > >  > 5.2.4 font-weight
 > [...]
 > > 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.)
 > If you're going to try and remove it by using the PANOSE numbers that are
 > available in some TrueType fonts, note that most of the fonts that are
 > sold in the design world today do not have them.  In other words, although
 > most font formats may support them, that's like saying that most forms
 > of transport do not use gasoline, so gasoline is not important in the world
  > economy.  Most fonts that are sold today for use in design are in the Type 1
 > format.  And that's where CSSn will have to make an impact if it is going
 > to be used in publishing.  Or that's how I see it, anyway.

PANOSE has a scale of 10, but it is a scale based on actual
measurements, rather than just an ordering. And as you say, not all
fonts have PANOSE numbers built-in.

We discussed this a lot with experts from several of the W3C member
companies, and the result was the nine-step scale of
TrueType/OpenType, for several reasons:

- nine weights seems to be enough for most fonts (there will be
  mechanisms for much more precise and more flexible font selection,
  for designers that want that kind of control, but it comes at a
  price: it will need more than just the CSS1 properties.)

- TrueType fonts for Windows & OS/2, and in all likelyhood all
  OpenType fonts, can be mapped to CSS1 properties trivially.
  OpenType is slated to be the new common font format, adopted by
  Microsoft and Adobe, and I've heard sounds coming from
  Bitstream that they have no problems with the nine-weight scale

- Fonts with other weight scales, or no weight scales at all (like
  Type 1) will have to be assigned a CSS1-weight manually, or maybe
  semi-automatically. I expect Adobe will be providing weight values
  for their fonts, when they start using OpenType.

- We added some heuristic rules to the explanation of font-weight,
  which can be used by CSS1 implementers to match fonts without
  weights in some simple cases. The heuristics are based on a list of
  the most common names for normal and bold.

 > >  >     (3) what happens if there is no bold weight, and the style sheet
 > >  > 	asks for one?
 > > It will be specified in the upcoming draft. Latest ideas are to use
 > > the normal font instead.
 > It might be better to allow artifical emboldening or a different colour.
 > > 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.
 > Again, the important formats at first are likely to be Type 1 on Macintosh,
 > followed by Type 1 on Windows, followed by other formats.  Since many
 > non-Adobe Type 1 font vendors explicitly forbid font embedding, and others
 > are changing their licence agreements to forbid it as soon as they hear
 > about the dangers of piracy, font substitution may well be used more than
 > one might otherwise have thought.
 > I realise that Microsoft's Internet Explorer is likely to be the browser
 > used by many or most people to test their CSS1 styles, but if you go to
 > a marketing or design agency, the chances are that they'll be using it on
 > the Macintosh.  Some of the design applications are migrating to Windows,
 > and the latest Fractal Painter actually shipped on Windows before Mac, so
 > things are changing, but it will take a while.
 > A lot of words, sorry.  I am not a Macintosh user myself, particularly,
 > but I think that Mac/Type 1 compatibility is very important in this area.

Font substitution is going to be very important, complemented by font
download. CSS1 sofar doesn't stand in the way, and CSS will eventually
use it, but we feel that trying to add a half-baked solution to CSS1
now can only harm us in the future.

W3C has a working group for fonts, that is working on these problems:


 > >> 5.2.5 font style
 > >>     You might have a font like Monotype Blado with only italic [...]
 > > Then it looks like Monotype Blado will have only one font-style: normal,
 > > and no italic or oblique.
 > Er, no, it only has an Italic.  It can be used with Bembo, for example.

I see. Automatic substitution of Blado in the middle of Bembo text is
not currently possible with CSS1, but you can ask for Blado
explicitly. If Blado only has the italic face, then it seems both
'normal' and 'italic' keywords in CSS1 will be mapped to that face.

 > >>     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.
 > I didn't realise tht the || meant something different from |, sorry.
 > How do I specify that within an H2 using small-caps, <em> is
 > to use italic, but within an H2 using italic small-caps, <em> is to
 > use normal small-caps?

Assuming this:

    H2 { font-variant: small-caps }
    EM { font-style: italic }

Then the new draft will allow you to do this for the first case:

    H2 EM { font-variant: normal }    /* No sc if EM is inside H2 */

and for the second case:

    H2 EM { font-style: normal }      /* No italic if EM is inside H2 */

 > > However, small-caps will be split off, leaving `normal|italic|oblique'
 > > for the font-style.
 > Oh, if that answers my question about h2/em, that's fine.
 > >     <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?
 > Yes, I did.

We now added that small-caps can be satisfied by three things:

   1. a `real small-caps' font (preferred)
   2. a `fake' small-caps font, with reduced and widened uppercase for
      the lowercase letters
   3. putting the text in uppercase (last resort)

 > >  >     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.
 > > 
 > oops, 10% wide should have read 10% wider, sorry.
 > >  > misc font:
 > >  >     Where do values such as Condensed and Expanded fit in? 
 > > These variants currently cannot be selected from CSS1.
 > Oh.  I think that's unfortunate, although maybe with OpenType that won't
 > be a problem any more?

It's not a problem with the font formats. We decided that the width is
more or less orthogonal to the other font selection properties
(family, size, weight, style, variant), so we would need an extra
property (font-width). It will probably be added, since it seems very
useful, even if the advanced font selection mechanisms propsed by the
Fonts WG will provide other means of getting at those fonts. But first
priority is to get CSS1 accepted.

 > >> 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.
 > God in the Details again -- I suggest using 0.3 em as an example word space.
 > >>   Most typographic software allows the specification of three values here.
 > >>   (1) minimum word space
 > >>   (2) preferred word space
 > >>   (3) maximum word space
 > > It's on our list for the CSS High-Quality Printing extensions.
 > Actually I think this should be done for the screen.
 > At the very least, change the word spacing example!  Word spacing that
 > is too wide reduces legibility, according to all the studies I've seen.
 > See Robert Bringhhurst or Colin Whieldon.
 > If not, at the very least you should not permit letter spacing to be
 > used for justification unless the style sheet calls for it.  A newspaper
 > might want to do this in order to use absurdly narrow columns, and give
 > that Authentic Look :-), but otherwise the single most important factor
 > in legibility is letter spacing.  (more important than word spacing).

But the best legible text is when the letter-spacing is not changed
at all, isn't it?

Saying something about allowing/disallowing letter spacing for
justification is a possibility. We'll see if we can add something to
that effect.

 > >> 5.4.2 letter spacing
 > > I'm not sure we need a property to turn automatic ligatures off. [...]
 > If you expect them to be automatic, then I suggest a note to the effect
 > that if display ligatures sich as ffi are used, the display agent should
 > normally suppress them if letterspacing is in effect.  Otherwise you get
 > d   i   ffi   c   u   l    t    examples.  You can't expect the author
 > to insert zero-width fillers here if the font on their system doesn't
 > have ligatures -- why would they think of it?

If they don't think of it, then they don't need ligatures to be
separated. It's only when they are talking about ligatures, that they
want to show the difference.

Putting in a word about the interaction of ligatures and letter
spacing may be a good idea.

 > >> 5.4.4 vertical align
 > > You think it would be useful to add a keyword for centering on
 > > capitals?
 > Yes, because it's useful to be able to include an image that's a decorative
 > bullet used like T  H  I  S (where  is centred on the cap-height, or
 > slightly above it).

Good example. We have to think about it, maybe for the next version of
CSS. For now, you can put the `THIS' in small-caps, then it will

 > >> 5.4.5 text transform
 > >>   On another note... I suggest adding `invert', converting upper to lower
 > >>   and lower to upper.
 > > We already have uppercase, lowercase and capitalize. Adding invert is
 > > no problem, but is it really useful?
 > It's useful with caps/smallcaps.  I don't know if there are any other uses.
 > Perhaps if you make the small-caps atomic, as you mentioned above, invert
 > wouldn't be needed at all.  It's probably not that important.

We added that small-caps should be shown as uppercase if no small-caps
are available (see above).

 > >>   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'.
 > It might be worth making that explicit.  I would have implemented it
 > differently, had I been writing code, and yet still been within the spec
 > I think.

Not in `the spirit' of the spec, and I doubt within the text, but
it's hard for me to judge. We'll see if we can add a line about this

 > >>   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.
 > Well, underline _thickness_ is clearly used for determining a border
 > thickness!  Cap height is used for a line hight in titling/headers.
 > An adjustment by ascender/descender height (as appropriate) is used in
 > optical balancing of headlines.  But perhaps that's for later.

We'll put it on our list.


  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 Thursday, 5 September 1996 13:08:49 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:26:41 UTC