Inside the CSS WG: Daniel Glazman, co-chair

Step with me behind the curtain into the W3C CSS Working Group. Historically filled with challenges, the group has grown into one of the most productive, powerhouse working groups in the W3C’s history. What happened to bring about this change? To provide insight, and encourage web folks to participate more in Working Groups in general, let’s turn up the house lights on some very diverse people: CSS WG individuals, who will over this series reveal their independent, as well as global, vision for CSS, and for the web.

In this first interview, I visit with the group’s co-chair, Daniel Glazman, who claims he “sometimes feels like a dinosaur in the world of web standards, having survived to nearly 14 years of active delirium in the World Wide Web Consortium including participation in HTML4, CSS2 and CSS3". He runs his own software company, Disruptive Innovations, and builds the standards-oriented, Gecko-based WYSIWYG editor, BlueGriffon.

MH: When you first became co-chair of the CSS-WG, CSS 2.1 was still unfinished, yet CSS3 implementations were taking off beyond the specs. How were you able to restore some direction at such a difficult time?
DG: It wasn't that difficult, you know. The members of the CSS WG are all here to make CSS progress. Granted, they're here to make it progress for their own competitive advantage, but still, they are (very) smart people of (very) good will. My co-chair Peter Linss and I had really little to do to make the Working Group focus on the essential, and the essential was at that time "Release CSS 2.1 as a REC". So we assigned priorities, often eliminated non-critical discussions from our meetings and conference calls, played a bit the conductor for the CSS orchestra and that's all. That's all because it was enough.

MH: How do you feel modularisation has influenced the advancement of CSS?
DG: It influenced it in two different ways:

• On the good side: CSS 1 was 15 pages long, CSS2 was 200 pages long, and CSS3 is even much larger than that. Keeping one single spec was clearly not an option because different sections of CSS3 evolve at different speeds. It helped making things evolve better and faster, and it helped getting advocates/editors for the different modules.
• On the bad side: not everyone is interested in all modules and a side-effect of modularisation is specialisation. To be totally fair, it's also a side-effect of complexity and some of our modules, Text for instance, reach very complex issues related to writing scripts, typographic common practices and complexity is almost unavoidable.

MH: As a leader, what are your top three challenges in managing a growing, productive and bright group of people to some kind of consensus?
DG: I'm not a "leader". I am chairing and that's entirely different. The CSS WG (hear its Members) decide the direction by consensus itself. The main thing is, as always, to make sure the main thing remains the main thing.

To achieve that, a chair's role is to do anything needed to avoid noise, internal conflicts and external attacks. That's sometimes tricky and even the Working Group members don't know everything that happened behind the curtains during the last four years. To summarise that into, not three as you requested, but four things, I could say: understand users, focus, implement, deliver.

MH: What is your greatest fear for the CSS-WG?
DG: An evolution towards the working habits of the WHAT-WG. In its rather short existence, the WHAT-WG led to a major and almost unprecedented clash with IETF, getting rid of the HTML version that I think is a totally crazy decision the whole industry (and I don't mean browser vendors but users here) will pay expensively in the future, attempts to make their model percolate in all web standards, and finally a spec that is, well, not a spec since it never stabilises. Maybe HTML became an example of Heisenberg's principle: it changes when you look at it?

This is only my personal opinion here but I think this would be the last thing to do for CSS.

MH: What is your greatest fear for the W3C?
DG: It has always been the same: lack of pragmatism and counter-productive political correctness.

MH: Daniel, you are also an implementor, developing software using open web technologies. Tell us a bit about your work implementing features into the tools you build.
DG: My tool is a cross-platform, open source, WYSIWYG editor for all flavours of HTML. It has a full GUI for CSS 2 and 3, including 3D transforms, transitions and timing functions. It handles SVG and MathML too. Its core CSS parser and serialiser, JSCSSP, is the result of years of thoughts even if it didn't take that long to implement, fortunately.

It helps me a lot when detecting bugs, inconsistencies and interpretation issues in CSS specs. Sometimes, things that look almost perfect in the spec are just not implementable in a nice and understandable GUI. As an editor vendor, I always keep in mind our users are browser users but also web authors. This last category deserves good authoring tools with friendly GUIs. But if our technical spec choices don't let editor vendors like me find any friendly GUI, then we might have a problem.

MH: Developers have had to create polyfills and mixins and non-standard techniques to solve real problems. Some suggest this is all the fault of holding off variables in CSS. What do you think about this?
DG: I have always wanted Variables, I even co-authored a proposal about it with Dave Hyatt from Apple. Variables are absolutely needed for corporate users who don't want to repeat a given colour, a given size or a given URL all over their corporate web. They want a corporate stylesheets and authors using the variables defined there and only there so if a variable changes, the whole corporate web gets the change instantly.

Mixins, variables and other exotic species – I don't really care myself about the precise technical solution, I care about the features. CSS was originally designed thinking almost only of browsers and "notepadability". Granted, CSS is "notepadable"; but it's not easily manageable in industrial critical environments. The language misses a few things to make users' lives easier and I want these things to emerge in CSS.

MH: Any additional thoughts?
DG: In the early days of the web, CSS had competitors. It's now the undisputed style language of the web. I understand some authors can be frustrated when they see the one feature they requested years ago is still not here. But you have to understand this is an absolutely core technology of the web standardised by only 20 people and there aren't many more available because standardisation is a complex, a very complex (and sometimes ungrateful), task.

What we have on our radar is enough to give us years of work, and even if that's not always understood, making sure the box model works in vertical Asian languages is as important – if not much more important – than having Variables in CSS. As I said in answer to your first question, that's only a question of priorities.

We'll eventually do everything, no worries. But standardisation and implementation do take time. That's a constant of our industry.