W3C style sheet workshop Paris '95
Author: Bert Bos
Day 2 (7 Nov)
This report is based on notes taken during the workshop.
There is also the original
agenda, a list of
participants and a report on
- CSS core syntax
- Media type
- The STYLE attribute
- Other issues
Creating a list of possible discussion subjects wasn't very
hard, but dividing the people into small groups proved
impossible. Chairman Steven Pemberton soon came to the
inevitable conclusion: there was a small number of topics that
everybody wanted to talk about and so the discussion was
conducted in the large group.
Subjects that were suggested but for which there was no time
included: speech, the user interface of style editors, and a
common model with DSSSL.
Note: the texts below are not a
literal transcription of people's words.
The proposed list of discussion topics relating to the CSS core
- counters & numbering style
- selector expressions (`left-hand side')
- declarations (`right-hand side')
- multiple presentations
- visual constraints
- destructuring property names
- the STYLE attribute
- class as selector
- terminology for directionality
- formatting model
- link styles
- environment variables
- <C> tag
- color names
- interaction, user events, cursors
- We increased the priority for author's
style sheets. E.g., the author's `!legal' now overrides the
reader's. The reader can only turn style sheets off.
- Can the author specify what may be
modified? The `user lens' is still important, but should it
require the user to turn off the style sheets first?
- The RHS should be more powerful, because the LHS
is not enough; it won't scale.
- E.g., we may want to change font in the middle
of generated text, such as a label.
- The model of the boxes is too complex, there are
too many margins. Do we need reference axes as in P?
- Designers may need axes like that.
- The terminology for margins isn't clear. Maybe
`offset' is better called `padding'?
- The side heads as they are shown in the draft may
- Where does `align=left' go? In other words: where
do floating images go and in which order?
- Using pseudo-classes is a bad idea, because it
is ambiguous. You may need a special syntax.
- It's a hack for level 1.
- Using class as a selector is also ambiguous in
the current syntax.
- What would an ambiguous class selector enable me
- The `*' is confusing: is it a wild-card for
everything or just for the top level?
- Most people find it confusing.
- People will know that `HTML' is the top level,
even if they don't have <HTML> in their document.
- OK, let's take `*' out.
- Please take out the class/GI ambiguity as well.
[Discussion about what the (original) intention of class is.]
- `Class' is meant to create a subclass of
an element. Multiple classes on an element indicate a sort of
multiple inheritance, not a hierarchy of classes.
- The hyphenated property names are ambiguous, too.
I suggest using underlines instead of dashes.
- But `-' is an allowed name character in HTML,
while `_' is not. For consistency, it is better to keep the
- I would like a method to address letters and
words from the style sheet, e.g., apply a style to the first
- It soon becomes too complicated.
- Structuring the property names may help:
partition the names into meaningful parts: line.font.family is
the family of the font in a particular line.
- But it is still the same number of properties,
whether you view them as a hierarchy or not.
- Not necessarily, you could introduce
`line.5.*.font.size' to mean the font size of all parts of the
- The `alt' properties are too limited. Styles for
labels, insertions, etc. may be different from each other, so
more structure is needed there, too.
- I can write something up about my implementation
and e-mail it.
- Complex inheritance is difficult in practice.
Explicit assignments are easier.
- To make labels and insertions more
powerful, we could allow the generated text to insert HTML
elements. But I would like to know, is level 1 already too
- HTML is so flat, can't we limit ourselves to
selectors without ancestors?
- Context sensitivity is needed, even in HTML.
E.g., the effect of CENTER as Netscape uses it is very
- We will have a new draft incorporating
these discussions by the end of the year. It will be a W3C
working draft. Do we need a review board?
- What sort of things can we specify about
graphics: spacing, scaling & scaling methods, which
graphic or color is the most important, etc.?
- And offsets and overlays.
- Do you actually change the graphic? E.g.,
- I want tinting, re-use of images, maybe rotate
(90°ree; only, but it's still expensive!). I also want to
take the colors out and then retint the gray scale.
- There are hundreds of possible operations.
- I also want images to change when a link has been
- And gradients.
- Image enhancements can be postponed and done only
when there is enough time.
- Visual transitions between pages would be nice,
maybe even small animations.
- I would like to be able to name and group images
and manipulate them together. Controlling the transparency is
important as well.
- To get consistent color across platform, we need
at least a consistent gamma correction built into the browser.
We need chromaticity as well.
- `RGB' should mean the light intensity, not the
- But all this must be transparent to users.
- Do we need exact colors?
- Just the ISO colors should go a long way.
- The draft should have a list of the color names
that are recognized by CSS.
- The fall-back mechanism of CSS can be used to
give a list of device specific colors for all platforms.
- Colors specified as percentages are easier than
hex or even 0.0-1.0.
- Is it possible to use `@define' to name a color
and make the `@define' dependent on the media type?
- currently definitions are global; this
would complicate the language.
- Controlling the load order of images is a way to
get the colors you want.
- But how about concurrent connections?
- I would like to have control over the dithering
patterns and to be able to turn dithering off.
- You can't change dither patterns on the fly.
Generating patterns is not that costly, but a page can only
have a single color map.
- What exactly are we trying to achieve?
- Can we use standard color maps?
- We can't require standard colors. It can even
lead to legal problems.
- The equipment is simply too different.
- Would the ability to turn dithering on/off per
image be enough?
- Some images are more important than others, and
some colors within them are more important.
- Down-load order cannot be equated with color
assignment, the colors depend on the dithering method.
- The width and height of images shouldn't be in
- The size could be got by some form of content
negotiation. But then the server would need to read image
- The style sheet must have properties relating to
images, even the HREF is a style property.
[David will write down his requirements. Somebody should make a
list of color names for CSS.]
- The browser can prefetch the titles of hyperlinks
and show them.
- Something from Engelbart: hypertext should allow view
control, filtering and re-grouping.
- Including zooming and clipping and other kinds of
- How much of this is done by the server and how much by the
- Can this be specified in CSS?
- Should we move hiding and folding to level 1?
- But we'll also want outline views, thumbnails, a view with
just the links, a synopsis.
- `Audio' is also a sort of `view', which can be selected by
- And so is print. But it's outside our scope to let the
author select the medium.
- Can we have multiple documents displayed together in a
single outline view?
This is probably a server-side issue.Are folding
- They are in level 2.
- Level 2 puts in a button for folded text. That is not clear
enough for a reader.
- Somebody suggested an <LH> (list header) element.
- There shouldn't be a single imposed style for folding text;
a designer should be able to choose.
- If we have `hide' then we also need `forbidden to hide'.
- What exactly would be forbidden? A page could be displayed
in a VR environment or it could be scrolled off the
- Another way is to have explicit on/off control over
- Can we turn off different kinds of links selectively?
- In level 2, based on the REL attribute.
- The links can stay active, but they are not visually
- If there are too many conditions to take into account,
designers might favor PDF.
- Since the author now overrides the reader, this is not such
a problem anymore.
- some documents are legally required to be unchangeable.
- Viewer & author are really indistinguishable. The user
can do anything.
- Some browser might even advertise its ability to change styles
and override the author.
- There has to be an agreement between authors and browser
writers to honor the author's wishes.
- But still, a proxy could change a document and nobody would
- These things are enforceable only with cryptography,
A list of topics:
- character/glyph model
- font delivery
- logical fonts & classification
- font sets
- font availability & fallback
- character maps
- glyph substitution tables
Character/glyph model (also see Unicode)
A character has a set of semantics, but no image. A glyph
has a visual appearance, though still somewhat abstracted.
AFII has a registry of names and images for glyphs, which
Adobe is using (going to use?) as well. SGML will support
the Unicode character set.
An incoming document is transformed to a list of characters
by determining the encoding and translating the bytes to
characters. The characters are displayed by adding
fonts. Complex languages need substitution tables, for such
things as mapping to capitals, adding swashes, mapping to
vertical forms of characters (parentheses `()' must be
Two very similar technologies have been defined, both based
on TrueType, one by Microsoft (TrueType XS) and another by
A `fontset' is not only a collection of fonts, but it also
includes substitution tables. Substitution tables and
character maps could be pointed to by a URL. A logical font
is a font created from several physical fonts plus a set of
The style sheet needs to have a charset as well, since it
includes strings (generated text). The font names may have
to be internationalized as well, so they may need to be
strings rather than keywords. The default charset could be
UTF-8; or is it better to have the same default as HTML:
- The same font should have the same width on all platforms,
measured in some device-independent units. For the most common
fonts (Times, Helvetica) that is currently not the case. The
Consortium might create/acquire some PD fonts. We need this in
level 1, really. I know of some Truetype fonts that are
- We would need them on X as well.
- What is the price?
- Affordable, I could buy them myself. We need good hinted
versions in Type 1 and Speedo (for X) besides
- Is there correspondence between fonts on a Mac and fonts on
- No, Arial is not Helvetica.
- The fonts that are on offer are fully hinted and include a
number of languages.
- Microsoft might be able to spend some resources on a
standard set of fonts.
- It's only useful if it covers math, Kanji, Thai and some
other often used ones.
- Math is currently a problem, this could help a lot.
- At first we need only three families (serif, sans,
monospaced), later more.
- It's also important to have something for all those
characters that I cannot currently display.
- In phase 2, you'll also need the ability to add glyphs and
characters on an individual bases for some styles only.
- Can we get a commitment from somebody? Font sets can help to
down-load only the needed parts. Can we convince Bitstream to
give away their glyph playback engine (called `Truedoc' or
`PFR'). Unfortunately, they don't pass the hints down the
- This may lead to lots of fonts, all essentially the same,
being down-loaded from everywhere all the time. A few free
fonts is much simpler.
- If Microsoft were to develop such fonts, they can't give
them away that easily, because of copyrights.
- We can do both, standard font and down-load fonts, they
- Maybe the W3C can do something.
- The Unicode Consortium might be able to help.
[David will write some Web pages on this. Bert is W3C
coordinator for i18n, Glenn can provide help.]
- Even with known font metrics, the line breaks are
unpredictable, because they depend on the algorithm as
- Even so, the precise size and the font quality are
important to me.
The future and time scales
- Style sheets, like all W3C activities, can be dealt with in
workshops, in working groups, on mailing lists, in technical
reports and in code.
- How are we going to decide what to use as a style
- There doesn't have to be a single format, several of them
- As an implementer, I want to use available code as much as
possible and write as little as possible.
- Supporting both DSSSL and CSS may be possible, but it could
- CSS is a proposal. Who is going to support it?
- I'll take it. But we still need a standard inclusion
- Could we also agree on a common intermediate format, like
- I object to the style attribute. It will cause a performance
hit on the parser. [The chairman postponed this discussion.]
About multiple languages: we can have a notation attribute, so
we don't need a single language.
- The choice is what to spend W3C resources on.
[Bert has a document about linking styles to documents, which
he will distribute. The <C> tag will be added to
- You can't really compare it with DSSSL, DSSSL isn't just
- The name is completely arbitrary. How about
- Or `text/css'?
- `text' must have a charset.
- That's no problem.
- The preferred file extension would be `file.css'?
- I suggest the default charset be the same as for HTML.
- The style attribute will lead to bad documents, people won't
move the styles to style sheets later.
- But it is also very useful.
- It prevents one from having multiple style sheets.
- To select the style language, would I need to put an empty
STYLE element at the top?
- The browser will have a default language.
- This style attribute is a kludge, it's brain dead.
- It's bad document management, but if people want it, we give
- At least don't use the STYLE element to set the
- The use of style sheets requires more discipline than shown
with the style attribute.
[Despite the disadvantages (larger documents, no re-use of
styles, no multiple views, maintenance difficulties, no
compiled or even pre-compiled style sheets), the style attribute
seems too useful as a short term solution to HTML extensions,
that it will probably stay.]
- Is somebody going to investigate automatic conversion between
CSS and DSSSL?
- There are some problems with the respective formatting
- We like to investigate this. Not much can be said now.
- How about table properties?
- They are not finished yet.
- We need them in level 1.
Bert Bos, 28 Nov 1995