[This is a transcript, courtesy of Karen Mosman, from the lecture on
"Style sheets and the challenges related to the dynamic aspects of the
Web" given on February 16 2006 as part of my PhD Defense. HWL is me, 
Håkon Wium Lie]

HWL: Perfect!  I've been allowed to start.  So we're just going to start and  
this time it is the topic which has been given to me.

I should say that I think it's interesting topic. I feared a much more
boring and difficult topic. This is not easy but it's very interesting
and gives, allows us to look a bit ahead which I'll try to do along
the way. The one clarifying question I had to Eric when I was got this
topic was whether I should consider dynamic aspects of the web to be
the web as a whole as in the web growing and being a dynamic -
extending, or whether it was on a per document basis. I was told, or I
assumed actually, that we're taking about the documents, the dynamic
aspects of web pages, not the web as an organism. Which I think is a
reasonable assumption.

Ethan Munson: Vincent and I would agree.

HWL: You agree with me?

Ethan Munson:  Yeah. Yes, you assume correctly.

HWL: Okay, thank you.  Otherwise, I would have had a problem.

Ethan Munson: The other question is a fine question too. I'd be happy
to hear that presentation.

Crowd: Next time... next time...

HWL: That's not going to be me.

I still think it's worth to look a bit at the title, like I did in the  
first talk.  I am not going try to define style sheets and web again.  I  
assume that by now most of you have been through that or can guess what I  
mean when I say the web so those term I consider to be well defined.  The  
term dynamic though is still worth a discussion.  What do we mean by   
dynamic web page?  And I looked at the dictionary where you turn when you  
need ideas.

Dynamic - characterised by continuous change, activity or progress, which  
I think is a fine, reasonable definition.

But then you need, that's the adjective and you need the noun. And
that's dynamism - continuous change,activity, progress, vigor. Which
also makes sense. But I don't really think the word dynamism is, I
didn't really like it, and I came up with a new word, which is not in
the dictionary. It is dynamicity. Which I think sounds much better. It
sounds much more dynamic than dynamism. Doesn't it? And it turns out I
am not the only one who has thought of this word. You go to Google and
you search for dynamicity and find all the pages that uses it. And
actually one guy has written up a page why he's using this. He himself
was writing a book on the Ruby programming language a few years ago
and he wanted "a word that conveyed the notion of dynamicness, the
quality of state of being dynamic. Someone suggested dynamism, the
technically correct term, but it didn't feel right to me in some way I
could not define or specify. So I did a web search... " You know this
is what we all do when you are going to write about the web. You come
up with a term you like and then search to see if someone else has
done it. This is the network. So this guy did exactly the same as I
did, only he did it three years ahead of me. But it turns out that
maybe dynamicity is a word that should enter into the vocabulary in
some way. It is analagous to the word specificity which we have used
extensively in CSS to describe the specificity of a selector, how
specific a selector is, a certain selector in CSS is. Specificity is
actually in the dictionary but it's rarely used. Dynamicity, I bet is
going to be there in five years.

So if we accept the term dynamicity we still need to describe what we mean  
by it in the context of dynamic web pages.   I think dynamicity can be  
measured in three different ways on the web.

The first is a visual expression - when something changes on your screen,  
whether it is something blinking or moving you have pixels changing their  
values along the way and the rate at which those pixels change can be a  
measure of dynamicity, visual dynamicity.

Then you have user interaction, when you interact with a document, if you  
get feedback, if there is communication along the way, I think that also  
makes a measurement for dynamicity.

And then there is network communication.  Most web pages that are  
considered to by dynamic these days will use a combination, at least two  
of the these.

I will go through each one of these more to define more what I mean with  

We'll start with visual ah dynamicity. Um, hat you saw there and I'm
sure everyone's eyes were attracted to the, to the right side with
the, with the ah little insect moving... Um That's an animated GIF
image. GIF is one of the fundamental image standards for the web. It
has been there since the beginning along with, along with JPEG and and
PNG. Png was developed a little bit later and it was put forward as an
alternative to GIF because GIF had a problem with patents. And we all
thought that everyone would start using PNG instead because PNG
offered better compression and it had all the open source and open
standards feel feel to it -- but it didn't really. And I think one of
the reasons why it didn't was because it didn't offer animation and
people got addicted to gif animations once they saw it and PNG
unfortunately didn't offer that. So GIF images are -- animated gif --
images are popular still on the web and we see them a lot.

Also CSS has some dynamic effects. There is the the hover
pseudo-class, which, when the pointer hovers over a certain element
you can apply a different style to it. Um so... there should be
actually an element blinking here. I don't know why it doesn't blink.
CSS has the concept of blink. You can say "text-decoration: blink" and
have this element be turned on and off and it worked I swear
(laughter) when I tested this (laugh).

Most people though when they talk about dynamic web pages they talk
about, they refer to something that's called dynamic HTML which is
term that was put forward by browser vendors, by Netscape and
Microsoft basically in the late 90s. It is a combination of
Javascript, a programming language supported on the web, DOM, which is
the document object model, and also CSS properties. And what goes on
there is that the Javascript manipulates CSS property values -- the
most popular are top left visibility and display and by setting values
on these properties -- on certain elements you can actually achieve
some stunning visual effects. And I'm going to show an example here.
This is a web page. This is HTML and these elements are moving around,
and they are, you know, simulating these gravitational forces. So,
this being a web page it shows that it can be actually very

If we look at the history of dynamic HTML and compare it to CSS we'll
see that they mostly run in parallel. In 1994 CSS was first proposed
but it was still far away from implementation and deployment whereas
on the JavaScript side we see that Livescript, which was the first
term used to describe Javascript was launched in 1995 when Brendan
Eich started working for Netscape. In 1996, the next year, CSS had
matured into a W3C recommendation and we'd actually had one commercial
implementation -- Internet Explorer version 3, which also by the way
supported Jscript which was Microsoft's implementation of Javascript.
Javascript was also supported by Netscape's browsers but I don't list
them because they didn't support CSS at the time. That only happened
the next year in 1997 when Ecmascript was released as the standardised
version of Javascript and it was supported by IE4 and Netscape 4.
Since then, with Opera joining, CSS and Javascript have both been
implemented by browsers. If you were to display a page written from
1997 and onwards, you really had to support both those specifications.
So, we've had CSS and Javascript all along but there has been tension
between the two one can say. I'll say a bit more about that that
later. But that's really the visual dynamicity. Now we're moving to
the next form of dynamicity, the user interaction dynamicity.

Menus is the most popular example here. A lot of web pages use dynamic
HTML to show menus, to have popup menus. For example this is done in
Javascript and CSS, it's setting the right property values on the
right elements so you can have menus pop up and it looks and feels
like the menus you are used to from from GUI applications.

There is also the simple video games which use keyboard controls and
actually offer some rich, or a different mode of interaction. I am
going to try show one of those um as well. This is a classic game
being authored using HTML, CSS and Javascript and it gives you the
Tetris that we all know. There is still quite a lot of functionality
missing though still a lot of things you cannot do with Javascript.
Uou can't do drag and drop easily, for example. That is not being used
on web pages you don't see drag and drop implemented. I've seen
attempts, but it's not really worth it. But menus are very, very
popular and we see them on most major web pages will use dynamic HTML
for menus.

Then there is the third type of dynamicity -- the network dynamicity.
And this is actually quite quite recent that this has become popular.
It's a little bit surprising because Internet Explorer 5, I believe,
introduced this in the 90s but it didn't really become much used. I
don't know if was that people didn't know about it or they didn't care
to use it. But over the last year or two it has become very popular
and we're seeing a lot of web pages use the XML HTTP-request, which
it's called at a technical level. Scripted HTTP is a better term to
describe what goes on here. Basically it allows a script linked to a
web page to communicate back with the server, to open a network
connection back to the server and exchange data back and forth.

To show an example of this um I've picked Answers.com -- again
Valentine's Days was a productive day for me. Answers.com offers an
online dictionary where you can search for terms or flights or other
things that you might be interested in. I could get roughly the same
thing with Google but I thought it would interesting to showcase some
other companies as well. I'm not online here so I can't show you this
live but you will see here from my screenshot when I search for
dynamic and start typing that the web page will come back to me and
will suggest some topics. So, for each key press that I type, the
Javascript running in the background here will look at it and go back
to the server and back with results and suggest them to me so I don't
have to type them. That's a very important on the mobile side for
example where typing on a small keyboard is hard or it could be that
just for interest. Who knows about Dynaglow heater accessories? I
would never search for that -- maybe it is something interesting.

So this is an example of a web page that uses several of these forms.
It uses user interaction, and it uses the network -- it goes back
and forth on the network and it's also visual. So it's a
combination of all these three forms of dynamicity.

But I though that it would be interesting to see at a technical level
what's going on here. And for the next few slides I am going to be
quite technical but I thought it was -- as I dug deeper into this -- I
saw things that I think others will also find interesting. This is
actually Javascript source code. This Javascript is on that
Answers.com page. If you look in the source you will see a reference
to the Javascript from the HTML and if you fetch that Javascript file
you will get this function, amongst others. The crucial piece of code
which does the network part is here were it actually opens a network
connection, an HTTP request back to the server where it comes from and
it gives it a GET command and then it starts the processing of what
comes back. So if we look at what's being sent across the network now,
now we're at the HTTP level, we're doing a GET from the local page
into the server, into Answers.com servers and we'll see that, here's
the GET that we highlighted in the previous page -- you'll see that I
have started typing here... "dy". That's me typing and the connection
is kept alive, the http connection is kept alive and the next thing it
sends over is "dyn". So for every letter I type in it will actually go
back to the server and see what the server can offer. So that is what
goes from my computer to the server. Now let's see what comes back
from the server. This is also HTTP coming back and you will see that
it also keeps the connection alive. That's really necessary. In order
to get the performance required for this to be a dynamic experience
you really need to keep the connection alive, otherwise it would be
too slow. So here it comes back. It's been sent the letters "dy" and
it sends back an array of possible things that "dy" could mean or
possible things that could be extentions to "dy". And one of the
interesting things I found here is that "Norwegian Air Shuttle" came
back. Norwegian Air Shuttle? But you know if you buy a ticket with
Norwegian Airlines, you'll see that the flight code is DY. They're
probably running out of codes for them if Norwegian Air Shuttle turns
into DY but that's not my problem. Interesting to see. So they know
about this. And we will see that the connection is kept alive so it it
expands here "dyn" and here we have the Dynaglow heater accessories
coming to us and so on.

So although the name for this request is XML HTTP request, it's not
really XML that crosses the wire. Other formats are being used. HTTP
is being used just as a transport protocol for other data.

Dave Raggett:   some people... XML faster...

HWL: It's possible to use XML but it is not required.


So the result of all that network communication and also Javascript  
running to to do the visual things is that it can actually offer me that  
list um,  um in the um web page. And really I think  the time has come to  
stop calling it a web page.   This is really a web application.  Um an  
application, the definition of an application is a computer program with a  
user interface.  And this looks and feels like an application although it  
is coded as a web page.  There is HTML at the bottom here. There is  
Javascript, but there's all these dynamicity things the visualness, the  
user interface, the network that really turns this into a web application.  
So this is really the formula that I will propose, it sort of like e=mc2  
or something... uh not quite (laugh)... that's as far as I will go.  But I think  
it's an important observation that web applications are different from  
documents and we should compare the two and see what the difference is.

If we look at the document, we have documents up here, and we have
applications in the right column, the dyanmicity although it exists
for documents, like the hover thing, it's still quite low dynamicity
whereas applications can offer high dynamicity. Another difference,
and this is more of a theoretical difference than a practical
difference, is the one of Turing completeness. That the document does
not require a Turing complete language in order to be decoded but the
application does. Those of you who have studied computer science know
about Turing completeness I'm not going to go into what that means.
The basic meaning of it is that it is harder to deal with. Yeah?

Ethan Munson:  Actually it's easy to deal with, but hard to analyse

HWL: Hard to analyse.   That's right. (laugh)

So although there is an important theoretical difference between a
document and an application, I still think it's worthwhile to ask the
question whether it's necessary to keep the distinction between
documents and applications. And I know there's different views in this
room on that topic. I will argue that users, from a users point of
view, the user experience is a gliding scale where you can have a
static simple HTML document with no graphics whatsoever, you add an
animated gif perhaps, you add a little bit of CSS, you add Javascript
you have a gliding scale here which from a user's point of view there
is no point in really classifying the two.

The next question then becomes, from the title of the talk, are style
sheets relevant. What are the challenges? Are style sheets gonna be
part of these dynamic web applications that we're gonna to be seeing?
Again, if we go back to the Answers.com page and look not on the
Javascript or network side of things now, but if we look at the HTML
source code for that page, we see that style sheet is indeed part of
this. We have two link elements that point to CSS files and also
further below we have a style element so certainly even though this
would be classified as an application it still uses style sheets
extensively in order to describe the initial appearance of that page.

So you can argue that yes,  style sheets matter.  Most web applications  
use style sheets.  Style sheets are very convenient for setting a bunch of  
visual,  static values which defines the initial appearance of the  
application and it's easier to code this in HTML and CSS than in Javascript.

Also documentation is a significant part of any application and
documention is basically a document so you need, in order to document
your application you still need HTML and CSS. And even when you have
dynamic HTML moving things around on the screen like we saw the sun
and earth and moon going, you need the CSS properties, because what
the Javascript does is basically just to manipulate those CSS property
values. Javascript alone would fail that. If we go to this page here,
if we run this page and suddenly turn of Javascript... sorry turn of
style sheets, if I turn off style sheets, this is what we get.
Javascript alone cannot do anything. This is all what's left there and
it's not quite as exciting.

The other argument coming from the other side is no, style sheets
don't really matter in this world because all stylistic properties can
be set through scripting and there's no longer any need for CSS. You
could actually remove the concept of a style sheet all together. You
would still need have the CSS properties there in place to set the
appearance of these things, but CSS has become merely a supplier of
properties and doesn't have that glamorous position any more.

It's also impossible for cascading to work as it's intended. Cascading
in CSS means that the presentation of a page can come from several
sources. For example, the browser can have an initial description of a
page, the author can supply another description and the user might
have a third one and in the end all these three sources are combined
in order to get the final presentation. That's not going to work when
you deal with scripts because any script can override anything that's
being set in the user style sheet, for example. I think that is a
valid argument. But At the same time I think it is time to declare
that cascading doesn't really work for all but the simplest HTML pages
because as soon as you start you start using any kind of advanced HTML
the coding practices will vary so much that it's very hard for user
style sheets to change the appearance in a meaningful way unless you
specifically target a certain site.

Then you have a third position, which is yes, style sheets may matter
but they shouldn't. We shouldn't really use style sheets for this.
This is an application, applications are programs, we shouldn't use
neither CSS or HTML for this purpose. Style sheets and structured
document formats have been designed for the production of documents
and using the for other purposes is an abuse. If we continue to use
them for this purpose, like we see on most big sites these
days, the result is that we will change HTML and CSS so it become
something it isn't today. It becomes a formatting framework for
applications rather than being a style sheet language for static

Steve Pepper:  You don't really mean that do you, that second bullet  
point?  It's a typo right?

HWL: Do I mean what?

Steve Pepper: Using style sheets in documents is an abuse?

HWL: Some people will say that, oh no, no, sorry, I mean no, no...
you're right, that's a typo, I meant applications here.. ha ha. Thank
you... An alert audience.. that coffee helped!

So I think there are social as well as technical challenges to this.   
These views are, if not widely held, then  held by influential people in  
the community and they need to be dealt with.  I'm not going to give a  
verdict on that view.  It is true though that Javascript when it  
manipulates, when  does all the magic it can do visually,  it does use  
properties, values and units of CSS and that's all it uses and that's a  
very limited part of what the style sheet is but it's a very important  
part still.  These properties, they were defined for static documents and  
if you look at the first CSS specifications that wasn't really considered  
how scripts could change these values  from the beginning it was only seen  
that these values should be used in the style sheet so for example CSS1  
has no concept of specified computed actual values which is needed if you  
are going to manipulate this through to the DOM.  Another example is the  
units for length values, for example if you are going to describe how wide  
a certain boarder around an element is going to be  you can use different  
units for that.  You can set it in pixels, or points, or centimeters or  
inches but if the width is zero you don't need to give a unit identifier  
because really zero is zero whether you measure it in centimeters or  
inches.  But still if you have Javascript that wants to manipulate that  
value after it's been set to zero by adding one to it, making zero into  
one, you don't know what it is anymore, so you really need a unit.  So  
actually, I think it was a mistake not to require a unit on the zero value  
as well.  And as a result when you manipulate this value through the DOM  
you are actually doing it with strings.  You see a lot of string  
manipulation in the Javascript where you concatenate a number and a string  
with a unit identifier, for example pixels, you concatenate it into a  
string and you set it as a value, which is very inefficient from a  
computer  perspective.

Should I be summing up?  I have a few things to show, don't I?  Let's see....

Yes, I would like to show how I think applications will develop in the
future. We've seen web applications in the browser window, being
camouflaged as a web page, I think we are gonna see more web
applications start out somewhat differently. And I am going to try to
do this in a very recent build of Opera where we're gonna run a web
application, but as you can see, it isn't really part of the browser
window, it's a separate thing that lives on the window. Some of you
may have seen this on Apple's dashboard which pioneered this. And what
this is it's really a web page. If we go to the source of this
application, which I am going to try to do live here, this is the code
that describes this application and it's just HTML. We launched this
last week, the ability to make these kind of applications in Opera and
we had a bunch of people submit the applications they had written. So
this is coming from Germany which is why it's searching Google.de and
it's title is Google, but as you can see, it's HTML code and then it
has a link to the Javascript here, base.js which we can also look at,
but it also has, if we flip this application, we can interact, we can
set a different skin, and this actually is all done with CSS. If we
looking into the styles catalogue here, we see that the CSS code here
is really defining the skin, setting the background color to be a
greenish tint. And we will find one such style sheet for each colour
this application offers. So even though this is an application,
application developers still use style sheets because it is simply
more convenient to do so.

So, summing up, I think style sheets are a part of a dynamic web.
Especially the style properties are required. Web applications would
not have been possible to write if we didn't have interoperable
implementations of CSS to base this upon. But it is also true that
style sheets will have a less prominent position. There isn't only CSS
and HTML anymore, there's Javascript as well. And if you follow the
recent acronym naming, the term AJAX has come up. AJAX doesn't have a
C in it. It's Asynchronous Javascript and XML that it stands for,
which I think is a misnomer because there isn't that much XML in these
applications at all, like we saw in the network there wasn't any XML
there. So maybe there should be a C in it but really it just shows
that people don't consider that to be the most important thing
anymore. I don't think that is necessarily bad though. I think it's
okay to play along here.

I can see some improvements where CSS in order to be a good player
could make some changes it could take up some popular dynamic effects,
for example the hover thing which I showed, that was picked up from
Javascript, early. You could do it in Javascript but you couldn't do
it in CSS1 so we added it to CSS2. I think more such dynamic effects,
especially with regard to menus could be picked up. I think the
interface between the style sheets and the property values, like the
length values, zero length values can be improved and one develops new
properties one should keep the relationship with Javascript in mind.

But I do think, to conclude, the main challenge for style sheets in a
dynamic web isn't really that style sheets are going to go away,
they're going to be there, they're going to be a part of it, they're
going to have a slightly less glamorous role. But really the challenge
is a proprietary web where style sheets will not be part at all. As
things look from my perspective today at least, HTML, CSS, Javascript
and DOM, those four specifications form the foundations that web
applications are built on. They are all standards and they will make
the world a better place if they are followed. The challengers to that
set of four specifications though is Microsoft's XAML and it's Adobe's
Flash. And they are proprietary formats and they don't have the same
concept of style sheets at all. It's a much more a closed environment
where you can't peek inside it. I think CSS should happily live
alongside Javascript and HTML and provide that as a platform for
application developers. And the enemy is not really Javascript, it's

Thank you.

Eric Monteiro: A couple of quick questions, if there any?  Anyone?

Dave Raggett: You may remember... adding more interactivity in CSS ..
today if you want to write an application you have to write a lot of
stuff Javascript and would be nice to be able extract some of those
...into style sheets. Do you see much potential for that?

HWL: I think there is a lot of crud code you have to do, especially to
create menus for example. And I think we could extract those into CSS.
The question is, yeah I think it is technically possible to write a
specification for that, that would be useful. The question is can you
deploy enough browsers in short enough time for people to actually
start using this. Because we saw with CSS being launched, being
recommended by W3C in 1996, it really took five years before you
really could start using it, before there were enough implementations,
enough browsers out there. And since the web has grown a lot in size
and there are a lot more browsers out there to replace now and
Microsoft only does an update every five years or so. So even if you
can first a) convince Microsoft to support this and b) replace all the
IE6s of the world, it's going to take too long time.

Dave Raggett:  Do you mean that CSS is basically has been such a success  
that it is its own enemy not the proprietary web?

HWL: In a way I think the success stops it from developing, from
taking up nice things in the future, yes. It's solidified as a
platform. Yeah.

Ethan Munson: I think I'll follow it up and disagree slightly and say
that this is mostly a political issue, in a sense, or business issue
but I think that dominance of Microsoft as a phenomena is far weaker
than in the world at least from my perspective in the US the fact that
Mozilla has substantial, what is it 20% market penetration or
something like that or 20% of machines have it installed and it
functions as well, essentially as well as IE does and Microsoft is
having trouble producing new product. Mozilla is actually more... that
Microsoft even though Microsoft has .... engineers... and so I think the
world is changing a little bit. Microsoft may still be the Al-Qaida of
Open Source but it's, but I don't think they're fundamentally as

Ethan Munson: But I do think you have identified the essential problem
which is, whatever you propose it is going to take a while to get into
any browser. I mean, you can propose it, and if you actually want it
to be a standard, Opera maybe will have it working by the time the
standard is endorsed but the other browsers manufacturers probably
not, and until you have almost all the browsers running something it's
not running.

HWL: That's right. There is an alternative that would work today, and
that's to extract things into Javascript libraries, which you had well
written Javascript libraries that you could refer to, today you would
have it working even IE6. Again you would have to hold your nose, some
of us would have to hold our noses, for that to happen but it is
something that could be done more easily. I think we actually have to
pursue both these ways. I think we're gonna have to get more into CSS
but not hold our breath for it to be used.

Ethan Munson: What if you could make the transition smoother? What if
you could, this would be ugly code, but what if you could add the
features to CSS that you want but make a path by which someone could
use a Javascript implemented parser to identify the presence of that
code in the CSS and can support it with a Javascript library?

HWL: That's very analogous to what I showed in the canvas element in
the previous talk where you have declarative elements within the
canvas element. I think you could do the same thing with CSS syntax.