[This is a transcript, courtesy of Karen Mosman, of my PhD defense on 
February  16 2006 as part of my PhD Defense. Anders Elverhøi was the 
convenor. HWL is me, Håkon Wium Lie]

Convenor: The committee reported on January 10th 2006 that it had
found the dissertation worthy of being presented for the degree Doctor
of Philosophy. Yesterday the candidate presented the required trial
lectures on the prescribed title "Discuss style sheets and the
challenges related to the dynamic aspects of the web" and one of the
his own choice entitled "What comes first on the web style or
structure?". The committee has found the trial lectures satisfying.

During the dissertation, Vincent Quint and Ethan Munson will act as  
opponents.

First the candidate will give us a brief survey of the purpose of the
work and investigations. Vincent Quint will then put the work into an
international context and present his opinion of the thesis.
Afterwards. Ethen Munson will continue the opposition, the candidate
will be allowed to answer the comments or questions of the opponents.
Finally, it will be possible to speak ex-...

I call on Håkon Wium Lie to present his scientific work.

HWL: Thank you so much. I'm going be presenting my thesis "Cascading
Style Sheets". You have samples up there if you want something to read
while I talk.

The initial questions I think I would like to answer during my short
presentation here is to give you an understanding of what style sheets
are. There are people in the audience who may not know a lot about
this field and there are also a large number of experts here who knows
a whole lot in this field. So I will try to start a little bit from
the beginning then move quickly on to describe initially what this
thesis contributes to the field, why this is an interesting area of
study, and we also have to start not only o discuss style sheets but
we also have to discuss what style sheets work with, which is
documents: structured documents. So I will also be talking a little
bit about documents all along.

The first thing I would like to do first is say a little something
about the title. The title of the thesis is "Cascading Style Sheets"
and then you might have thought that the main parts of it describes
CSS, the acronym, which is one specific form of style sheets. That's
actually not the case. Major parts of this thesis describes other
languages that are comparable to CSS style sheets, other proposals
that were put forward in the 80s and the 90s. It also describes CSS
but that may perhaps not be the best place to go for a description for
CSS. There are other sources than this thesis.

Now I said we were going to say a little bit about documents. I will
start at the very beginning. Those of you who were here yesterday saw
a similar slide. I will for the benefit for those who were not, start
again from scratch. What you see on the screen here is a little HTML
snippet. HTML is the document format used on the web. It's what when
you see a web page in your browser. This is the underlying code. If
you go in to the View Source in your browser you will see tags like
this where you have angle brackets that say something about the role
of the content -- H1 means heading level 1 -- then you have the
content which says "overskrift" in Norwegian which means headline, and
then you have the end of the tag. So basically what these tags -- the
H1 there at the beginning and at the end -- say what comes between the
tags is a heading of level 1. So it says something about the role of
that string. HTML was developed around 1990 at CERN a physics
laboratory in Geneva in order for researchers to communicate better
electronically. In a scientific environment having information about
the role of the text, the semantics of text, that's what scientists do;
they try to abstract knowledge, they try to classify knowledge.
However, when the web became popular in the beginning of the 90s a lot
of the authors that came to the web weren't really that scientific.
They were more interested in how documents were presented on the
screen. They were more interested in aesthetics. They wanted to
control how there documents looked on the screen. So instead of using
the semantic tags the H1 and the Ps for paragraphs etc. they wanted to
have control over the look of the document. So they wanted things like
the font tag where you could set the size or perhaps the color. This
is an imaginary tag that I've come up with here, but this is
presentational mark up. Here you say something about the presentation
of the documents and actually some browsers starting adding these
presentational tags to them so that their authors would be happy. Some
of us, quite a few of us actually, who had a background in document
research thought this was perhaps not such a good idea
because if you start doing presentational markup instead of semantic
markup you lose a lot of the freedoms you have with semantic mark up.
For example, if you have H1 you can present these easily both on the
screen and in a speech synthesiser, in a non-visual medium. This is
independent of the presentation medium, where as if you only describe
the font size and the colour then you are limited to visual
presentations. So we knew about the concept of style sheets. Style
sheets have been around at least since the 1980 the idea that you
describe the presentation of the document, not in the document itself
but in a document that goes along with the document. So there was a
bunch of people who said "Really we shouldn't do presentational markup
in HTML, we should do style sheets instead." Along the way there were
several proposals for style sheets for the web and that's really the
context of this thesis: that a bunch of style sheet proposals were
presented; they were discussed in the web discussion groups, they put
forward languages that would describe the presentation of documents,
that would have stylistic rules that would say how H1 and all the
other elements should be presented. The great benefits of style sheets
is that they can be reused. You can write one style sheet and have it
work for all the documents on your site. They can work for many types
of media including non-visual presentations.

However, there is also some downsides. People had been using word
processors at that time, for example Word, the most commonly used word
processor these days. It has the notion of styles. It is very similar
to style sheets. Microsoft word doesn't use a standardised format. It
uses Microsoft's own proprietary format but the concept is quite
similar. And it turned out, and we have seen this from research, that
people, authors, weren't really very good at using the styles
consistently in Word. Instead of using the semantic styles that were
suggested by templates in Word, they chose to use presentational
style. They selected text and made it bold just like you would use a B
tag in HTML. So, the question was also could we convince people to use
this? That was not a clear given answer.

One of the languages that were presented was later developed into CSS
and I am going to give you a small CSS sample here just to give you a
sense of what a style sheet looks like. This is like we saw the HTML
source code from before this is a small snipped from a CSS style sheet
that describes how these H1 elements, which is only one of many
elements in HTML, how it is to be presented. We set the font size. We
set the color and we set the alignment of the text and this happens
not from the HTML file itself but from a style sheet which is linked
from the HTML file. This style sheet can then be linked from many HTML
files and thereby control the look and feel of a whole site. That's
one example from where style sheets on the web are different from Word
documents, that fact that these resources can be linked makes the case
for reuse more compelling than it is for single documents in your word
processor.

(showing examples from CSS Zen Garden)

I will also show you a few examples of what style sheets can do. Again
I used this document in my presentation yesterday for the benefit of
the new participants here I will show a few screen dumps of what can
happen when you apply a style sheet. This is one HTML document. This
is exactly the same HTML document but know you have a style sheet
attached to it. For the benefit for those who were here yesterday, I
have actually made a few new screen dumps. And it is actually quite
striking what you can do visually just by adding a link to a style
sheet from the top of the document. It really changes the whole look
and feel. I am charmed by this LEGO version here.

Instead of going through this thesis chapter by chapter I will
concentrate on what I consider to be the main contribution of it. I
will follow the order in which they appear but I will not go through
each chapter individually. I have selected five items that I consider
to be the main contribution along the way.

The first one is what I call the ladder of abstraction and this has
more to do with structure documents that it has to do with style
sheet. This is a way of rating structured mark up languages. HTML is
one such mark up language but there are others as well. I've also not
only looked at structured documents but I start here at the beginning
by looking at images to try to rate where on a ladder, on an imaginary
ladder of abstraction, a certain document format, a certain content
format, can be rated. And I think there are some significant
differences between image formats and textual formats and the first
question to ask is whether there is human readable text in the format.
And there we see that all these formats answer yes to that because
even in an image, even in a fax transmission, you can actually encode
text and read the text for humans that is. Is the text machine
readable, that is can a computer extract the textual content from the
image, the answer is no. Can it extract it from HTML, indeed it can.
That's what Google does every day when it goes through the web and
indexes HTML pages. So I have formulated a bunch of questions that if
asked in the right order will hopefully give us a sense of where
document format is on this ladder of abstraction. And I think knowing
that placement is important for what you can do with that content. For
example, it would have been terrible if the web consisted only of
images, GIF images of text documents, then we wouldn't have a Google.
So, it is important that you reach a certain level on the ladder of
abstraction. At the same time a format like MathML has gone too far up
that ladder. At least it is too far for sending across the web to
browsers. It may be important for researchers, for experts to use
highly semantic format that have application specific semantics, as
I've called it here. But that may not be suitable for web use; that's
one of the questions that is left in the thesis actually. So this was
the contribution number one, the ladder of abstraction, as a tool for
measuring mark up languages and other content formats.

Contribution number two is found in chapter 3 and that's a criteria
for style sheet languages. As Ethan Munson, one of the opponents here,
noted earlier, and I've included it as an inspirational quote for me,
"Style sheet languages are terribly under-researched." Nobody have
really looked down and studied them at least from several angles are
left unstudied and I think it is important to start that or continue
that study. I am not the first person who does study here. I shouldn't
claim any such thing. But I think I'm the first person who perhaps
formulates and give a numbered list of what a style sheet language has
to include in order to be called a style sheet language. And the six
things that I have come up with is listed here on the screen.

First, a style sheet language needs a syntax. That's really the easy
part. Any language need a syntax so that's easy. But in the context of
CSS it's for example to say that you have these signs here to denote
the difference between the selector at the beginning and the
properties in the middle. That's a syntactic choice that was made by
the people who designed CSS.

Second, you need selectors. Selectors is here what is marked in red at
the beginning. It's saying this rule applies to the H1 element. It
selects the H1 element and then the rule that comes after, which
happens to set the font size in this example, that applies to H1
element.

A style sheet language also need properties. It needs to have a list
of properties that can do useful things, that can set useful
characteristics of the presentation. Font size is an obvious one for
screen use, there are others like colors, there's white space, if
you're dealing with an aural presentation you need volume and perhaps
speech personality. There's maybe around a hundred such properties in
various style sheet languages.

Then we need to assign values to those properties. And that is what I
have called values and units. Here we set the font size to be 12
pixels -- "px" stands for pixels. That is a necessary unit on the
screen. If you are dealing with paper you might want to use fonts or
some other unit instead.

Then you need a value propagation system. You don't really want to set
all values of all properties on all elements in documents. You want
many of the values to be set automatically, in fact most of them you
want set automatically and we show this by setting a value here, not
the H1 element, but on the body element which is in this small sample
at the top here, which is the ancestor of the H1 element and then
through inheritance, which is one example of a value propagation
system, the value will propagate from the body element and into the H1
element which is a child.

And then finally, a style sheet language needs a formatting model to make  
sure that whatever content is put within the markup actually appears on  
the screen in some kind of useful manner.  So that this is translated, the  
right font is chosen, that the right font size is chosen, etc.

In addition to the required components here I could have, I have actually  
listed two other ones as well which are often present but not always  
present:  that's a way to do generated content and it's a way to link the  
style sheet to the document or the other way around.

That's the second contribution.

The third contribution is listed here: the style sheet language
comparison chart. As I mentioned a lot of proposals were put forward
in this time, starting from the mid 80s and until the mid 90s and you
see the list up here. Three of them were done before the web, that's
the three first one listed, FOSI, DSSL and P94. As the web took off in
the beginning of the 90s people starting discussing this on the
mailing list and actually the first proposal, the first complete
proposal was put forward in 1993 by a person called Robert Reich.
What's special about many of these proposals is that there were
actually just a person sitting down and writing an email message.
Sometimes very long, but he didn't give it a proper name, he didn't
propose it with more than a "here's my proposal". And that is the
wonderful thing about the web - we had an effective way of
communicating along the way and people threw out ideas and people
responded. So it's a bit of an anarchy sometimes and part of my job
here was to sort out what of these messages can be labelled as a
proposal and then review it. And here's the list that I've come up
with and I think it is a fairly complete list of the style sheet
languages that have been proposed for the web. And actually, going
through and discussing the similarities and the difference of these
languages, that's what a large portion of this thesis is about. And
most of those pages will be very boring to those of you. I am not
going to recommend them to read but I think they will be useful to
researchers who, at some point, want to go back and see what happened
really with style sheet in the 90s. You know, how did they differ.

I did some, for me very interesting job, and read through all these
proposals and extract how can you set the font size of an H1 element
in CSS, in DSSSL, in FOSI, or in the P language. And this slide here
shows one such small examples and you will find more such examples in
the thesis.

The next contribution, is really the "thesis" of the thesis. This is,
you know when you write a scientific work like this you are supposed
to but forth a thesis, and discuss it, and evaluate it, and see
whether it is true or not. And the hypothesis in my dissertation is
that the web calls for different style sheet languages than does
traditional electronic publishing.

Like I said, people had been using styles in word processors before and we  
took the style sheets with into the web when the web came along.  But the  
web is quite different in many ways from a traditional publishing world.   
For example when you're writing Word documents, or at least when you were  
writing Word documents in the 90s,  you typically  printed them out on  
paper  before you sent them along.  Increasingly, the web is taking over  
so that's changing too.  But word processors, the areas where style sheets  
came from,  were basically  typewriter simulators, and they were of use to  
the author, to each individual author who was working on his machine but  
they didn't really extend beyond that.  When the web came along that  
changed.  Now we could suddenly put documents on distributed machines all  
around the world and the style sheets could be in a different place and  
one document in one part of the world could point to a style sheet in  
another part of the world.  So we have what is known, or the term I  
propose for this characteristic is so called  "late binding".  Whereas  
before the style sheet and the content was combined at the author's  
computer, now we have the style sheet combined with the document on the  
very computer, right before the eyes of the reader, not before the eyes of  
the author.

And one example I will use here is, that I am using a style sheet in
this presentation this is a normal browser I am using, I am sure you
can guess which one, and what happens when I press this magic button
on this HTML document is that a different style sheet is applied and
it goes into presentation mode and the style sheet says I should use
bigger fonts, I should split presentation into pages, etc and do a
little bit with colors and things to make it look like something out
of Power... power something? So that is certainly one characteristic
of the web that is different from traditional publishing environment.

Also, the web is a screen-centric publishing environment where you
need to set properties and values and units that are suitable for
screen use, for example using pixels instead of points. That's how
most web documents are presented. Of course, we want to be able to
print on paper as well. Like this thesis was written entirely in HTML
and CSS. So, you know, we want to be able to go here as well but in
most environments, most web documents are shown on a screen.

There is also the possibility of having a shared author and user  
influence.  One example there is if you don't have the same fonts on a  
certain machine that the author had you will need to change the  
presentation.  The author has certain characteristics of the machine he is  
using.  The user has different characteristics and these differences needs  
to be negotiated and the style sheets need to work in any case.

On the web there are multiple outputs. We show web documents on phones
these days. We listen to them. Most of us still see them on PCs
perhaps. But in any case there will be different ways of presenting
web documents.

Also web documents are linked. You click on one link and you are taken
from one document to the other and you would like to remember which
link you have been to before so therefore the browser sometimes give
it a different color to the links you have been to versus the ones
you haven't been to and therefore the requirement is to have link
styling, to be able to set those colors from the style sheet.

Also the web, you can't really trust it. You can't really trust the
internet. You can't really trust that the server in the other end of
the world is really up and running when you need the document from
there or the style sheets from there. Maybe there's a picture missing.
In any case you would like there to be a presentation in the other
end. So you need a kind of robustness. If the style sheet is missing
you still want the content to be presented one way or the other. So
that's also a web specific requirement.

And this list of requirement is meant to be added to the criteria that we  
evaluate style sheet languages by.  These criteria have been written  
afterwards, after style sheet languages were proposed, after CSS was  
developed, so in some ways this thesis comes too late.  It should have  
been written at the beginning of the 90s instead of now but there we are.   
But I still think it's a useful exercise to go through.

The last contribution I will list is CSS itself. CSS is actually
better described somewhere else. What I have tried to do in this
thesis is evaluate CSS by the same criteria as I have done with the
other proposals and languages so that one has a playing. The same flat
playing field, so you can see more easily how these languages compare
to each other, to use the same metric.

In addition to that comparison though I have also tried to write a
very honest chapter about what the problems with CSS and how CSS could
have been better, mistakes that were made. That is one chapter on its
own.

Then there are two smaller chapters about how CSS can be used for
other contexts, one is small screen presentations. We have actually
used that at Opera when we worked on trying to display web pages on
very small screen. There in the beginning we enforced a certain style
sheet in the beginning and you can read not all our secrets in that
chapter but some of them. Then there is a chapter also on how CSS can
perhaps be used outside the domain of styling. Where we use CSS to
describe links -- how to connect one hypertext document to another.

So before I end here, I would just like to say a couple of things
which I think are useful in the evaluation this thesis. First, I think
it is important to distinguish the thesis from CSS itself. CSS is a
language which is out there. It's successful, most people would say.
But that's really not the same as this thesis being successful. This
is something else and this should stand on its own regardless of CSS
success or failures.

Also, the thesis is more backwards looking than it is forward looking.
This is not the time to do visionary statements about where to go
next. There is a chapter on future directions of research which I
think would be interesting as well and I hope there will be more
researchers in this field. But the thesis itself is really about
recording history and extracting the important point of history and
sorting through history more than it is looking into the future.

For me personally this exercise has been very useful. I have very much
enjoyed the process of going back, of doing the review of these
languages along with CSS. Since I have been very involved in the
process of developing CSS, one could argue whether or not I am the
right person to do this job but it is certainly the case that I have
enjoyed doing it.

Finally, I have also very much enjoyed printing this document, to make
a PDF file out of the HTML and CSS, to show that it is possible to
actually use CSS for real documents as well.

Thank you so much.

Convenor: I thank Håkon Wium Lie for his contribution, I then call on
Vincent Quint to put the work into international context and give his
evaluation of the dissertation.

VQ: Thank you.

At first to say that I am very happy to be here today.  I have been not  
directly involved but I have followed very closely in that work on CSS  
since more or less  day one, and possibly before, because I think that  
some CSS may come from earlier work.  So it is really a pleasure of me to  
participate in this defence.  And the first thing I would like to do is  
thank the candidate for having done a large part of my work by  
highlighting the most significant contributions that he did it on his  
thesis...

But I could add one or two more contributions that I think are worth being  
mentioning here.  Anyway, clearly the ladder of abstraction is something  
important to clearly understand how the style sheet may be involved in the  
web at large, and more specifically in structured documents.   Then  
obviously for a serious academic work it is necessary to establish the  
criteria for evaluating previous work and your own work and so the  
criteria that the candidate has presented briefly here but details in his  
dissertation are very selective and really help to make a distinction  
between different languages that have gone before CSS and CSS itself.    
Using this criteria for comparing languages is then something that is very  
important and very useful.  I think he said that already but let me repeat  
that.  I think that's the first time I read something about style sheets  
that is complete from an academic point of view without any commercial  
bias and that is fair enough to recognize every single contribution and  
give a complete overview of the domain.  For me that is a very important  
contribution.  Maybe I may be a little selfish here.  I have students from  
time to times who have to work with style sheets, and it was always  
difficult for me to recommend any single paper that could introduce them  
to the topic.  Now,  I can tell them to read chapter 2...

HWL: Three

VQ: Read chapter 3 and you're done. That's certainly something very
useful in the academic context.

As the candidate said himself, and I think it was my colleague, Ethan
who at first, I... the area of style sheet languages was not really
taken seriously in many academic work, and I don't undertand why,
because that is certainly something, that is very important for
everybody actually. I guess everyone in this room and outside and in
Oslo and elsewhere in the world, is exposed to style sheets. Whenever
you open your browser, whatever it is, what you see first is the
result of some style sheet and so style sheets are really something
that is important for the information society. And, believe it or not,
there is very few academic work on that area. So this thesis, again,
is a contribution to that problem. So, this will be extremely useful.

The last contribution, Håkon has chosen to present it at the end...
CSS is clearly a very important contribution of this thesis. I can
understand why the chapter on CSS itself is not the most the number of
pages in this book, that's probably because this is the result of a
really worldwide effort to define a style sheet language for the web
and clearly Håkon is not the only author of CSS. A few of them are
here in the room. And therefore, I think Håkon had some difficulty to
describe his work in the context of CSS because obviously his
contribution is very strong, to my understanding he is the first who
proposed to have an international activity on style sheets for the
web. But still a lot of people have contributed to this work. And
trying to present his own contribution to CSS as a PhD dissertation is
certainly something that was very difficult to do. I can imagine how
difficult it was to chose what to say and not to say in the chapter on
CSS because there is obviously always the risk that you take for you
something that probably or maybe has been suggested before or you
don't remember exactly when and by whom so that's really a challenge.
On the other hand this dissertation clearly shows that it's worth
trying to do so, even when trying to describe a large cooperative
effort you can extract your personal contribution, provided obviously
your contribution is as strong as the one we are talking about here.

The consequence of that is, I think, a few interesting thing about CSS
are missing in the document. Some are just mentioned at the end of a
paragraph or something. For instance, well, I think it was mentioned
during the introductory talk by the candidate, but you know, CSS is
not only for display or printing documents you might also use it to
plant a document to a voice in the browser and this type of CSS is not
mentioned in the document. Probably because Håkon was not that much
involved with that part of CSS. But the general architecture of CSS
and here Håkon is really involved made that possible and I think that
is something that needs to be mentioned here.

Another aspect of CSS that is not completely developed here is the CSS
DOM which is the object model for including CSS prerogatives in
dynamic documents. Well, we had a talk yesterday, Håkon gave a talk
yesterday on that and he explained how dynamicity could be added to
style and how CSS handles that but again, probably because this part
of CSS was developed by a separate group where Hakon I think was not
deeply involved, it's not mentioned.

Well, basically those remarks are just to say that CSS is more that
what is in the book. I agree that this book is not only about CSS, I
mean all the first part about the history, the context, the
requirements, the criteria, all those things are more general than
CSS. But still the contribution on CSS itself is, I think, more
important than what you can read here.

So after this short assessment of my review of his work, let me ask
the candidate a few questions. And I will try to do that in two or
three parts. I would like to start about the model because, well
basically my questions are about CSS. And I won't discuss much about
the first part, the introductory part and the overview. I have said
what I think about that, I think it is very valuable but I feel more
interested in the discussion of CSS itself. And let's start with the
model.

So talking about the model, obviously the kernel of CSS is a
formatting model. Everything is based on the formatting model of CSS.
But CSS doesn't work alone by itself. It has to work on some
documents. And documents too have models, DTDs, schemas and so on. So
I would like to know what you think of the connection between CSS and
document models, let's say DTDs or schemas. And more precisely for
instance, what's the impact of a document being valid or invalid
regarding the use of a language like CSS? How can CSS work on invalid
documents? And that is an important question because on the web as
maybe everybody knows there are many invalid documents, so how can CSS
manage that?

HWL: Yes, it's interesting questions that you raise Vincent.

First, could I briefly respond to why access and the CSS DOM are not
described in this thesis as well? Since you raised that as points.
That's because I used the same metric for CSS as with the other ones
and none of the other ones had an aural formatting model or dynamic
object model so that was my reason. But I agree that could have been a
natural part of any such thesis as well.

When it comes to the model of the document versus the model of CSS,
there were proposals initially and I think Bert Bos was the one who
came up with that idea (Bert Bos, the co-author of the first CSS
specification is sitting in the audience today) of actually addressing
schemas in CSS as well. One could easily foresee that when you have a
description of how H1 elements are to be presented, formatted, you
could easily also say what the content model of the H1 element is.
Just like you do in the DTD. So you could in fact take the information
that is in a DTD and put it in a style sheet. Now because we
concentrated on the formatting part, we decided not to do so. There
was also some, I would say, resistance from the SGML community that
they wanted to keep on doing schemas and DTDs in their world whereas
we did the formatting world. So I think that's the reason why CSS has
limited itself to the formatting.

And that's also the answer to your second question of why, what, how
we deal with invalid documents. CSS doesn't say anything about that.
We say that's outside the scope of CSS. We describe how to format a
document that comes in but whether that document is valid or not
according to some schema, we don't say. And that has resulted, that's
part of the reason why, initially, some documents on the web looked
one thing with one CSS browser and in another one they were different
because the validity was handled outside of CSS and therefore if they
addressed validity differently the resulting presentation would also
be different. So I agree it's an issue but I think it's outside the
scope for CSS.

VQ: Okay, but any way, a part of CSS relies on the document structure
I mean the selector part clearly and also the formatting modes to some
extent. But let's just talk about the selector part at the moment.
Have you thought about checking CSS style sheets based on the DTD of
the document which you are supposed to apply those style sheets. For
instance, that way you could detect whether some selectors are
meaningless or not because some structure you describe in a selector
may be just invalid regarding the DTD

HWL: It's true

VQ: So this is possibly a way of exploring the DTD.

HWL: Yes I agree that could be useful and if the web had been based on
DTDs that I think would have been done, if not in the specification,
at least by the implementors who wanted to cut out the invalid parts.
In practice though the web isn't based on DTDs. The DTD is a remnant
of SGML, of the past, it's not part of the present, and we saw that
XML, when XML came along as a follow up to SGML, they kept the DTDs
there but only barely and people don't really use them. There's a
bunch of other schema languages coming out now and I think maybe they
will be deployed on the web eventually. But currently the schemas
aren't available for the style sheet processors to use.

We did do one thing though that was interesting in this context though.   
In CSS1 we had this example of a document where you used the body element  
as the selector even though the tag body didn't appear in that document.   
But we said, since  this is HTML there will be a body element in the  
document model  even though it is not represented in the syntax so we did  
sort of hint that you had to, you can't just look at the tags, you have to  
look at the underlying structure.

VQ: The actual structure

HWL: The actual structure.

VQ: Even if it not apparent in the markup

HWL: Exactly.

VQ: Another issue that is not completely developed in the document is the CSS  
formatting model as opposed to a formatting model that would be based on  
transformation.  You know that -- this is an important way of considering  
a style sheet.

HWL: Yupp.

VQ: And so I want to ask you why you didn't review XSL in detail in
your thesis. You have touched this issue yesterday so I won't go
further with that.

HWL: Yes, it's a difficult question.

VQ: Yeah but I heard the answer anyway. But still, you explained that
CSS is powerful enough to form a complex document and you took that
document as an example. To me the advantage of the transformation
approach is that you can generate things much more than generated
content in CSS. I mean generated table of contents and index, or these
kinds of relevant information you find in books which are very useful
for the reader. I mean, how did you do that? The table of contents,
indexes, the glossary and these kind of things.

HWL: The glossary was hand inputed. There I just wrote the glossary as
HTML code and had links from the document. So it wasn't automatically
generated. The table of contents in the beginning was machine
generated but it was done with a program written by Bert Bos, again,
who goes through the HTML code and generates new HTML code that
represents the table of contents. So it is basically a small
transformation that takes place there. It's true that CSS does not
handle transformations currently. It does a little bit. It does the
generated content. There are proposals on the table for how to do
generated table of contents as well but that's not in any
specification yet. We're thinking along those lines.

Personally I don't have anything against transformations, we need them
obviously on the web, but I don't think transformations and styles
should be mixed together. That's my main point. And that's probably
why I have been so vocally against XSL which again may be the reason
why I didn't review it: I have such strong opinions about it. I use
the excuse that it was submitted one year too late for me, but that's
really not the reason. I don't think they should be mixed up because
you do your transformations and then you get your content into the
order you want it presented, roughly, then you transmit it over the
web, so transformation takes place on the server side and I think
presentation and style sheets should take place on the client side. I
think to have a clean separation between the two is very useful. But
of course, we do need transformations. Absolutely.

VQ: I have more questions about the formatting model actually, the CSS  
formatting model.  Basically, the formatting model is explained in terms  
of rectangular boxes.  But there are a few properties, like float which  
make the boxes as little less rectangular.  Something that is more  
complicated shapes for elements and then whenever these boxes become more  
complex, a few properties become a bit difficult to understand like  
border, margins and padding.  So, do you think that it's really worth to  
try to have and present everything as a single model?  Wouldn't it be more  
clear possibly to have a simple model based on a rectangular area, always  
a rectangle, and then to have a more sophisticated model when you want to  
do something more sophisticated and then you are out of these rectangular  
constraints and you can go in a different way to do more sophisticated  
things without distorting a little bit the original model?  What do you  
think of an alternative model for complex layout?

HWL: I think it's an important and interesting question. The reason
for having floats there in the first place was that authors wanted to
have menus that went off on the right side of the screen and then they
wanted to have something that went off on the left... and they use
tables for it. Okay go ahead.

VQ: Let me, let me I am not discussing the requirements, just the
results you have shown with the CSS Garden are something that people
want to do and are able to do. What I am discussing is the way to
achieve that just using, in principle, rectangular boxes but they are
not rectangular boxes. So in those extreme cases wouldn't I think,
possibly another kind of model be more...

HWL: Yes, yes, I think you're right and Steven Pemberton I remember
you argued for using a table based model actually, in the beginning.
So instead of having the floats you would insert things into the
table. The table wouldn't be in the markup, it would be in the style
sheet. And now we have support for tables as well in CSS2, so that is
an alternative to floats. I agree that floats are, well they're still
rectangular boxes but they are a bit more complex especially since
margins collapse between floats and the parent element and the other
elements around, so it actually turns out to be complex than I would
like it to be. So, I agree with you we might have chosen a slightly
different path if we had done this today. I still think the way floats
work on the web today, we have finally achieved interoperability so...
so it works.

VQ: Yes, sure it works, but not easily

HWL: Yes, I would agree with you there.

VQ: Okay, another... the box model because that really is the
foundation of the formatting engine of CSS. This distinction about
line boxes or line element, and block box or elements. I have to say
that's probably not the most clear thing in the dissertation. The
definitions of those boxes or elements and inline versus block is not
very clear and, so I am wondering why you need only these two
elements.

To me it seems that taking  HTML elements, as example, large elements such  
as body or divs, are not exactly in the same model regarding formatting as  
let's say paragraphs and headings, which are clearly block for everybody  
... paragraph or heading is a block.  But div or a body or these kind of  
large element which contain other elements which then are blocks.  Would  
it be interesting to try to make a difference between two kind of block  
elements, what is currently called block elements?

HWL: Yeah, yeah  I think it's a good idea to maybe have a container type which  
would contain other elements.  Still I think calling it block,  it works,  
again.   And also, as I am sure you know, we have added more types than  
just block and inline, we have the list item -- it was there in CSS1 -- and  
we've added like, things like run in, to do these kind of somewhere  
between inline and block to be able to format things like definition  
lists, DL elements in HTML.  So I agree.  It's a little more complex that  
just a binary switch between inline and block but we have the, we  
engineered in the expansion capabilities in CSS for that.  We used a  
property name, the display property that took two or three values in CSS1  
and we could just add more values as we needed them. And there is not  
reason why we can't  add a container as another value on the display  
property.

VQ: Another feature of CSS is the first C, cascade, which is really something  
new in the style sheet languages.  That was never done before, that was  
introduced by CSS, basically by you.  So it was discussing that a little  
bit.  In fact, I don't know if you have had the same experience I have had  
on the web, the way it is used now by wen designers.  It seems that this  
sophisticated mechanism is used more for modularization, dividing large  
pieces into style into small modules that you can combine easily but all   
modules being designed carefully by the same people and it can show that  
they work well together.  As opposed to the original idea of cascade which  
was that different people without any connection between them may specify  
different aspects of the document style.  So what do you think after a few  
years of deployment, what do you think of the use of the cascade and is  
that what you had in mind in the early days?

HWL: No, I think the cascade turned out to work somewhat differently
today. The idea of the user being able to have his personal style
sheet with his favorites and the author to have his ideas and then to
have them match magically in front of your ideas, and have serif fonts
and san serif fonts and there being somewhere in the middle, that
doesn't really work. We have to admit that. It was great marketing for
CSS at the time. It made people stop and think "Um, yeah, this would
be cool." but I think cascading, you mentioned one aspect of cascading
that worked which is basically the an include statement which allows
you to have different style sheets on the author's side which combine
nicely if you engineer them well.

Another side of cascading which also works well is the fact that the
browser has a default style sheet for HTML so that you don't have to
specify everything from the author side. You can rely on paragraphs
looking roughly like paragraphs and H1 elements with a bigger font
etc. You don't have to specify all that. You only specify the things
you care about from the author side. You don't have to specify a
complete style sheet which would be quite long. So you can cascade,
you can rely on there being other browser style sheet. You don't
really care about the user style sheets because they aren't really in
use; it's too hard to author; browsers don't easily support ways of
including them and it's hard to debug the result. So that part of
cascading, I agree it has failed and it is time to declare that to be
a failure. But the every day use of cascading as in you don't have to
specify everything about all HTML tags that works very well.

VQ: Provided most browsers have the same default style sheet.

HWL: Yes that's right and that's included in the specification as well, a  
suggested style sheet and they tend to do the same.

VQ: And it works. Fairly well.

HWL
Yea, fairly well? (soto voce)

VQ: I think that is enough with the model. Let's move to the language,
the syntactical aspect of CSS. As you have shown in one of your
slides, it's a very simple language. One slide is enough to explain
how to write CSS. This is clearly an advantage and something that
helps people to use the language and that was certainly and important
factor for the wide and quick deployment of CSS. But, there are some
limitations that are introduced by that. And more specifically the
fact that you are given the syntax all properties are syntactically
independent of each other . You can put them anywhere and in any order
while the... engine will manage to pick the ones that are relevant and
do whatever, what has to be done to satisfy the constraints stated by
these properties. But this makes a little bit complex the writing and
debugging of style sheets. Properties such as display, or instance,
and float f and clear and margins, all those things which are
interrelated in some way, are not at all related by the syntax itself
but they have a strong influence on the way the document will be
presented. Do you see any way to improve that situation from the style
sheets author point of view?

HWL: Well I agree there is an issue there. I do think in the design of
the properties we tried to make them independent of each other as much
as possible. But there are cases

VQ: It works well for 90% of them

HWL: Yes, and then you have the display and margin

VQ: I am talking about the 10%

HWL: Yes, so you end up with the author asking himself  "Why does it look that  
way? What do I need to fix in my style sheet in order to have the  element  
be over there instead?"  I don't see how the language itself can change to  
make that easier.  I would have hoped that there would have been more CSS  
debuggers out there.  Just like you have debuggers for programs, I think  
you could have debuggers for style sheets as well.   You can do some  
tricks.  For example, in CSS2 you can add an outline around each element  
which doesn't effect the layout, it just puts a border around it.  Right  
so you can see where the boarders around the elements are.  That's a sort  
of  poor man's debugger.  I'm actually surprised that given the acceptance  
of CSS as a language and the importance it has for designers these days,  
that there aren't more debuggers out there.  But I think that will happen.

VQ: That's an interesting question, at least to me. In my group we
have been working a little bit with that and so I would be interested
to go a little bit further on that topic. Clearly, drawing the outline
of each box may help to understand the formatable part of CSS but you
have also this very complex or sophisticated mechanism of inheritance,
cascade, and propagation in general which makes sometimes very
difficult to understand why that element has not the property values
that you expect. And then finding the rule that was triggered to
produce that result is something that's a bit tricky in some cases.
When you have many multiples of style sheets.

HWL: Absolutely, I agree. I find myself debugging all the time and
using grep as my tool for trying to find the, you know, its not very

VQ: Well, I am sure you have some ideas for doing something a little
bit more...

HWL: I would like to have, on my screen I would like to have a
debugger where I could right click on an element to say what
properties apply to this element and where were they defined. And this
is something you have in integrated development environments in
programming languages. It's a basic part. And I don't see why we
shouldn't be able to do something along those lines for CSS as well.
You could take an environment like Eclipse, like the Open Source
Eclipse, and do a CSS IDE, is that what they're called? for CSS.
Absolutely.

VQ: Yes but it requires the formatter to work in both directions. At
the moment most CSS formatters start from style sheets and produce
some layout and style and that's it. What you are asking for is
something that would allow you to go the other way around, starting
from something that has been formatted and has some style properties
and go back...

HWL: It's true, it would need to remember things along the way. It
would have to remember where that property. If it has the color red
and you expect it to be green...

VQ: Exactly

HWL
You would have to click on it.  It has color red, where was that set, in  
which style sheet do I have to make changes to fix that problem.

VQ
I'm glad you agree

HWL
Was that the right answer? (laugh)

VQ
Okay so I am on the right way, thank you.

But still, what we have just discuss, is about to some extent linked to  
the fact that properties are  completely independent of each other, at  
least syntactically independently of each other and you never know where  
 from a property comes.  But, so have you... well, let me take another  
example.  For instance, another way to debug a set of style sheets is to  
just remove one of those style sheets and see what changes and so that's a  
first level of debugging.  You can look at the result and have an idea of  
where, whether the properties you were looking for was in that sheet or   
not.   So that's one way of working.  But to do that you have to be able  
to talk about style sheets, to tell the system to remove that style sheet  
and the only way you have to talk about the style sheet is giving it a  
URL.  There is no other way.  There is no title.  There is no meta data  
information.   There is nothing about that.  And in your critical review  
of CSS in the book you are mentioning the UI issue that are linked, or  
related to CSS. Do you think that to improve the manipulation of style  
sheets it would be interesting to have at least a few meta element or some  
way to identify or qualify every single piece of CSS code so that the user  
may manipulate them more easily?

HWL
Yeah well, we try that somehow, not through meta elements, but we have,  
for example, title attributes on the link element so that you could give  
your style sheet a title and you could also declare whether this is an  
alternate style sheet or a default style sheet.  So that's in the  
specification.  It turns out though  that browsers don't really implement  
this.  They have, they don't show if there is an alternate style sheet.   
Well you can actually find it in Opera if you, but you have to go down  
several levels in menus and in Firefox as well  and IE has never exposed  
them.  So, even if that's available, it hasn't caught on because the user  
interface isn't t there and I think if we start adding meta tags now  I  
don't think they be used because there simply won't be implementations,  
deployed implementations.  I do think though maybe one way of attacking  
the problem is through Javascript. Cause through the style sheet interface  
of the DOM you can actually turn style sheets on and off and you can hook  
that up with a small user interface to list the links elements and click  
and turn them on and off.  I can't see any problems with why it should  
work, reformat the document accordingly though I think you might actually  
be able to write that debugger, in part at least, in Javascript.

VQ: Another aspect of the language the selector.  With every new level of  
CSS,  selectors become a little bit more complex and  more powerful too.    
It is all about complexity the goal is to give them more power and more  
selectivity.  So I am wondering whether at the end you won't finish with  
something that is very close to Xpath.  What do you think of this kind of   
convergence between CSS selectors and Xpath - because basically they are  
the same thing.

HWL: Yeah,  I think it's a little sad that at the starting point we weren't  
able to find a common ground to develop those languages.  They're similar  
but different now so, that's,  one would have hoped that as this all  
happened within one organization, W3C, that we would have been able to  
synchronize that but it didn't happen.

I also see the danger of feature creep in CSS.  I think that's with every  
successful language you have people wanting to add more functionality,  
have their favorites go in there.  I certainly  see that selectors,  
especially in the selectors module of CSS3, that there's stuff there that  
I wouldn't want to ideally have in a browser.  For example, in the CSS3  
selectors module you can select for the last child element, which is in  
conflict with the progressive rendering because you won't really know if  
something is the last child until you parsed a few more bits.  Or  
alternatively if you set a style on the last element, let's say you set  
the last child to be red, you will move the red down as you parse, in  
which case you may mislable something to be the last child.  It is only  
the last child at a certain point in the parsing process so.  People are  
adding things to CSS that I ideally wouldn't want to have in there, but as  
you started off  saying  it's a community effort.  I have done my share,  
others have done their share.  There's many people who have contributed  
significantly to CSS both in this room, on the mailing list,  W3C,  
companies' implementations, so there is no dictator and all in all, I  
think that is good.

VQ
You were just mentioning progressive rendering and complex selectors to be  
a problem regarding progressive rendering.  In CSS1 progressive rendering  
was a given, I mean there was no problem to display the document, one  
element after the other and even before you received the whole thing.

It seems that with the progress made by CSS2 with absolute positioning and  
floating elements and so on, it's sometimes very difficult to know when  
you can really display something without waiting for something else.  So,  
is there, in your experience, is there any way to make sure when you are  
really allowed to display something that you are sure won't be changed  
depending on what comes next on the float?

HWL
I think that for browsers on screen that have an endless scrollable area  
the problems have been worked out.  For example,  if there is an  
absolutely positioned element at the end of the document and it says to  
display it at the top, you just add it up there afterwards and the  
limitations seem to be able to handle that quite well.

VQ
Well, if it's a floating element it might have to make some room at the  
top of the document then if you receive it at the end you have to change  
the top.

HWL
No, because the floating appears left and right down there.  It can't move  
upwards. It can't float to the top of the page.

VQ
No, but to the top of the element.

HWL
No, well the constraint rules in CSS that it cannot go above the line  
where it's defined at.  That was specifically put in there so that you  
don't have to push things aside further up.  So, we have actually thought  
about that one and I believe that works for all CSS implementations in  
browsers.

Where I acknowledge that there are problems though is for printers, for  
example.  Cause some of these printers want to put CSS into very cheap  
printers now, $50 printers, and if you find an absolutely positioned  
element at the bottom there and it says go to the top of the body element,  
what does that mean?  It means you have suck in all those pages you've  
printed and put it back on.  That's not going to work.  So we have work  
out some issues there.

VQ
Okay, I guess, I have a few more questions but I probably have to leave  
some time for my colleague to address some other issues but still, let me  
just consider another aspect of CSS.  The way you can use it and to what  
extent you can apply it to other languages, than HTML, because it was  
designed for HTML in the old days but now you may use it in many, many  
different languages.   And so, well there are a few issues related to  
that.  For instance, you don't say much in this thesis, about the use of  
CSS with SVG for instance,  or with MathML, and there are many other  
languages that actually use CSS.  So,  what do you think of the, is there  
a limitation to the scope of CSS?  How far do you think it can go?  Does  
it make sense, for instance, to use CSS in MathML?  And do you think that  
other languages will require, like SVG, that you extend CSS a little bit,  
to add a few more properties?  So what do you think about extensibility of  
CSS related to the variety of document languages.

HWL
I think your observation is correct.  Mark up languages come along and  
they want to have a way of applying different stylistic properties to  
their elements, and CSS is an easy way to achieve that.   And probably  
some of these languages will make demands on CSS as well.

  I don't think that's the ideal way to move forward though.  As I said in  
my talk yesterday, I believe the other way around works better, where mark  
up languages are developed in the context of a formatting language so that  
a mark up language shouldn't come and make demands on CSS, it should be  -  
CSS is the platform and then you develop on top of that.  So that that may  
actually change your mark up languages as we saw with MathML.  MathML is  
not ideal to work with CSS and we could change CSS so that MathML can  
remain unchanged but currently it is much harder to change CSS, because  
CSS is deployed and it's going to be there and making changes now is  
really too late.  Comparably MathML is relatively little used.  It may  
sound arrogant coming from me, that other people have to change, I don't  
want to but I think that reflects a state of the world.

I do think that microformats have a great potential of coming up with  
wonderful mark up languages that work wonderfully with deployed browsers  
out there and that's really where I want to use some of my research time  
in the future.

VQ
I agree with you, it's true for basically text formats.  But when it comes  
to graphics, mathematics, multimedia, this kind of things, so you probably  
have to do something else.  Just building on top of CSS is probably not  
the right way to go.  So mathematics, is probably something just between  
text and graphics, you know, and it works more or less; you have shown an  
example yesterday.  But I have not seen any simplest thing in mathematics,  
which is a subscript and a superscript - so this doesn't work, for  
instance.  The very simplest thing in mathematics you can't do it using  
CSS or HTML as it is.  The same for roots, square roots.  So there is  
probably a limitation somewhere but it is not easy to know.

And what do you think about SVG?  SVG is using a lot of CSS for a lot of  
things and still it required CSS to be extended a bit. Which works well, I  
think, in fact for SVG.  So do you think it will happen for other  
languages?

HWL
Yeah, yeah, I think it is possible to reuse some parts of CSS without  
doing the whole thing.  For example, you can reuse the sytax.  People have  
taken the CSS syntax and made transformation languages out of that.  The  
concept of selectors, the concept of properties, and setting properties on  
various elements is very useful, no matter what domain we're in.  And  
that's how SVG uses it as well.

The problem arises when  those groups want to change the formatting  
model.  Are they bound by the CSS formatting model?  Or can they supply  
their own formatting model? And for SVG, I think the answer is a little  
bit of both. And that has created some tensions.   Because when they have  
come up with new properties or added values to existing properties, that  
they have legitimate needs for, the CSS group doesn't necessarily agree  
with that and the additions aren't compatible with what we had in mind.   
So now we are at a level of social and political conflicts rather than  
technical.  But there is also a technical aspect there.  What parts of CSS  
do you want to use? Will you limit yourself to the sytax or do you accept  
the formatting model?  If you accept the formatting model, do you want to  
extend it or is it enough for you?

I think the CSS formatting model is sufficient for document-like  
presentations.  If you want to go beyond that, as I showed yesterday with  
the canvas element, I think you can do wonderful prototyping for other  
sorts of things.  With those two models, I think we can do very  
interesting experiments in the time to come.

VQ: Thank you.  I think that's it for now.

Convenor: I then thank Vincent Quint for his contribution. I then call
on Ethan Munson to close the ordinary opposition.

EM: I will start today with some general comments and then turn to the
question style of it we have been following. Vincent and Håkon have
both quoted me in saying the style sheets are under-researched and I
will say again that they are under-researched and tell a small
anecdote about myself. In 1995, I was a young assistant professor in
the United States and, as we are obligated to do, I sent a grant
proposal to the National Science Foundation asking for research money,
proposing to continue to study style sheets as I had in my
dissertation. And I remember very well one of the comments of the
reviewers who said "Shouldn't Microsoft be doing this?" And, the
answer was actually that Microsoft was, to some extent, doing this. It
wasn't that Microsoft wasn't, but they certainly weren't giving me any
money to do it and the strange thing was that is was seen as such an
unimportant, mundane topic, that was outside the purview of academic
study, which bothered me, but frankly perhaps I wasn't articulate
enough to convince people that it really was so important.

Now thinking about Håkon's work and about his document, his
dissertation, I want to say it's an unusual degree. Because it's using
essentially an old fashioned model of the PhD here at the University
of Oslo, that you would not find in the United States, where Håkon has
acted as an independent scholar, who has produced his dissertation and
arrived at the University and said, "I would like a doctorate. I would
like you to evaluate my dissertation." And we are now in the final
stages of that evaluation and I think you can see that evaluation is
rather positive to this point perhaps we'll decide otherwise but it
doesn't seem very likely.

That's one way that it is unusual. Another way that it is unusual,
that several of us have observed, is that this room contains perhaps
eight, maybe ten, people who are among the major contributors to style
sheet languages in the world. And I'm not near the highest level of
that contribution. While I studied them and I may intellectually know
as much or more than anyone else, I have no fame, to be honest. I am
not a famous person at all. But there are people in this room who are
well known, in many cases for their involvement directly on the topic
of this dissertation. The centerpiece of this dissertation, Cascading
Style Sheets, is running on over 99% of all the computers in the
world, that people use directly in front of them. Perhaps not on every
computer that sits in a back machine room but among personal computers
with screens and user interfaces, over 99% run this software in one
form or another, perhaps not the most modern version. The number of
PhD candidates who can make that claim about their dissertation, at
the time when they are defending their thesis, is tiny. And that fact,
and the attendance of the varied experts who are in the room, speak to
the quality of the work and to the quality of Håkon's personality.
That we all get along with him and respect him. He treats us with
respect and we do the reverse.

In addition, as Vincent noted, the work is fundamentally
collaborative. Håkon's primary collaborator in CSS1, Bert Bos, is here
in the room and several of the other people in the room, Joe English,
who I have never met before, in fact we haven't been introduced yet,
and myself and Vincent, in varying ways contributed to the thought.
But at the same time, particularly in the modern context, thinking of
the recent events in South Korea, for instance, I want to be clear
that I am certain that the work that we are evaluating today, the
dissertation and cascading style sheets, is substantially Håkon Lie's
work. He is not claiming my work, or Vincent's, or Bert's, or Joe's as
his own. He is describing something he did himself and his
dissertation is extremely clear about what he did, what he shared with
other people, what his influences were and perhaps it's not perfect
but the lack of perfection is only limited by human limitation, normal
human limitation, to remember or to describe what really happened.

Finally, I want to say, like Vincent, I found the survey part of the
dissertation, the part that studies structured document systems and
style sheet languages, to be one of the finest summaries of that body
of work that I have ever seen and that has been lacking. The quality
of the writing is very high and the intellectual analysis is also of
the first order.

In regards to the other contributions in the dissertation, the ladder
of abstraction is not a technical concept in a deep sense. It is a
broad, intellectual categorisation of a body of work. I think that
there is scope for disagreement about some of the classifications in
it but that's okay because in reality it's an attempt to digest many
abstractions across several different considerations in language
systems, in document systems... and, but, like, oh, the waterfall
model in software engineering, it presents a way that you can talk
about what's going on that is useful.

In terms of the criteria for style sheets in general and for style
sheets on the web, I think those criteria are sound and they present a
good taxonomy of the language qualities that need to be considered
about any style sheet language and I find that it will be
intellectually useful to me and I think it's a good point for other
researchers to start from.

And then finally, the cascading style sheets language in general as I
have said in some other venues, cascading style sheets has a
wonderfully clean syntax. It's very easy when you are designing a
programming language, or some other specification language, to muddy
up the works, to put in extra little pieces of syntax that are not
necessary to get the job done, to add features that no one uses, the
protective feature in C++ comes to mind, and that's very hard to
avoid. I think the reason for this being the case, is that someone,
Håkon, Bert, whoever, was conscious of what had come before with the
languages. There had actually been experiments, they were substantive,
they ranged from Scribe and LaTex to other more pure style languages
and those lessons where clear enough, and Håkon and the people
observing were smart enough to draw those lessons well. And they have
designed essentially a very sound language. I have little complaints -
so what? That's not the important thing.

Let me think. So, those are my broad comments. I'm extremely pleased
with the document that I read. I was happy to read it and I am very
happy to be here as an, what's the word? Opponent. I don't feel very
opposing.

But that said, I will now turn to my opponent role. And I'll at least
start by taking a different approach then Vincent. I'll take a more
traditional professor's approach, thinking about foundations issues of
computer science and how they relate to cascading style sheets. And
then I may turn to some details and cover some of the same territory
that Vincent thought about. But I'll start thinking about issues in
programming language design in general and issues in software
engineering.

So in the area of programming languages, and in reading your document
one of the things I was struck by was the lack of mention of
traditional programming language concepts. In traditional imperative
programming languages, and object oriented languages, it's very common
to discuss what the type system is, to describe how various kinds of
computations are performed, to talk about the scope of definitions and
to talk about the binding of values to something that holds a value.
Yeah, I think I would say that. I wonder if you can expound briefly on
the relevance of those concepts and if they exist at all, if they play
any role in CSS?

HWL: Certainly. I think if Bert Bos had written his dissertation --
no, he has a PhD already so he doesn't have to write one, but if he
had written it -- those areas would have been given more weight. I
must admit that this is not my strong side. One of the reasons why I
never studied at the University of Oslo in computer science
traditionally is that here they're very good at programming languages.
They have Simula, their pictures are hanging on the walls and they do
all sorts of theoretical proofing and things, which has never really
attracted me. Or, to be more honest, it scared me.

Also, I think, one influence of CSS is that it should be usable by
designers, not by programmers. We wanted to get away from a world
where people had to be LISP programmers, which was the case for DSSL.
We wanted to have a simple declarative, declarative is a difficult
word to use because DSSSL is also declarative, as you know in the
computer science meaning of that word, but we wanted to have a simple
language, where people who came from the desk top publishing world
could feel familiar. Of course, we also need to deal with scoping, and
we need to deal with syntax and we do that in the simple example I
should where you have a scope denoted by these curly brackets to which
the selectors apply. So, certainly the concepts exist. Bert has
handled more of those issues in the design process. I don't find them
very interesting, and therefore probably that's why it's reflected as
not coming forward very strongly in the thesis.

EM: Let me try a somewhat stretched analogy here about binding. You
have the classic example H1 whatever some selector and then you have
some rules and that connects a set of stuff to another set of stuff.
Connect - bind. Is there something that, is there any more analogy
with programming language than imperative programming languages than
that or is there something about style sheets that is so fundamentally
different that that traditional concept of binding doesn't work? I'm
struggling with this too, so I'm just trying to...

HWL: Certainly, well, at the very superficial level, it is influenced by the C  
programming language by using these characters instead of other  
characters, but in general it is not an imperative model we are looking  
at.  For example, the assignments can come in any order in CSS, it doesn't  
matter.  So we are more influenced by languages like Prolog, Mercury that  
are more constraints based and declarative in nature where you evaluate a  
set of constraints that have been placed on a body of data and you end up  
with, in our case, formatting.  And one of the implementations of the CSS  
formatting engine, the one that's used to create these pdf documents is  
actually implemented using Mercury for that purpose.  It actually uses the  
constraint based nature of that language and takes advantage of that in  
the evaluation of the CSS statements.

EM
I think you're right.  I think your analysis is right.  I think the reason  
those issues didn't come up, for you, may perhaps mean that they aren't  
that relevant;  that the, particularly scope and binding is classic  
programming language concepts have to do with variables, primarily, and  
there are not variables...

HWL: Yeah, there are no variables

EM: There are no variables, because the things that you want to bind
something to are living in some document that you don't even know what
it is yet. And so the binding comes from the selector, connecting the
selectors to documents and it's not in the language.

HWL: People have asked for variables along the way because they could
shorten their style sheets a bit if they could set a variable and just
reuse that variable throughout, more macros they have also asked for.
We have resisted that idea. In order to keep the number of building
blocks in the language to a minimum.

EM: So let me turn now to software engineering concerns, before I use
up all my time. You do describe in the dissertation the criteria for
style sheets on the web. These criteria are, I think, a set of
requirements in the traditional software engineering sense and you
actually do discuss in the dissertation what are the requirements for
-- you use that word from time to time -- but I'm wondering if you can
make some broad statement about the development process that CSS saw.
You talk in considerable detail about it, but perhaps not with the
terminology of traditional software engineering.

So, examples of questions I am curious about are: where did the
requirements come from? Or were they specified after the application
was built or where they specified before? So, when, who had control of
the requirements, if anyone? and to what extent were they formally
defined?

HWL: They were not very formally defined. The requirements as I have
formulated them in the thesis is entirely written afterwards, in
retrospect. So in that sense they come in the wrong order. Since CSS
was one of the first specifications that were developed in W3C, there
weren't very many formal rules about how to develop this or how to
publish it. And later, one has, now, at least it's customary to
establish a set of requirements before one starts to develop a new
specification. I'm not sure if that's a good idea or not. I go back
and forth on that issue. If you have strong requirements, I think you
might end up with something which is bigger and more complex than
ideally what the world wants to see. But it's certainly one
methodology which is commonly use in specification development.

EM: I think I'll comment on that. I saw a very interesting talk at a
software engineering conference by a British software engineering who
talked about the contrast between normal design and radical design.
And I think normal design is when you are building a bridge over a
highway today, the distance may be different from the last one you
built, the weight may have some different parameter, but you're
building something that everyone knows how to build. The only question
is perhaps there's a new kind of steel that's a little lighter, or a
little less expensive then some other kind, and you have to change
your parameters. But it is normal design because it is in the bounds
of what people have always designed, or not far from that.

But with cascading style sheets, and most things that we do on computers,  
frankly, are radical design.  We are designing something that has never  
existed before and not in its full form and we must, it's hard to have a  
rigorous traditional process of saying what you need, and then deciding  
how to make it.  Because of that, and so I don't think that is abnormal  
but let me then turn from requirements to the design process.

How formal was the design process?   Did you use any modeling techniques  
other than just writing texts to each other?  And to what extent was the  
design process controlled? Where did the control over how the decision  
were made rest?  Who was the W3C?  Who at the W3C could say "Yes, we can  
do this. Let's go."

HWL: It's an interesting area of study, how specifications are
developed. For CSS there are various phases. The first phase is where
I was sitting alone, cooking up a proposal and throwing it out on the
web. Bert did the same a few months later. Then we worked together and
we worked on a white board in the same room, many hours a day and
actually writing syntax on the board, doing rectangles, making sure
that the formatting model was consistent as far as we could prove on a
blackboard. But we didn't use any formal tools. One idea that we
wanted to do, and I think there was a graduate student working on this
some where in the world at some point, but he got a job - this was the
dot com era. He actually tried to formulate CSS as a set of
constraints to see if it was internally consistent. I think those kind
of tools would have helped us. But it was also very productive just to
work on a black board. See if you like the syntax, see if it feels
natural to write this thing. And I can probably point to several areas
where we have dropped functionality because we couldn't find the right
syntax for it. If we had started out with a set of requirements
instead, you have to find a syntax for this. It would have looked
different. I think the syntax matters. If I can't show a picture on
the projector, one page to show how the fundamentals of the language
work, than it's not going to fly.

EM: So considering this overall process - requirements only implicit
and people's ideas about where the system needs to go and a design
process that certainly was not formally based in the formal methods
sense or something like that, but the design was done somewhat more
formally, in that you have multiple people talking about it, trying to
share their ideas and communicate, can you see any strengths or
weaknesses of CSS that derive from the process?

HWL: I think we were able to establish, since there were so few people
involved in the first design of CSS, we were able to put down the
foundations with only two people in the room, basically. Although a
lot of people contributed on the mailing list after that and in the
working group after that, having a solid foundation that was not
designed by a committee was a big strength. I think perhaps today one
establishes a committee a little too early before you have a good
design in place. So I would say that is one strength that we had.

EM: Okay.  Perhaps just a few more questions.

Now I have a series of smaller topics that are connected to CSS in
particular and have some overlap with the concerns that Vincent
addressed. One of them is about the broad classes of style sheet
languages. I guess I would, I am not sure anyone else would use this
label, but I would describe CSS as being a property value language.

HWL: Yep.

EM: You have a collection of properties that you are going to use,
that everything you are going to format is relevant to some large
subset of those, maybe the subsets are different depending on the what
the object is. But essentially you're just saying " For this property,
here's a value. For this property, here's a value. For this property,
here's a value." And you have this binding mechanism, that we waved
our hands at. And then you have the other paradigm which you know that
several people in the room are not fond of, is the transformation
paradigm, where you take a document in one form and you turn in into
something else that has a semantics for producing pixels on a printed
page or on a screen,or producing sound levels as they come out the
speaker. And then there's a final, perhaps not independent, model,
which is the constraint model, which Vincent and I to varying degrees
have been interested in. And there's work that you don't cite that I
think you know about by Greg B on constraint cascading style sheets
that also has explored this topic. And I wonder if you can discuss
these three categories and kind of what their strengths and weaknesses
are and why it makes sense that CSS is a property value language.

HWL: I think your sorting into three categories is interesting. I
haven't thought of it that way. But I can see that it makes sense to
do so. I would argue though that all languages end up being property
value languages in the end. Even in XSL when you transform into
formatting objects, those formatting objects are elements that has
properties and values. And with P and PSL too you use the concept of
properties and values. But there are differences. The transformation
step is unique to the DSSL, DSSL Lite, XSLcatelgory of style sheet
languages and then your own flavor,the constraint based approaches are
distinct and I think they're interesting in the sense that to
formulate a formatting model especially through constrainst is an
admirable approach.

EM: An admirable goal!

HWL: An admirable goal. I think the reason why the CSS didn't go
further in that direction is that we weren't sure whether we could
have internally consistent models. For example, the progressive
rendering was very near and dear to us and if you have constraints its
easy that they go backwards

EM: Yes

HWL: So we didn't feel confident going all the way there. Therefore
you will have some notion of constraints in CSS but it is not fully
flavored.

EM: My observation would be that I think the transformation approach
is one that seems to appeal to certain people naturally and once
someone likes it, they seem to stay with that model. The constraint
approach can be mixed in with the property value languages more easily
and it appeals to Vincent and I in its generality and its ability to
go beyond text in a comfortable way. But I don't think anyone has
produced a satisfying run time system for such a system.

A final thing I will ask just as... related to multimedia, that you
alluded to when talking to Vincent, is about the problems of handling
new applications, of extending the formatting model beyond the
essentially text typography oriented model that CSS holds to. And as
you discussed, and in fact argue in your dissertation, that the fixed
property set that CSS provides, where there is a formatting model,
it's clear what the fomatting model is, makes the language better. At
least in practical terms. But it presents the problem that if you want
cascading style sheets to support 2-D graphics, 3-D graphics, animated
3-D graphics, sound, music in the MIDI sense, you need a lot of
properties. And for most documents, most of those properties will not
be relevant. So you'll end up with a specification like this where
each user only needs so much even if they're an expert in their
subdomain. Is there a direction to go that is actually practical?

HWL: I don't know. We considered one idea along the way it was
rejected in the end. The concept of media independent properties, like
for aural presentations, volume is central and for textual
applications, font size is central. So you could have a sort of value
between zero and ten for a media independent property that maybe we'd
call volume and if you're visual it would end up as a font size,
aurally it would end up as volume. But that's an obvious example that
works but when you get to the sort of margins and floating and stuff
there are no obvious corresponding. So, I do think we need to address
each medium with a set of properties that are suitable. We can find a
few things, like color works independently in graphics as well as
text. But sometime you just have to come up with new properties. I
think CSS and the formatting model associated with CSS is suitable for
2-D graphics with rectangles but that's not going to take you far in a
graphics world. They want to have triangles and all sorts of things.

EM: Oh yeah and being able to rotate and bind things to round corners

HWL: Exactly, there are limits to the formatting model.  But I do think the  
syntax can be used, as SVG actually does.

EM: To close the opposition, I want to follow up on that. Thinking
about, not about the properties and how to avoid the explosion of
property types, but about the language itself, does the XML name
spaces model offer a possible direction for bringing collections of
properties in? Does that, actually, I haven't honestly thought about
this

HWL: I hate namespaces.

EM: I don't care if you hate them. Can it work? And is there some
kernel of an idea there about mixing in stuff that would be
successful?

HWL: I don't think so. Just as it has proven author unfriendly to
import vocabularies of names spaces not really in use, I think it's
going to be even more difficult to import a set of properties and
expect the formatter to deal with them in a natural way. Formatters
are really quite delicate, advanced engines and just like you can't
pump deisel into your gasoline car, you can't expect a formatter to
just accept a bunch of new tags even if it has a declaration in front
of it. 

EM:  I think that concludes my questioning.

Convenor
I then want to thank Ethan Munson for his assistance.  Finally, does  
anyone wish to speak ex-temporae.  It's been mentioned that there are some  
important people are in the room.  No?  The committee..

HWL: There's a question there.

Convenor: Yep?

Questionner #1 (Gisle?): I'm not one of the important people in the
room, but since none of those decide to speak up, I'll take my
chances. The thing I want to ask you about is this thing about
extensibility we were discussing earlier in the discussion. You
mentioned that you were quite enthusiastic about microformats and you
sort of saw this as a continuation of your work. One thing that
generally puzzles me is that you clearly don't like name spaces, and
you don't like XML with private...way down on your ladder of
abstraction, whether you could explain briefly to me, what's exactly
microformats. To me it the same mechanisms as names spaces and XML
with private vocabularies. So can you explain what makes you
enthusiastic about microformats and less enthusiastic about XML with
private vocabularies.

HWL: Yes, a couple of things.  First, I think you are right in saying that name  
spaces and XML have some of the same mechanisms.  You can write and XHTML  
document and you can through an interface import other tags and thereby  
build on the well known semantics of XHTML and add your own tags on top of  
that.  And that is basically the same that microformats are doing.  Their  
building on XHTML using the HTML tag set, or XHTML actually and just  
adding sematics through the class attribute.  The difference here is that  
the class attribute works much more seamlessly with the currently deployed  
formatting technology that's out there.  Basically, it works in IE6.

Questionner #1
...private unknown semantics

HWL: You attached, I used an example from the book we did yesterday,
you added class names to div elements. You said div class equal
introduction, div class equal chapter, preface, appendix etc, so you
basically split an HTML document into several parts which correspond
to parts of a book. So the semantics, it's not really deep semantics
as in AI, but it's enough semantics so you can attach style to it.
Sort of a hook where you can inject style and out comes your printed
book. And I think similarly other microformat project will do the
same. By using the class attribute you can a. attach presentational
information to it but also if this catches on and becomes popular,
Google will start using it as well. I know they're keeping a close eye
on this. And we haven't seen the same thing happening for name spaces.

Convenor: Any more questions?

Steven Pemberton: So, my name's Steven Pemberton. You showed some
examples from CSS Zen Garden, which I often use as well, to
demonstrate the success of CSS but one of my great problems with CSS
Zen Garden, is that because they're pixel perfection, you can't reflow
them anymore, you haven't got any control over the font size. That if
you can't read that font size you are out of luck, in most browsers.
Now I know Opera is an exception here but do you think that CSS from
that point of view has been damaging for accessibility.

HWL: Ummmm. No.  You're right.  They are doing some tricks here.  They're not  
just styling the text, they're replacing the text with images.  And if you  
see the particularly cute group of people there, one arguing for table and  
the other for CSS, on top there, that's of course text encoding in an  
image.  So that text isn't accessible.  So I agree that there are  
accessibility problems.  But even in other browsers that don't have all  
the accessibility features of Opera, you can turn off the style sheet  
typically.  So if you do that here, you do get back... woops,sorry I was  
dealing with a screen shot and not my... (laughter)  you do get back to that  
document where all the text is available. Whereas I agree that some CSS  
code has been abused to create visual effects only and some of the designs  
in CSS Zen Garden are dancing on the edge of that, all in all, CSS has  
been very  beneficial for accessibility by stopping people from using all  
these images for text.

Dag Asheim: I see you point to the thesis itself as an example of how
you could use CSS itself for printing but I see you used ragged right
style without any hyphens, is that a coincidence? I see on page 44,
it's a table where you where you have some strange word breaking level
of complexity in the table. Is that a limitation on the hyphen side of
this?

HWL: Yes, it's actually a limitation in the Prince formatter. Browsers
don't support hyphenation unless there is a hyphen or a soft hyphen
character it will not break words. In print you are expected to break
words. So that is something that the Prince developers are working to
add now. It is fairly easy to do so, you can just steal the code that
Donald Knuth wrote for TeX. That is freely available but that's not
been put in place yet. And I agree that these are not enough. What I
should have done here, I should actually have injected soft hyphen
characters so that the formatter would know where to break and replace
it with a dash in it. So you are right in pointing out a deficiency. I
must admit while we talk about deficiencies, there are a few typos in
the conclusion and I am sorry for that.

Convenor: Okay. Then the committee will leave and evaluate the
disputation. And when the committee have made a decision we will
return.

...

Convenor: So the question is has the committee found the disputation
satisfactory.

VQ: Yes.

Convenor: Then we can congratulate and applaud.

(Applause)

HWL: Thank you.  Thank you Vincent good questions, nice discussion

VQ: Congratulations.

Convenor: So I hereby declare the proceedings are concluded. A report
will be made to the department of mathematics and natural sciences.
Thank you.

HWL: Perfect.