Even when you are done, you are not done

At the Libre Graphics Meeting 2008, OSP sat down with
Chris Lilley on a small patch of grass in front of the Technical
University in Wroclaw, Poland. Warmed up by the early May sun, we talked
about the way standards are made, how ‘specs’ influence the
work of designers, programmers and managers and how this process is
opening up to voices from outside the W3C. Chris Lilley is trained as a
biochemist, and specialised in the application of biological computing. He
has been involved with the World Wide Web Consortium since the 1990s,
headed the Scalable Vector Graphics (SVG) working group and currently
looks after two W3C activity areas: graphics, including PNG, CGM,
graphical quality, and fonts, including font formats, delivery, and
availability of font software.

I would like to ask you about the way standards are
made… I think there’s a relation between the way Free, Libre
and Open Source software works, and how standards work. But I am
particularly interested in your announcement in your talk today that you
want to make the process of defining the SVG standard a public process?

Right. So, there’s a famous quote that says that
standards are like sausages. Your enjoyment of them is improved by not
knowing how they’re made. 1 And
to some extent, depending on the standards body and depending on what
you’re trying to standardize, the process can be very messy. If you
were to describe W3C as a business proposition, it has got to fail.
You’re taking companies who all have commercial interests, who are
competing and you’re putting them in the same room and getting them
to talk together and agree on something. Oddly, sometimes that works! You
can sell them the idea that growing the market is more important and is
going to get them more money. The other way… is that you just make
sure that you get the managers to sign, so that their engineers can come
and discuss standards, and then you get the engineers to talk and the
managers are out of the way. Engineers are much more forthcoming, because
they are more interested in sharing stuff because engineers like to share
what they’re doing, and talk on a technical level. The worst thing
is to get the managers involved, and even worse is to get lawyers
involved. W3C does actually have all those three in the process. Shall
we do this work or not is a managerial level that’s handled by
the W3C advisory committee, and that’s where some people say No,
don’t work on that area or We have patents or This
is a bad idea or whatever. But often it goes through and then the
engineers basically talk about it. Occasionally there will be patents
disclosed, so the W3C also has a process for that. The first things are
done are the ‘charters’. The charter says what the group is
going to work on a broad scope. As soon as you’ve got your first
draft, that further defines the scope, but it also triggers what
it’s called an exclusion opportunity, which basically gives the
companies I think ninety days to either declare that they have a specific
patent and say what it’s number is and say that they exclude it, or
not. And if they don’t, they’ve just given a royalty-free
licence to whatever is needed to implement that spec. The interesting
thing is that if they give the royalty-free licence they don’t have
to say which patents they’re licencing. Other standards
organizations build up a patent portfolio, and they list all these patents
and they say what you have to licence. W3C doesn’t do that, unless
they’ve excluded it which means you have to work around it or
something like that. Based on what the spec says, all the patents that
have been given, are given. The engineers don’t have to care.
That’s the nice thing. The engineers can just work away, and unless
someone waves a red flag, you just get on with it, and at the end of the
day, it’s a royalty-free specification.

But if you look at the SVG standard, you could say that
it’s been quite a bumpy road 2
… What kind of work do you need to do to make a successful
standard?

Wait a second. How do you make a clear distinction between
marketing and technical comments?

People can make proposals that say We shouldn’t
work on this, we shouldn’t work on that, but they’re
evaluated at a technical level. If it’s Don’t do it like
that because it’s going to break as follows, here I demonstrate
it then that’s fine. If they’re like Don’t do
it because that competes with my proprietary product then it’s
like Thanks for the information, but we don’t actually
care. It’s not our problem to care about that. It’s your
problem to care about that. Part of it is sharing with the working group
and getting the group to work together, which requires constant effort,
but it’s no different from any sort of managerial or trust company
type thing. There’s this sort of encouragement in it that at the end
of the day you’re making the world a better place. You’re
building a new thing and people will use it and whatever. And that is
quite motivating. You need the motivation because it takes a lot longer
than you think. You build the first spec and it looks pretty good and you
publish it and you smooth it out a bit, put it out for comments and you
get a ton of comments back. People say If you combine this with this
with this then that’s not going to work. And you go Is
anyone really going to do that? But you still have to say what
happens. The computer still has to know what happens even if they do that.
Ninety percent of the work is after the first draft, and it’s really
polishing it down. In the W3C process, once you get to a certain level,
you take it to what is euphemistically called the ‘last call’.
This is a term we got from the IETF. 3
It actually means ‘first call’ because you never have just
one. It’s basically a formal round of comments. You log every single
comment that’s been made, you respond to them all, people can make
an official objection if you haven’t responded to the comment
correctly etcetera. Then you publish a list of what changes you’ve
made as a basis of that.

What part of the SVG standardization process would you like
to make public?

The part that I just said has always been public. W3C
publishes specifications on a regular basis, and these are always public
and freely available. The comments are made in public and responded to in
public. What hasn’t been public has been the internal discussions of
the group. Sometimes it can take a long time if you’ve got a lot of
comments to process or if there’s a lot of argumentation in the
group: people not agreeing on the direction to go, it can take a while.
From the outside it looks like nothing is happening. Some people like to
follow this at a very detailed level, and blog about it, and
blablabla. Overtime, more and more working groups have become
public. The SVG group just recently got recharted and it’s now a
public group. All of its minutes are public. We meet for ninety minutes
twice a week on a telephone call. There’s an IRC log of that and the
minutes are published from that, and that’s all public now. 4

Could you describe such a ninety minute meeting for us?

How many people do take part in such a meeting?

In the working group itself there are about 20 members and
about 8 or so who regularly turn up, every week for years. You know, you
lose some people over time. They get all enthusiastic and after two years,
when you are not done, they go off and do something else, which is human
nature. But there have been people who have been going forever.
That’s what you need actually in a spec, you need a lot of stamina
to see it through. It is a long term process. Even when you are done, you
are not done because you’ve got errata, you’ve got revisions,
you’ve got requests for new functionalities to make it into the next
version and so on.

On the one hand you could say every setting of a standard is
a violent process, some organisation forcing a standard upon others, but
the process you describe is entirely based on consensus.

There’s another good quote. Tim Berners Lee was asked
why W3C works by consensus, rather than by voting and he said: W3C is
a consensus-based organisation because I say so, damn it. 5
That’s the Inventor of the Web, you know… (laughs)
If you have something in a spec because 51% of the people thought it was a
good idea, you don’t end up with a design, you end up with a
bureaucratic type decision thing. So yes, the idea is to work by
consensus. But consensus is defined as: ‘no articulated
dissent’ so someone can say 'abstain' or whatever and that’s
fine. But we don’t really do it on a voting basis, because if you do
it like that, then you get people trying to make voting blocks and
convince other people to vote their way… it is much better when it
is done on the basis of a technical discussion, I mean… you either
convince people or you don’t.

If you read about why this kind of work is done… you
find different arguments. From enhancing global markets to: ‘in this
way, we will create a better world for everyone’. In Tim
Berners-Lee’s statements, these two are often mixed. If you for
example look at the DIN standards, they are unambiguously put into the
world as to help and support business. With Web Standards and SVG, what is
your position?

Yes. So, basically… the story we tell depends on who
we are telling it to and who is listening and why we want to convince
them. Which I hope is not as duplicitous as it may sound. Basically, if
you try to convince a manager that you want 20% time of an engineer for
the coming two years, you are telling them things to convince them. Which
is not untrue necessarily, but that is the focus they want. If you are
talking to designers, you are telling them how that is going to help them
when this thing becomes a spec, and the fact that they can use this on
multiple platforms, and whatever. Remember: when the web came out, to
exchange any document other than plain text was extremely difficult. It
meant exchanging word processor formats, and you had to know on what
platform you were on and in what version. The idea that you might get
interoperability, and that the Mac and the PC could exchange characters
that were outside ASCII was just pie in the sky stuff. When we started,
the whole interoperability and cross-platform thing was pretty novel and
an untested idea essentially. Now it has become pretty much solid. We have
got a lot of focus on disabled accessibility, and also
internationalization which is if you like another type of accessibility.
It would be very easy for an organisation like W3C, which is essentially
funded by companies joining it, and therefore they come from technological
countries… it would be very easy to focus on only those countries
and then produce specifications that are completely unusable in other
areas of the world. Which still does sometimes happen. This is one of the
useful things of the W3C. There is the internationalization review, and an
accessibility review and nowadays also a mobile accessible review to make
sure it does not just work on desktops. Some organisations make standards
basically so they can make money. Some of the ISO 6 standards, in particular the MPEG group,
their business model is that you contribute an engineer for a couple of
years, you make a patent portfolio and you make a killing off licencing
it. That is pretty much to keep out the people who were not involved in
the standards process. Now, W3C takes quite an opposite view. The
Royalty-Free License 7 for example,
explicitly says: royalty-free to all. Not just the companies who were
involved in making it, not just companies, but anyone. Individuals. Open
Source projects. So, the funding model of the W3C is that members pay
money, and that pays our salaries, basically. We have a staff of 60 odd or
so, and that’s where our salaries come from, which actually makes us
quite different from a lot of other organisations. IETF is completely
volunteer based so you don’t know how long something is going to
take. It might be quick, it might be 20 years, you don’t know. ISO
is a national body largely, but the national bodies are in practice
companies who represent that nation. But in W3C, it’s companies who
are paying to be members. And therefore, when it started there was this
idea of secrecy. Basically, giving them something for their money.
That’s the trick, to make them believe they are getting something
for their money. A lot of the ideas for W3C came from the X Consortium
8 actually, it is the same people who
did it originally. And there, what the meat was… was the code. They
would develop the code and give it to the members of the X Consortium
three months before the public got it and that was their business benefit.
So that is actually where our ‘three month rule’ comes from.
Each working group can work for three months but then they have to go
public, have to publish. ‘The heartbeat rule’, we call it now.
If you miss several heartbeats then you’re dead. But at the same
time if you’re making a spec and you’re growing the market
then there’s a need for it to be implemented. There’s an
implementation page where you encourage people to implement, you report
back on the implementations, you make a test suite, you show that every
feature in the spec that there’s a test for… at least two
implementations pass it. You’re not showing that everyone can use it
at that stage. You’re showing that someone can read the spec and
implement it. If you’ve been talking to a group of people for four
years, you have a shared understanding with them and it could be that the
spec isn’t understandable without that. The implementation phase
lets you find out that people can actually implement it just by reading
the spec. And often there are changes and clarifications made at that
point. Obviously one of the good ways to get something implemented is to
have Open Source people do it and often they’re much more motivated
to do it. For them it’s cool when it is new, If you give me this
new feature it’s great we’ll do it rather than: Well
that doesn’t quite fit into our product plans until the next
quarter and all that sort of stuff. Up until now, there hasn’t
really been a good way for the Open Source people to get involved. They
can comment on specs but they’re not involved in the discussions.
That’s something we’re trying to change by opening up the
groups, to make it easier for an Open Source group to contribute on an
ongoing basis if they want to. Right from the beginning part, to the end
where you’re polishing the tiny details in the corner.

I think the story of web fonts shows how an involvement of
the Open Source people could have made a difference.

When web fonts were first designed, essentially you had
Adobe and Apple pushing one way, Bitstream pushing the other way, both
wanting W3C to make their format the one and only official web format,
which is why you ended up with a mechanism to point to fonts without
saying what format was required. And than you had the Netscape 4, which
pointed off to a Bitstream format, and you had IE4 which pointed off to
this Embedded Open Type (EOT) format. If you were a web designer, you had
to have two different tools, one of which only worked on a Mac, and one of
which only worked on PC, and make two different fonts for the same thing.
Basically people wouldn’t bother. As Håkon 9 mentioned the only people who do actually use
that right now really, are countries where the local language is not well
provided for by the Operating Systems. Even now, things like WindowsXP and
MacOSX don’t fully support some of the Indian languages. But they
can get it into web pages by using these embedded fonts. Actually the
other case where it has been used a lot, is SVG, not so much on the
desktop though it does get used there but on mobiles. On the desktop
you’ve typically got 10 or 20 fonts and you got a reasonable
coverage. On a mobile phone, depending on how high or low ended it is, you
might have a single font, and no bold, and it might even
be a pixel-based font. And if you want to start doing text that skews and
swirls, you just can’t do that with a pixel-based font. So you need
to download the font with the content, or even put the font right there in
the content just so that they can see something.

I don’t know how to talk about this, but…
envisioning a standard before having any concrete sense of how it could be
used and how it could change the way people work… means you also
need to imagine how a standard might change, once people start
implementing it?

I wouldn’t say that we have no idea of how it’s
going to work. It’s more a case that there are obvious choices you
can make, and then not so obvious choices. When work is started,
there’s always an idea of how it would fit in with a lot of things
and what it could be used for. It’s more the case that you later
find that there are other things that you didn’t think of that you
can also use it for. Usually it is defined for a particular purpose and
than find that it can also do these other things.

Isn’t it so that sometimes, in that way, something
that is completely marginal, becomes the most important?

It can happen, yes.

For me, SVG is a good example of that. As I understood it,
it was planned to be a format for the web. And as I see it today,
it’s more used on the desktop. I see that on the Linux desktop, for
theming, most internals are using SVG. We are using Inkscape for SVG to
make prints. On the other hand, browsers are really behind.

Browsers are getting there. Safari has got reasonably good
support. Opera has got very good support. It really has increased a lot in
the last couple of years. Mozilla Firefox less so. It’s getting
there. They’ve been at it for longer, but it also seems to be going
slower. The browsers are getting there. The implementations which I showed
a couple of days ago, those were mobile implementations. I was showing
them on a PC, but they were specially built demos. Because they’re
mobile, it tends to move faster.

But you still have this problem that Internet Explorer is a
slow adopter.

Yes, Internet Explorer has not adopted a lot of things.
It’s been very slow to do CSS. It hasn’t yet done XHTML,
although it has shipped with an XML parser since IE4. It hasn’t done
SVG. Now they’ve got their own thing… Silverlight. It has been
very hard to get Microsoft on board and getting them doing things.
Microsoft were involved in the early part of SVG but getting things into
IE has always been difficult. What amazes me to some extent, is the fact
that it’s still used by about 60-70% of people. You look at what IE
can do, and you look at what all the other browsers can do, and you wonder
why. The thing is… it is still a break and some technologies
don’t get used because people want to make sure that everyone can
see them. So they go down to the lowest common denominator. Or they
double-implement. Implement something for all the other browsers, and
implement something separate for IE, and than have to maintain two
different things in parallel, and tracking revisions and whatever.
It’s a nightmare. It’s a huge economic cost because one
browser doesn’t implement the right web stuff. (laughing,
sighing)

My question would be: what could you give us as a kind of
advice? How could we push this adoption where we are working? Even if it
only is the people of Firefox to adopt SVG?

Bear in mind that Firefox has this thing of Trunk builds and
Branch builds and so on. For example when Firefox 3 came out, well the
Beta is there. Suddenly there’s a big jump in the SVG stuff because
all the Firefox 2 was on the same branch as 1.5, and the SVG was basically
frozen at that point. The development was ongoing but you only saw it when
3 came out. There were a bunch of improvements there. The main missing
features are the animation and the web fonts and both of those are being
worked on. It’s interesting because both of those were on Acid 3.
Often I see an acceleration of interest in getting something done because
there’s a good test. The Acid Test 10 is interesting because it’s a single
test for a huge slew of things all at once. One person can look at it, and
it’s either right or it’s wrong, whereas the tests that W3C
normally produces are very much like unit tests. You test one thing and
there’s like five hundred of them. And you have to go through, one
after another. There’s a certain type of person who can sit through
five hundred test on four browsers without getting bored but most people
don’t. There’s a need for this sort of aggregative test. The
whole thing is all one. If anything is wrong, it breaks. That’s what
Acid is designed to do. If you get one thing wrong, everything is all over
the place. Acid 3 was a submission-based process and like a competition,
the SVG working group was there, and put in several proposals for what
should be in Acid 3, many of which were actually adopted. So there’s
SVG stuff in Acid 3.

So… who started the Acid Test?

Todd Fahrner designed the original Acid 1 test, which was
meant to exercise the tricky bits of the box-model in CSS. It ended like a
sort Mondrian diagram, 11 red squares,
and blue lines and stuff. But there was a big scope for the whole thing to
fall apart into a train wreck if you got anything wrong. The thing is, a
lot of web documents are pretty simple. They got paragraphs, and headings
and stuff. They weren’t exercising very much the model. Once you got
tables in there, they were doing it a little bit more. But it was really
when you had stuff floated to one side, and things going around or
whatever, and that had something floated as well. It was in that sort of
case where it was all breaking, where people wouldn’t get
interoperability.

No, it didn’t come from W3C. The same for Acid 2,
Håkon Wium Lie was involved in that one. He didn’t blow his own
trumpet this morning, but he was very much involved there. Acid 3 was Ian
Hickson, who put that together. It’s a bit different because a lot
of it is DOM scripting stuff. It does something, and then it inquires in
the DOM to see if it has been done correctly, and it puts that value back
as a visual representation so you can see. It’s all very good
because apparently it motivates the implementors to do something.
It’s also marketable. You can have a blog posting saying we do 80%
of Acid Test. The public can understand that. The people who are
interested can go Oh, that’s good.

It becomes a mark of quality.

That’s why the idea of the Acid Test is a nice breed
between the spec and the designer. When I was seeing the test this
morning, I was thinking that it could be a really interesting work to do,
not to really implement it but to think about with the students. How would
you conceive a visual test? I think that this could be a really nice
workshop to do in a university or in a design academy…

It’s the kind of reverse-reverse engineering of a
standard which could help you understand it on different levels. You have
to imagine how wild you can go with something. I talk about standards, and
read them - not before going to bed - because I think that it’s
interesting to see that while they’re quite pragmatic in how
they’re put together, but they have an effect on the practice of,
for example, designers. Something that I have been following with interest
is the concept of separating form and content has become extremely
influential in design, especially in web design. Trained as a pre-web
designer, I’m sometimes a bit shocked by the ease with which this
separation is made.

That’s interesting. Usually people say that it’s
hard or impossible, that you can’t ever do it. The fact that
you’re saying that it’s easy or that it comes naturally is
interesting to me.

It has been appropriated by designers as something they
want. That’s why it’s interesting to look at the Web Standards
Project where designers really fight for a separation of content and form.
I think that this is somehow making the work of designers quite…
boring. Could you talk a bit about how this is done?

It’s a continuum. You can’t say that something
is exactly form or exactly presentation because there are gradations. If
you take a table, you’ve already decided that you want to display
the material in a tabular way. If it’s a real table, you should be
able to transpose it. If you take the rows and columns, and the numbers in
the middle then it should still work. If you’ve got
‘sales’ here and if you’ve got ‘regions’
there, then you should still be able to transpose that table. If
you’re just flipping it 90 degrees then you are using it as a layout
grid, and not as a table. That’s one obvious thing. Even then,
deciding to display it as a tabular thing means that it probably came from
a much bigger dataset, and you’ve just chosen to sum all of the
sales data over one year. Another one: you have again the sales data, you
could have it as pie chart, but you could also have it as a bar chart, you
could have it in various other ways. You can imagine that what you would
do is ship some XML that has that data, and then you would have a script
or something which would turn it into an SVG pie chart. And you could have
a bar chart, or you could also say show me only February. That interaction
is one of the things that one can do, and arguably you’re giving it
a different presentational form. It’s still very much a gradation.
It’s how much re-styleability remains. You can’t ever have
complete separation. If I’m describing a company, and
[1] I want to do a marketing brochure, and
[2] I want to do an annual report for the shareholders,
and [3] I want to do an internal document for the
engineering team. I can’t have the same content all over those three
and just put styling on it. The type of thing I’m doing is going to
vary for those audiences, as will the presentation. There’s a limit.
You can’t say: here’s the überdocument, and it can be
styled to be anything. It can’t be. The trick is to not mingle the
style of the presentation when you don’t need to. When you do need
to, you’re already halfway down the gradient. Keep them as far apart
as you can, delay it as late as possible. At some point they have to be
combined. A design will have to go into the crafting of the wording, how
much wording, what voice is used, how it’s going to fit with the
graphics and so on. You can’t just slap random things together and
call it design, it looks like a train wreck. It’s a case of
deferment. It’s not ever a case of complete separation. It’s a
case of deferring it and not tripping yourself up. Just simple things like
bolds and italics and whatever. Putting those in
as emphasis and whatever because you might choose to have your emphasized
words done differently. You might have a different font, you might have a
different way of doing it, you might use letter-spacing, etc. Whereas if
you tag that in as italics then you’ve only got
italics, right? It’s a simple example but at the end of the
day you’re going to have to decide how that is displayed. You
mentioned print. In print no one sees the intermediate result. You see ink
on paper. If I have some Greek in there and if I’ve done that by
actually typing in Latin letters on the keyboard and putting a Greek font
on it and out comes Greek, nobody knows. If it’s a book that’s
being translated, there might be some problems. The more you’re
shipping the electronic version around, the more it actually matters that
you put in the Greek letters as Greek because you will want to revise it.
It matters that you have flowing text rather than text that has been
hand-ragged because when you put in the revisions you’re going to
have to re-rag the entire thing or you can just say re-flow and fix it up
later. Things like that.

The idea of time, and the question of delay is interesting.
Not how, but when you enter to fine-tune things manually. As a designer of
books, you’re always facing the question: when to edit, what, and on
what level. For example, we saw this morning 13 that the idea of having multiple skins is
really entering the publishing business, as an idea of creativity. But
that’s not the point, or not the complete point. When is it possible
to enter the process? That’s something that I think we have to
develop, to think about.

Designers as lawyers!

Yes… and the programmer would say: OK, we respect
the spec, but then we don’t expect anything else from us. This
kind of behaviour in the end, blocks a lot of exchange, instead of making
a more creative approach possible.

I read about (and this is before skinning became more
common) designers doing some multimedia things at Microsoft. You had
designers and then there were coders. Each of them hated the other ones.
The coders thought the designers were idiots who lived in lofts and had
found objects in their ears. The designers thought that the programmers
were a bunch of socially inept nerds who had no clue and never got out in
sunlight and slept in their offices. And since they had that dynamic, they
would never explain to each other (…)

(policeman arrives)

POLICEMAN:Do you speak English?

Yes.

POLICEMAN:You must go from this place because there’s a conference

Yes, we know. We are part of this conference (shows LGM
badge).

POLICEMAN:We had a phone call that here’s a picnic. I don’t really see a picnic

We’re doing an interview.

POLICEMAN:
It looks like a picnic, and professors are getting nervous.
You must go sit somewhere else. Sorry, it is the rules.

Have a nice day!

_Laws are like sausages. It’s better not to see
them being made._ Otto von Bismarck, 1815–1898

Consensus is a core value of W3C. To promote consensus,
the W3C process requires Chairs to ensure that groups consider all
legitimate views and objections, and endeavor to resolve them, whether
these views and objections are expressed by the active participants of the
group or by others (e.g., another W3C group, a group in another
organization, or the general public).

_International Standards for Business, Government and
Society_ International Organization for Standardization (ISO),
http://www.iso.org

_The purpose of the X Consortium was to foster the
development, evolution, and maintenance of the X Window System, a
comprehensive set of vendor-neutral, system-architecture neutral,
network-transparent windowing and user interface standards._
http://www.x.org/wiki/XConsortium

The Acid 3 test: http://acid3.acidtests.org is
comprehensive in comparison to more detailed, but fragmented SVG tests:
http://www.w3.org/Graphics/SVG/WG/wiki/Test_Suite_Overview#W3C_Scalable_Vec
tor_Graphics_.28SVG.29_Test_Suite_Overview