W3C 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 day 1.

 
Contents

  1. Introduction
  2. CSS core syntax
  3. Fonts
  4. Media type
  5. The STYLE attribute
  6. Other issues

 
Introduction

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.

 
CSS core syntax

The proposed list of discussion topics relating to the CSS core syntax:

Priorities

Håkon:
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?

RHS expressions

James:
The RHS should be more powerful, because the LHS is not enough; it won't scale.
Sharon:
E.g., we may want to change font in the middle of generated text, such as a label.
Jeff:
The model of the boxes is too complex, there are too many margins. Do we need reference axes as in P?
Kevin:
Designers may need axes like that.
Glenn:
The terminology for margins isn't clear. Maybe `offset' is better called `padding'?
Jeff:
The side heads as they are shown in the draft may cause trouble.
Glenn:
Where does `align=left' go? In other words: where do floating images go and in which order?

LHS selectors

Steven:
Using pseudo-classes is a bad idea, because it is ambiguous. You may need a special syntax.
Håkon:
It's a hack for level 1.
Steven:
Using class as a selector is also ambiguous in the current syntax.
Terry:
What would an ambiguous class selector enable me to do?
Steven:
The `*' is confusing: is it a wild-card for everything or just for the top level?
Dan:
Most people find it confusing.
Steven:
People will know that `HTML' is the top level, even if they don't have <HTML> in their document.
Håkon:
OK, let's take `*' out.
Glenn:
Please take out the class/GI ambiguity as well. [Discussion about what the (original) intention of class is.]
Dave:
`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.
David:
The hyphenated property names are ambiguous, too. I suggest using underlines instead of dashes.
Glenn:
But `-' is an allowed name character in HTML, while `_' is not. For consistency, it is better to keep the dash.
Steven:
I would like a method to address letters and words from the style sheet, e.g., apply a style to the first word.
Håkon:
It soon becomes too complicated.
Glenn:
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.
Bert:
But it is still the same number of properties, whether you view them as a hierarchy or not.
Glenn:
Not necessarily, you could introduce `line.5.*.font.size' to mean the font size of all parts of the 5th line.
Jeff:
The `alt' properties are too limited. Styles for labels, insertions, etc. may be different from each other, so more structure is needed there, too.
Glenn:
I can write something up about my implementation and e-mail it.
James:
Complex inheritance is difficult in practice. Explicit assignments are easier.
Håkon:
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 complex?
Jeff:
HTML is so flat, can't we limit ourselves to selectors without ancestors?
Glenn:
Context sensitivity is needed, even in HTML. E.g., the effect of CENTER as Netscape uses it is very context-sensitive.
Håkon:
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?

Graphics

Chris:
What sort of things can we specify about graphics: spacing, scaling & scaling methods, which graphic or color is the most important, etc.?
Dave:
And offsets and overlays.
Sharon:
Do you actually change the graphic? E.g., tinting does.
David:
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.
Kevin:
There are hundreds of possible operations.
David:
I also want images to change when a link has been visited.
Dave:
And gradients.
David:
Image enhancements can be postponed and done only when there is enough time.
??:
Visual transitions between pages would be nice, maybe even small animations.
David:
I would like to be able to name and group images and manipulate them together. Controlling the transparency is important as well.

Colors

Chris:
To get consistent color across platform, we need at least a consistent gamma correction built into the browser. We need chromaticity as well.
Dan:
`RGB' should mean the light intensity, not the voltage.
David:
But all this must be transparent to users.
Chris:
Do we need exact colors?
Steven:
Just the ISO colors should go a long way.
Kevin:
The draft should have a list of the color names that are recognized by CSS.
William:
The fall-back mechanism of CSS can be used to give a list of device specific colors for all platforms.
David:
Colors specified as percentages are easier than hex or even 0.0-1.0.
Glenn:
Is it possible to use `@define' to name a color and make the `@define' dependent on the media type?
Håkon:
currently definitions are global; this would complicate the language.
David:
Controlling the load order of images is a way to get the colors you want.
William:
But how about concurrent connections?
David:
I would like to have control over the dithering patterns and to be able to turn dithering off.
Thomas:
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.
Chris:
What exactly are we trying to achieve?
??:
Can we use standard color maps?
Sharon:
We can't require standard colors. It can even lead to legal problems.
Chris:
The equipment is simply too different.
Thomas:
Would the ability to turn dithering on/off per image be enough?
David:
Some images are more important than others, and some colors within them are more important.
Chris:
Down-load order cannot be equated with color assignment, the colors depend on the dithering method.
Steven:
The width and height of images shouldn't be in HTML attributes.
??:
The size could be got by some form of content negotiation. But then the server would need to read image formats.
Glenn:
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.]

Multiple views

Dave:
The browser can prefetch the titles of hyperlinks and show them.
Dan:
Something from Engelbart: hypertext should allow view control, filtering and re-grouping.
Sharon:
Including zooming and clipping and other kinds of filtering.
Dan:
How much of this is done by the server and how much by the client?
George:
Can this be specified in CSS?
Håkon:
Should we move hiding and folding to level 1?
Glenn:
But we'll also want outline views, thumbnails, a view with just the links, a synopsis.
Louis:
`Audio' is also a sort of `view', which can be selected by the user.
Dan:
And so is print. But it's outside our scope to let the author select the medium.
Jeff:
Can we have multiple documents displayed together in a single outline view?
Dan:

This is probably a server-side issue.

Are folding lists expressible?
Bert:
They are in level 2.
Glenn:
Level 2 puts in a button for folded text. That is not clear enough for a reader.
Dave:
Somebody suggested an <LH> (list header) element.
Terry:
There shouldn't be a single imposed style for folding text; a designer should be able to choose.
Anders:
If we have `hide' then we also need `forbidden to hide'.
Håkon:
What exactly would be forbidden? A page could be displayed in a VR environment or it could be scrolled off the window.
Glenn:
Another way is to have explicit on/off control over inheritance.
Chris:
Can we turn off different kinds of links selectively?
Håkon:
In level 2, based on the REL attribute.
Chris:
The links can stay active, but they are not visually indicated.
Terry:
If there are too many conditions to take into account, designers might favor PDF.
Glenn:
Since the author now overrides the reader, this is not such a problem anymore.
Terry:
some documents are legally required to be unchangeable.
George:
Viewer & author are really indistinguishable. The user can do anything.
Jeff:
Some browser might even advertise its ability to change styles and override the author.
Dan:
There has to be an agreement between authors and browser writers to honor the author's wishes.
William:
But still, a proxy could change a document and nobody would know.
Glenn:
These things are enforceable only with cryptography, etc.

 
Fonts

A list of topics:

Character/glyph model (also see Unicode)

Glenn:

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 horizontal!).

Two very similar technologies have been defined, both based on TrueType, one by Microsoft (TrueType XS) and another by Apple.

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 parameters,

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: 8859-1?

Delivery

David:
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 on offer.
Håkon:
We would need them on X as well.
William:
What is the price?
David:
Affordable, I could buy them myself. We need good hinted versions in Type 1 and Speedo (for X) besides Truetype.
Thomas:
Is there correspondence between fonts on a Mac and fonts on Windows?
Terry:
No, Arial is not Helvetica.
David:
The fonts that are on offer are fully hinted and include a number of languages.
Thomas:
Microsoft might be able to spend some resources on a standard set of fonts.
Glenn:
It's only useful if it covers math, Kanji, Thai and some other often used ones.
Dave:
Math is currently a problem, this could help a lot.
David:
At first we need only three families (serif, sans, monospaced), later more.
Chris:
It's also important to have something for all those characters that I cannot currently display.
Sharon:
In phase 2, you'll also need the ability to add glyphs and characters on an individual bases for some styles only.
Glenn:
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 wire.
David:
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.
Glenn:
If Microsoft were to develop such fonts, they can't give them away that easily, because of copyrights.
Dan:
We can do both, standard font and down-load fonts, they don't compete.
Steven:
Maybe the W3C can do something.
Glenn:
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.]

Sharon:
Even with known font metrics, the line breaks are unpredictable, because they depend on the algorithm as well.
David:
Even so, the precise size and the font quality are important to me.

The future and time scales

Dan:
Style sheets, like all W3C activities, can be dealt with in workshops, in working groups, on mailing lists, in technical reports and in code.
Jeff:
How are we going to decide what to use as a style language?
Håkon:
There doesn't have to be a single format, several of them can coexist.
George:
As an implementer, I want to use available code as much as possible and write as little as possible.
Jeff:
Supporting both DSSSL and CSS may be possible, but it could be hard.
Dan:
CSS is a proposal. Who is going to support it?
Thomas:
I'll take it. But we still need a standard inclusion mechanism.
Chris:
Could we also agree on a common intermediate format, like flow objects?
Glenn:
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.
Dan:
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 that.]

 
Media type

Chris:
`application/x-style-css'?
James:
You can't really compare it with DSSSL, DSSSL isn't just style.
Dan:
The name is completely arbitrary. How about `application/css'?
George:
Or `text/css'?
Dan:
`text' must have a charset.
Håkon:
That's no problem.
Dan:
The preferred file extension would be `file.css'?
Glenn:
I suggest the default charset be the same as for HTML.

 
The STYLE attribute

William:
The style attribute will lead to bad documents, people won't move the styles to style sheets later.
Thomas:
But it is also very useful.
Glenn:
It prevents one from having multiple style sheets.
William:
To select the style language, would I need to put an empty STYLE element at the top?
Dan:
Yes.
Thomas:
The browser will have a default language.
Glenn:
This style attribute is a kludge, it's brain dead.
Dan:
It's bad document management, but if people want it, we give it.
William:
At least don't use the STYLE element to set the notation.
Glenn:
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.]

 
Other issues

William:
Is somebody going to investigate automatic conversion between CSS and DSSSL?
Glenn:
There are some problems with the respective formatting models.
Håkon:
We like to investigate this. Not much can be said now.
Thomas:
How about table properties?
Dave:
They are not finished yet.
Thomas:
We need them in level 1.
W3C Bert Bos, 28 Nov 1995