Re: CSS2 Progress

* Bert Bos
| 
| The reason we hesitated was that we don't want any text in the style
| sheet that might be a good index term for locating the document

A good point, and one that I didn't consider before.

| However, it is impossible to draw a clear line. And as a result, no
| technical limitation on the power of generated text will both allow
| the generated texts we want and prohibit those we don't.

Very true. 
 
| Current situation is that we want to be able to insert text before
| and after an element. That text will have style properties of its
| own.

Well, to start with, I see the current issues:
1) Possible collision with cue-before/-after properties
2) Should markup be allowed in generated text?
3) Different styles in generated text?

The idea that immediately strikes one is having two properties (let's
call them insert-text-before and insert-text-after) to do text
generation and then formatting the generated text as if it had
actually appeared inside the element originally.

IMHO, this sort of collides with cue-before and -after, and I'd
suggest removing both entirely and instead allowing the insert-text-*
value to be either text or a URL to a sound file, or both, with the
sound as an alternative value for speech UAs. (Essentially
incorporating cue-* in insert-text-*.)
 
This is a fairly simple scheme that would fit well in the current
framework, IMHO. There are of course some problems with this and
questions 2 and 3 above are not addressed.

The main problems I see are:
1) An aural property has been moved out of the aural section
   effectively giving a general property aural capabilities
2) Will the user always want the generated text to be formatted in the
   same way as the contents of the element the style rule applies to?
3) Users may want text generated according to specific rules, like
   "Chapter 3.2.1" on an H3 heading.

Personally, I consider 1 to be less serious than the collision with
cue-*. YMMV, of course.

As for 2, I think this is really the best way to do it despite the
limitations. It requires no new CSS features and is about as simple as
it gets. If anyone wants more flexibility this is perhaps best handled
by allowing markup in the generated text. (See below.)

Doing something about 3 quickly leads into XSL territory and is
perhaps best left there as I see no simple way to allow that kind of
behaviour. 

One thing that might be possible is to allow the insertion of a an
attribute value in the generated text, but I'm not sure if the
benefits outweigh the complications to the model. Personally, I'd vote
against.

| The possibility that different words in the generated text have
| different styles is also something we want, but we won't work on that
| until after CSS2. (For accessibility, text in a single style will
| probably meet 90% percent of the requirements.)
 
I guess the only way to achieve different styles (without having to
extend the CSS mechanisms) would be to allow markup in the generated
text? 

If so, these issues are really one and the same, AFAICS. This means
that for the time being markup is not allowed in generated text, but
it may be later.

| I read your home page. Do you have any publications relating to your
| thesis already?

None that are of sufficient quality to be of interest, I'm afraid. An
article comparing various maintainance tools is under way, but not
completed yet. Then there's the XML introduction, but that's already
available. Thanks for the interest, though.

-- 
"These are, as I began, cumbersome ways / to kill a man. Simpler, direct, 
and much more neat / is to see that he is living somewhere in the middle /
of the twentieth century, and leave him there."     -- Edwin Brock

 http://www.ifi.uio.no/~larsga/        http://birk105.studby.uio.no/

Received on Tuesday, 25 November 1997 19:52:02 UTC