Slashdot Mirror

Michael J. Ross writes "For Web developers who appreciate the value of separating Web content from its presentation, Cascading Style Sheets (CSS) has proved a godsend, because it allows all of the styling of a Web site to be organized in CSS files separate from the site's semantic content, in HTML files (possibly dynamically generated). Yet to make this styling power possible, CSS must incorporate a long list of syntax elements, including hundreds of selectors, properties, and values. Thus it can be quite handy for the developer to have on hand a concise summary of CSS, such as the CSS Pocket Reference, authored by Eric A. Meyer." Read on for the rest of Michael's review. CSS Pocket Reference, 3rd Edition author Eric A. Meyer pages 168 publisher O'Reilly Media rating 8/10 reviewer Michael J. Ross ISBN 0596515057 summary A concise reference book for CSS. The book was published by O'Reilly Media on 5 October 2007, under the ISBNs 0596515057 and 978-0596515058. CSS itself has evolved along with other Web technologies, and this book is now in its third edition, having been updated to reflect the ongoing changes in CSS; the book now covers CSS2 and CSS2.1. On the book's Web page, O'Reilly offers an online table of contents, as well as ways for the visitor to view and submit errata (none as of this writing) and reviews for the book. Unlike most technical publishers, O'Reilly now makes available previews of their books' contents, in the form of a table of contents with links to the first few paragraphs of each section, including tables and illustrations.

Despite the growth in the number of elements in CSS, and the attention paid to each one of them by the author of CSS Pocket Reference, the book is still small enough to fit in a pocket, at only 168 pages. The book's material is organized into 18 unnumbered sections, preceded by some notes on the book's typographical conventions, and followed by an essential index. The bulk of the material is found in the Property Reference section. Other sections explain how to add styles to HTML and XHTML pages; CSS rule structure and style precedence, including inheritance and the cascade; element classification and display roles; visual layout; rules on floating and positioning; and table layout. Subsequent sections cover CSS value types and units, and selectors, including some of the newest additions to CSS, such as the adjacent sibling selector and the language attribute selector. Just before getting into the details on properties, Eric Meyer discusses pseudo-classes and pseudo-elements, which have made it possible for Web developers to create rather robust and attractive site navigation using CSS exclusively, without any need to resort to images and JavaScript for rollover effects and other navigation eye candy.

For each element of CSS that is covered in all of the sections mentioned above, the types of information presented to the reader can vary, depending upon the category of element. But they generally include the element's possible values, a default value, what elements it can apply to, whether it is inherited, its computed value, a brief description of the element, at least one example illustrating its usage, what browsers support it, and oftentimes a note on its usage. Consequently, this new edition of the book, like its predecessors, should prove more than adequate for most CSS reference needs.

As with any computer book, there are several ways in which this one could be improved. Any reader using the book to look up a particular element, has two possible ways of doing so: They could first consult the index, and, assuming the element is listed there, go straight to the page indicated. But most readers, knowing that the elements in each section are listed alphabetically, will probably open up the book near the front or the back, and begin flipping backward or forward, respectively, hoping to spot the element of interest as quickly as possible, given its alphabetical ordering. That individual will likely immediately spot an obvious problem with the book: The pages have no running titles (the words that indicate the first element discussed on that page, and typically listed at the very top of each page). Inclusion of such running titles in the next edition of the book, would make it much faster to use.

Another valuable addition would be some sort of table listing all of the CSS elements and their level of support within the most commonly used Web browsers and, in the case of Internet Explorer, the most commonly used versions of the browser. Also, on page 48 of the book, at the beginning of the Property Reference section, it has a subhead of "Visual Media," which suggests that there are other subheads within that section, for other media types; but I was unable to find any.

All of these problems concern the publisher's choice of material. My last criticism concerns the layout of that material in the print version of the book. Because this diminutive volume has narrow pages, and they are tightly glued together in the binding, it is imperative that the publisher of such a book provide plenty of white space in the inner margins (those closest to the binding), so the reader does not have to crack open the book too much in order to read the text closest to the binding. Repeatedly opening up the book far enough to read those inmost words, will over time weaken and eventually destroy the binding. In contrast, a small reference book like this has no need for much outer margin. Sadly, O'Reilly got it backwards with this volume, with relatively wide and useless outer margins, and inadequate inner margins.

Aside from the aforementioned flaws — all of which can be remedied in the future — CSS Pocket Reference is a compact and neatly organized gem of a book, packed with information of value to busy Web programmers.

Michael J. Ross is a Web developer, writer, and freelance editor.

You can purchase CSS Pocket Reference, 3rd Edition from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Rudd-O writes "It's official. Ogg technology has been removed from the HTML5 spec, after Ian caved in the face of pressure from Apple and Nokia. Unless massive pressure is exerted on the HTML5 spec editing process, the Web authoring world will continue to endure our modern proprietary Tower of Babel. Note that HTML5 in no way required Ogg (as denoted by the word 'should' instead of 'must' in the earlier draft). Adding this to the fact that there are widely available patent-free implementations of Ogg technology, there is really no excuse for Apple and Nokia to say that they couldn't in good faith implement HTML5 as previously formulated."

a nona maus writes "Several months ago a workgroup of the W3C decided to include Ogg/Theora+Vorbis as the recommended baseline video codec standard for HTML5, against Apple's aggressive protest. Now, Nokia seems to be seeking a reversal of that decision: they have released a position paper calling Ogg 'proprietary' and citing the importance of DRM support. Nokia has historically responded to questions about Ogg on their internet tablets with strange and inconsistent answers, along with hand waving about their legal department. This latest step is enough to really make you wonder what they are really up to."

poet sends us to Computerworld for a story on the intention of the OpenDocument Foundation to drop support for Open Document Format, OASIS and ISO standards not withstanding, in favor of the Compound Documents Format being promoted by the W3C. The foundation's director of business affairs, Sam Hiser, dropped this bomb in a blog posting a couple of weeks ago. Hiser believes CDF has a better shot at compatibility with Microsoft's OOXML, and says that the foundation has been disappointed with the direction of ODF over the last year.

foo fighter writes "The World Wide Web Consortium (W3C) has been slumbering the past several years: HTML was last updated in 1999, XHTML was last updated in 2002, and no one is taking seriously their largely incompatible work on 'next-generation' XHTML or 'modularized' XHTML. Both HTML and XHTML are in sorry need of removing deprecated items while being updated to reflect the current practices of web and browser developers and remaining compatible with legacy Recommendations. The much more open and transparent WHATWG (Web Hypertext Application Technology Working Group), formed in 2004 to address this problem, and has been hard at work on developing a draft spec for HTML5 to update and replace legacy versions of both HTML and XHTML. The quality of this work has reached the point that Apple, Opera, and Mozilla have requested the adoption of HTML5 as the new 'W3C Recommendation' for Web development."

foo fighter writes "The World Wide Web Consortium (W3C) has been slumbering the past several years: HTML was last updated in 1999, XHTML was last updated in 2002, and no one is taking seriously their largely incompatible work on 'next-generation' XHTML or 'modularized' XHTML. Both HTML and XHTML are in sorry need of removing deprecated items while being updated to reflect the current practices of web and browser developers and remaining compatible with legacy Recommendations. The much more open and transparent WHATWG (Web Hypertext Application Technology Working Group), formed in 2004 to address this problem, and has been hard at work on developing a draft spec for HTML5 to update and replace legacy versions of both HTML and XHTML. The quality of this work has reached the point that Apple, Opera, and Mozilla have requested the adoption of HTML5 as the new 'W3C Recommendation' for Web development."

foo fighter writes "The World Wide Web Consortium (W3C) has been slumbering the past several years: HTML was last updated in 1999, XHTML was last updated in 2002, and no one is taking seriously their largely incompatible work on 'next-generation' XHTML or 'modularized' XHTML. Both HTML and XHTML are in sorry need of removing deprecated items while being updated to reflect the current practices of web and browser developers and remaining compatible with legacy Recommendations. The much more open and transparent WHATWG (Web Hypertext Application Technology Working Group), formed in 2004 to address this problem, and has been hard at work on developing a draft spec for HTML5 to update and replace legacy versions of both HTML and XHTML. The quality of this work has reached the point that Apple, Opera, and Mozilla have requested the adoption of HTML5 as the new 'W3C Recommendation' for Web development."

foo fighter writes "The World Wide Web Consortium (W3C) has been slumbering the past several years: HTML was last updated in 1999, XHTML was last updated in 2002, and no one is taking seriously their largely incompatible work on 'next-generation' XHTML or 'modularized' XHTML. Both HTML and XHTML are in sorry need of removing deprecated items while being updated to reflect the current practices of web and browser developers and remaining compatible with legacy Recommendations. The much more open and transparent WHATWG (Web Hypertext Application Technology Working Group), formed in 2004 to address this problem, and has been hard at work on developing a draft spec for HTML5 to update and replace legacy versions of both HTML and XHTML. The quality of this work has reached the point that Apple, Opera, and Mozilla have requested the adoption of HTML5 as the new 'W3C Recommendation' for Web development."

foo fighter writes "The World Wide Web Consortium (W3C) has been slumbering the past several years: HTML was last updated in 1999, XHTML was last updated in 2002, and no one is taking seriously their largely incompatible work on 'next-generation' XHTML or 'modularized' XHTML. Both HTML and XHTML are in sorry need of removing deprecated items while being updated to reflect the current practices of web and browser developers and remaining compatible with legacy Recommendations. The much more open and transparent WHATWG (Web Hypertext Application Technology Working Group), formed in 2004 to address this problem, and has been hard at work on developing a draft spec for HTML5 to update and replace legacy versions of both HTML and XHTML. The quality of this work has reached the point that Apple, Opera, and Mozilla have requested the adoption of HTML5 as the new 'W3C Recommendation' for Web development."

An anonymous reader writes "Cascading Style Sheets celebrate their tenth anniversary this week. The W3C put together the CSS10 site in recognition of this milestone with a Hall of Fame, essays from the past decade, a gallery, and more." I was glad to see the CSS Zen Garden selected for the Hall of Fame, and disappointed (but not surprised) that no browser on my computer correctly renders the Acid2 test.

An anonymous reader writes "Cascading Style Sheets celebrate their tenth anniversary this week. The W3C put together the CSS10 site in recognition of this milestone with a Hall of Fame, essays from the past decade, a gallery, and more." I was glad to see the CSS Zen Garden selected for the Hall of Fame, and disappointed (but not surprised) that no browser on my computer correctly renders the Acid2 test.

GuNgA-DiN writes, "Today marks the 16th anniversary of the World Wide Web. According to the timeline on the W3.org site: 'The first web page [was] http://nxoc01.cern.ch/hypertext/WWW/TheProject.html. Unfortunately CERN no longer supports the historical site. Note from this era too, the least recently modified web page we know of, last changed Tue, 13 Nov 1990 15:17:00 GMT (though the URI changed.)' A lot has happened in 16 years and this little 'baby' has grown into quite the teenager."

GuNgA-DiN writes, "Today marks the 16th anniversary of the World Wide Web. According to the timeline on the W3.org site: 'The first web page [was] http://nxoc01.cern.ch/hypertext/WWW/TheProject.html. Unfortunately CERN no longer supports the historical site. Note from this era too, the least recently modified web page we know of, last changed Tue, 13 Nov 1990 15:17:00 GMT (though the URI changed.)' A lot has happened in 16 years and this little 'baby' has grown into quite the teenager."

prostoalex writes, "HTML tutorials usually mention alt tags for images and noscript tags as something optional that a Web designer should add to a site for the crawlers and users browsing with graphics or JavaScript turned off. However, a recent lawsuit against Target by the National Federation of the Blind accuses the retailer of not complying with the Americans with Disabilities Act. Since Target's online store is unbrowsable with a screen reader, the nation's 200,000 blind people who go online cannot become paying customers, the NFB contends. From the article: 'In denying Target's motion to dismiss the suit two months ago, Judge Marilyn Hall Patel... held that the law's accessibility requirements applied to all services offered by a place of public accommodation. Since Target's physical stores are places of public accommodation, the ruling said, its online store must also be accessible or the company must offer equally effective alternatives.' Does the judge's name ring a bell? Yes, it's the same Marilyn Hall Patel who handled the RIAA's case against Napster in 2001." Web builders and tools may need to start brushing up on the Web Accessibility Initiative.

NotesSensei asks: "Recently I was teasing the teacher who runs the computer club in my sons' primary school: 'You teach the kids only how to use software but not how to make software.' Today I got an email: 'OK, you're in: teach them programming.' Now I wonder what language should I pick? My first lesson will be the board game c-jump, but after that? The contestants are: Kids programming language KPL (ab VB.net derivate; Java using BlueJ; Greenfoot (and the BlueJ); and HTML. Does it sound like I'm on the right track or should I try something completely different? We are looking at primary 3-5 (that's 10-13 in this part of the world). Where can I find inspiration for the curriculum?"

Philipp Lenssen writes "Google today released Accessible Search, a Google Labs product aiming to rank higher pages which are optimized for blind users. Google asks you to adhere to the W3C's Web Content Accessibility Guidelines if you want to make sure your pages are accessible (and thus, rank better on Google Accessible Search). I wrote a small tool to compare results of default and accessible results."

dustin writes "Public outcry against the workings of the World Wide Web Consortium (W3C) is growing. On Sunday, Björn Höhrmann announced his departure in a lengthy critique of problems at the W3C. Web standards champion Zeldman adds his comments as well: 'Beholden to its corporate paymasters who alone can afford membership, the W3C seems increasingly detached from ordinary designers and developers.'"

You submitted questions for Håkon Wium Lie on June 20. Today we have his answers, not only to the (+5 moderated) questions we sent him, but to a bunch of others he thought would also be interesting to answer.

 > Where... by bcat24
 >
 > Do you think the W3C development process is too slow? I know that
 > you guys want everything to be perfect, but it seems to take far
 > longer than necessary. CSS 3 shows promise and I wouldn't want it
 > to die a slow death in standardization.

No, I don't think W3C is too slow. W3C isn't the bottleneck, browsers are. The dominant browser on the web hasn't been updated for years, and it doesn't make sense for specifications to get too far ahead. Rather, the CSS Working Group in W3C has focused on specification maintenance and achieving interoperability between implementations. This work is not so glamorous and some people — even within W3C — would prefer if they concentrate on new specifications. However, I think the focus on interoperability (which has resulted in CSS 2.1) has been crucial to the success of CSS.

CSS3 is a set of specifications that are developed more or less independently of each other. The best way to push a specification forward is to implement it. In the past year, we've seen some encouraging CSS3 implementations come along. For example, Mozilla supports multi-column layouts, Opera supports media queries, Prince supports cross-references and Safari supports borders and backgrounds. A few years from now, I think a select group of CSS3 modules will be interoperably supported in all browsers.

 > Why is CSS such a good idea but a pain to use?
 > by rar
 >
 > CSS is clearly very useful for separating style from content. But
 > apparently people tend to have problems when using it for layouts.
 > Would you say this is because people have not yet understood how to
 > properly do layout in CSS, or is it CSS that is lacking in this
 > area? What can be done to improve the situation? --- Would the web
 > benefit from HTML and CSS being complemented with some kind of
 > "layout language"?

I think layout and style should be tackled by the same language and the two are intertwined. Trying to split the two is like splitting the HTML specification in two, one specification describing inline elements and the other describing block elements. It's not worth the effort.

I think CSS is capable of describing beautiful and scalable layouts. The CSS Zen Garden has been a eye-opening showcase of what is possible today. If MS IE had supported CSS tables, another set of layouts would have been possible. So, there is still lots of potential in the existing CSS specifications which should be the next milestone. Beyond that, the CSS Working Group has started work on a new CSS3 module for advanced layout. Feedback is welcome.

 > CSS Evolution!
 > by eieken
 >
 > Is the wave of webpages designed completely in CSS what you
 > intially intended when you came up with CSS? Do you see that
 > changing? Is that good or bad?

I saw a clear need for a web style sheet language when proposing CSS in 1994. I also wanted CSS to fully describe the presentation of a web pages -- not just add some styling. All in all, I think it has turned out quite well. It has taken longer than I expected, but the scale -- due to the growth of the web -- is more than anyone could imagine.

I used "I" too many times in the previous paragraph. It's important to realize that CSS is a community effort rather that one man's work. Bert Bos joined me early and we worked out the initial designs on a whiteboard during the summer of 1995. The www-style mailing lists and the W3C CSS Working Group have also been crucial in ensuring the success of CSS.

If you're interested in the history of web style sheets, you'll find plenty of material in my PhD thesis on the subject.

 > Two questions (cut to 1.5 by editor Roblimo)
 > by Dolda2000

 > If you were allowed (perhaps by court order, which wouldn't be
 > unthinkable) to force Microsoft to do one (1) change in Internet
 > Explorer, what would that be?

I would force them to support one (1) single web page before shipping IE7, namely Acid2. By using a tiny amount of resources to get Acid2 right, Microsoft can save web designers and users endless amounts of frustration in the future. It would also be an honorable thing to do. This is what Microsoft's W3C representative wrote in 1998:

Microsoft has a deep commitment to working with the W3C on HTML and CSS. We have the first commercial implementation of HTML4, we were the first vendor anywhere to implement even portions of CSS, and we have put a tremendous amount of energy into seeing CSS mature to Level 2. We are still committed to complete implementations of the Recommendations of the W3C in this area (CSS and HTML and the DOM).

May I have one (1) more change? Please? Then I would make IE7 support TrueType downloadable fonts. Microsoft's record in fonts isn't that bad. They made their core fonts available for anyone to use, and IE supports downloadable fonts. Unfortunately, only the proprietary EOT format is supported. A few lines of code would be sufficient to support zipped TrueType fonts as well, and this would unleash a new wave of typography on the web. (To protect yourself, make sure you use a browser where author style sheets can be turned off — Shift-G in Opera). > As a bonus question: What do you think of Slashdot's CSS? ;)

The new design looks great! The style sheets behind the scene are more complex than what the average web page needs. But, we wouldn't expect anything average from Slashdot, would we?

> 6)  Opera
 > by taskforce
 >
 > Opera 9.0 seems to offer a lot of decent additions to Opera's
 > standards pool. How satisfied are you personally with the work the
 > team has done on implementing standards, and is there anything in
 > there you feel is superflous and anything you would have preferred
 > to see which wasn't in there?

I'm very proud of the standards support in Opera 9. Acid2 is an obvious favorite of mine and seeing that smiley face makes me very happy.

Among the more experimental features is support for Audio in HTML5. Web applications can now make sounds in a sensible way! Combined with the canvas element, developers can create Flash-like content without resorting to a proprietary format.

Having support for Bittorrent is also great. From a technical point of view, it makes much sense. Also, it's a political statement of sorts.

During the development of Opera9. Geir Ivarsøy, who founded Opera with Jon von Tetzchner, died after fighting cancer for years. Geir did a spectacular initial CSS implementation in Opera, thus convincing me to join the company. In music, the 9th is legendary. Beethoven, Schubert, Bruckner and Mahler all did 9 symphonies. Opera 9 was Geir's last symphony.

> Included styles, aliases
 > by Spy der Mann
 >
 > I always wanted to have "included" substyles or "aliases" in my
 > CSS definition, to save redundancy.
 >
 > (For includes)
 >
 >     .class1 { color:#ff0000; }
 >     .class2 { background-color:#ffffff; }
 >     .class3 { include:class1,class2;font-weight:bold; }
 >
 > (For aliases)
 >
 >     @alias color1 #ff0000;
 >     @alias color2 #ffffff;
 >     @alias default_image url('/img/image1.jpg');
 >
 >     .class1 { color:color1; }
 >     .class2 { background-image:default_image;background-color:co lor2; }
 >
 > This way we could change colors or images for a whole webpage
 > by editing a reduced number of lines.
 >
 > Had you considered any of these ideas in the past? If so,
 > why were they rejected?

Yes, aliases and constants have been considered. As David Wheeler noted, "Any problem in computer science can be solved with another layer of indirection."

CSS is already an indirection. Instead of putting properties and values directly on elements, it associates properties and values with selectors. What you (and others) are proposing is to add another layer of indirection. By doing so, one could possible write shorter, more manageable style sheets. However, there are also some downsides. It requires a new syntactic construct (@alias) and implementations must be able to remember a list of aliases. What if aliases are defined in one style sheet and referenced in another -- should that work? If so, what if the first style sheet isn't available?

For CSS1, the downsides of aliases were considered more significant than the benefits.

 > Definition of pixel
 > by Sara Chan
 >
 > The word pixel meant "picture element", but CSS redefined it
 >to mean something quite different (a particular subtended angle
 >of view [w3.org]). This causes confusion: CSS pixels are not pixels.
 >(Indeed, I have seen misinformed comments on Slashdot due to
 >that confusion.)
 >
 > My question is this: why call the subtended angle a "pixel", instead of
 >something else (e.g. "subangle")? If CSS wanted to use the subtended
 >angle for something, that is fine, but calling it a pixel seems to follow
 >the approach of Humpty Dumpty "When I use a word, it means just
 >what I choose it to mean".

In most cases, a CSS pixel will be equal to a device pixel. But, as you point out, the definition of a CSS pixel will sometimes be different. For example, on a laser printer, one CSS pixel can be equal to 3x3 device pixels to avoid printing illegibly small text and images. I don't recall anyone ever proposing another name for it. Subangle? Personally, I think most people would prefer the pragmatic "px" to the non-intuitive "sa".

> Vertical CSS Support
 > by infestedsenses
 >
 > As a developer who works with CSS every day, I find one
 > complication that continues to bother me in my daily work.
 > Support for CSS has always been good on the horizontal scope,
 > but vertical positioning has always been quite complicated.
 > Alone the procedure to affix a footer to the bottom of a screen
 > in dependance of the amount of content is unnecessarily difficult,
 > spawning hackish solutions such as "footerStickAlt"
 > [themaninblue.com]. Centering an object in the dead center of a
 > page also requires strange procedures such as this one [wpdfd.com],
 > which still aren't ideal (try making the viewport really small). The old
 > table method provided much easier methods for this. What are your
 > thoughts on this and do you see improvement following in future
 > CSS revisions?

Indeed, the CSS formatting model allows more control horizontally than vertically. This is due to (typically) having a known width, but an unknown height. As such, the height is harder to deal with.

However, CSS2 fixed positioning allows you to place content relative to the viewport (which is CSS-speak for window) instead of the document. For example, by setting position: fixed; bottom: 0 on an element, it will stick to the bottom. This works in Opera, Safari and Mozilla-based browsers. IE6 doesn't support it, however. It remains to be seen if IE7 will support it.

> About Microsoft...
 > by Chabil Ha'
 >
 > With MS's next browser release (IE 7), you mentioned in other
 > interviews that their decision to not supprt CSS2 was more a political
 > decision than a mechanical one. Aside from their obvious desire to
 > dominate the world, what politics do you think are in play that make
 > them not want to conform to the standard, and what do you think would
 > change that landscape so that they would have some initiative to
 > fully support it?

Great question. It's quite clear that Microsoft has the resources and talent to support CSS2 fully in IE and that plenty of people have reminded them why this is important. So, why don't they do it? The fundamental reason, I believe, is that standards don't benefit monopolists. Accepted, well-functioning, standards lower the barrier of entry to a market, and is therefore a threat to a monopolist.

From that perspective, it makes sense to leave CSS2 half-implemented. You can claim support (and many journalists will believe you), and you also ensure that no-one can use the unimplemented (or worse: buggily implemented) features of the standard. The only way to change the equation is to remind Microsoft how embarrassing it is to offer a sub-standard browser. And to use better browsers.

Another reason for not making a IE too good is that it will compete with Windows. A modern browser is an application platform; the combination of HTML, JavaScript, CSS and DOM allows developers to target the web instead of Windows, Linux, or Mac.

> From linvir
 > How long since you last used Linux?

I'm using it right now. Ubuntu on a IBM Thinkpad X41 is the environment I live in. Ubuntu rocks -- especially with Opera on top! (And Emacs right underneath.)

 > From Rob T Firefly (844560)
 > Why the curly brackets?

The initial CSS proposal didn't use them, instead relying on newlines to separate statements. TimBL didn't really like that and I therefore borrowed the curly braces from the C programming language. The syntax for comments came along as well. I think it works quite well.

 > why not XML?
 > by slashdot.org
 > Simple question (hopefully simple answer ;-)): why
 > did you not use XML?

The simple answer is that the development of CSS preceded XML by a year or so. However, if XML had been available, would we have used it? Probably not. And I suspect Brendan Eich of JavaScript fame would answer the same way on behalf of his language.

XML is a great syntax for structured data, but not suitable for all languages. Still, I think the SGML-based syntax for the FOSI style sheet language.

 > Padding
 > by Anonymous Coward

 > Why was the decision made to make padding apply outside
 > of the width of a 'box', rather than inside, which would seem
 > to make more sense?

It makes sense in some situations, but not in others. For example, when a child element is set to width: 100%, I don't think it should cover the padding of its parent. The box-sizing property in CSS3 addresses this issue. Ideally, the issue should have been addressed earlier, though.

> by nuzak

 > why not float:

 > DSSSL had this sort of thing solved before HTML even existed,
 > let alone CSS. But scheme is too scary and icky, and the W3C
 > believes in a principle of least power, so CSS has to be fully declarative,
 > static, and crippled until patched later.

You're wrong about DSSSL -- it didn't support floating text (as in having text wrap around images) at all. And the DSSSL specification only became publically available around 1996, years after HTML.

> by MagicM

 > How frustrating is it to write a specification knowing
 > that you're at the browser vendors' mercy?

That's part of the game. I don't think any specification has a birthright to be fully supported by all browsers. There should be healthy competition between different specifications. I believe simple, author-friendly specifications will prevail in this environment.

Microformats are another way of developing new formats. Instead of having to convince browser vendors to support your favorite specification, microformats add semantics to HTML through the CLASS attribute. And style it with CSS.

> New standards
 > by iamsure
 >
 > In your work at Opera, you have clearly paved a path that includes
 > going beyond the W3C standards. Whether it is WhatWG
 > implementations, or new functionality specific to Opera (2dgame),
 > you are pushing into new territory. Can you explain why W3C isn't
 > sufficient, and why efforts at Opera to expand beyond the standards
 > differ from Microsoft's embrace/extend model?

It's a fair question. The WhatWG was set up when it seemed as if W3C didn't care much about browsers anymore. That has definitely changed and work items from WhatWG are now channeled into W3C (e.g., XMLHttpRequest).

At Opera, we sometimes include experimental features before they have been standardized. When this happens they are labeled as such, but we still try to document them. For example, we support some Opera-only CSS properties for XML. If these features gain traction, we are happy to work with other organizations to standardize them. If they don't become popular, the features will most likely disappear.

 > Beyond HTML
 > by pr1000

 > How far can CSS be taken beyond the web page--that is,
 > have generalized or non-web specific features for such things
 > as page formatting or type setting? Do you plan/wish/hope to
 > take it farther than it currently is?

Yes, I think it's possible to take CSS further in several directions. I'm eager to see CSS being used in paper-based publishing and I joined the board of YesLogic — which makes the Prince XML to PDF converter — to make sure they added my favorite features. Bert and I used Prince to generate PDF from HTML and CSS sources for the third edition of our book. W3C just published a new Working Draft which describes features for printing, e.g., footnotes, cross-references, and even generated indexes.

For mobile units, I think Media Queries will be important. For example, they can express that large images should not be sent to mobile devices.

Another great opportunity for CSS is Web Applications. Just like documents, applications need to be styled and CSS is an intrinsic component of AJAX. The "AJAX" name sounds great, but allow me to propose a few alternate spellings that I find more accurate:

• AJACX: Asynchronous JavaScript, CSS and XMLHttpRequest
• ADJACS: Asynchronous DOM, JavaScript and CSS
• ADHJACS: Asynchronous DOM, HTML, JavaScript and CSS
• AJAHCS: Asynchronous JavaScript, HTML and CSS
• AJACS: Asynchronous JavaScript, HTML and CSS

Opera, Mozilla and Safari developers are collaborating in the WHAT WG and in W3C to make sure we have interoperable specifications for AJAX. I mean, ADHJACS.

 > by crush

 > Is the difficulty of producing a layout that consists of
 > three or more columns of equal height justification for
 > adding some new feature to the specification to make this easier?

I don't think so. CSS2 defines a table layout that can be used for this purpose. The problem is, and I'm repeating myself here, that the dominant browser doesn't support it. Adding yet more features to the specification wouldn't help.

 > How come, we um, lie?

Right. My name is, um, a bit troublesome to pronounce in English. But I'm a nice person who generally tells the truth. I often tell non-Norwegians that my first name is pronounced "howcome". That's close, but not quite. It does make for a great email address like howcome@opera.com, though.

So I may be a Lie, but I'm just a little white one :-)

You submitted questions for Håkon Wium Lie on June 20. Today we have his answers, not only to the (+5 moderated) questions we sent him, but to a bunch of others he thought would also be interesting to answer.

 > Where... by bcat24
 >
 > Do you think the W3C development process is too slow? I know that
 > you guys want everything to be perfect, but it seems to take far
 > longer than necessary. CSS 3 shows promise and I wouldn't want it
 > to die a slow death in standardization.

No, I don't think W3C is too slow. W3C isn't the bottleneck, browsers are. The dominant browser on the web hasn't been updated for years, and it doesn't make sense for specifications to get too far ahead. Rather, the CSS Working Group in W3C has focused on specification maintenance and achieving interoperability between implementations. This work is not so glamorous and some people — even within W3C — would prefer if they concentrate on new specifications. However, I think the focus on interoperability (which has resulted in CSS 2.1) has been crucial to the success of CSS.

CSS3 is a set of specifications that are developed more or less independently of each other. The best way to push a specification forward is to implement it. In the past year, we've seen some encouraging CSS3 implementations come along. For example, Mozilla supports multi-column layouts, Opera supports media queries, Prince supports cross-references and Safari supports borders and backgrounds. A few years from now, I think a select group of CSS3 modules will be interoperably supported in all browsers.

 > Why is CSS such a good idea but a pain to use?
 > by rar
 >
 > CSS is clearly very useful for separating style from content. But
 > apparently people tend to have problems when using it for layouts.
 > Would you say this is because people have not yet understood how to
 > properly do layout in CSS, or is it CSS that is lacking in this
 > area? What can be done to improve the situation? --- Would the web
 > benefit from HTML and CSS being complemented with some kind of
 > "layout language"?

I think layout and style should be tackled by the same language and the two are intertwined. Trying to split the two is like splitting the HTML specification in two, one specification describing inline elements and the other describing block elements. It's not worth the effort.

I think CSS is capable of describing beautiful and scalable layouts. The CSS Zen Garden has been a eye-opening showcase of what is possible today. If MS IE had supported CSS tables, another set of layouts would have been possible. So, there is still lots of potential in the existing CSS specifications which should be the next milestone. Beyond that, the CSS Working Group has started work on a new CSS3 module for advanced layout. Feedback is welcome.

 > CSS Evolution!
 > by eieken
 >
 > Is the wave of webpages designed completely in CSS what you
 > intially intended when you came up with CSS? Do you see that
 > changing? Is that good or bad?

I saw a clear need for a web style sheet language when proposing CSS in 1994. I also wanted CSS to fully describe the presentation of a web pages -- not just add some styling. All in all, I think it has turned out quite well. It has taken longer than I expected, but the scale -- due to the growth of the web -- is more than anyone could imagine.

I used "I" too many times in the previous paragraph. It's important to realize that CSS is a community effort rather that one man's work. Bert Bos joined me early and we worked out the initial designs on a whiteboard during the summer of 1995. The www-style mailing lists and the W3C CSS Working Group have also been crucial in ensuring the success of CSS.

If you're interested in the history of web style sheets, you'll find plenty of material in my PhD thesis on the subject.

 > Two questions (cut to 1.5 by editor Roblimo)
 > by Dolda2000

 > If you were allowed (perhaps by court order, which wouldn't be
 > unthinkable) to force Microsoft to do one (1) change in Internet
 > Explorer, what would that be?

I would force them to support one (1) single web page before shipping IE7, namely Acid2. By using a tiny amount of resources to get Acid2 right, Microsoft can save web designers and users endless amounts of frustration in the future. It would also be an honorable thing to do. This is what Microsoft's W3C representative wrote in 1998:

Microsoft has a deep commitment to working with the W3C on HTML and CSS. We have the first commercial implementation of HTML4, we were the first vendor anywhere to implement even portions of CSS, and we have put a tremendous amount of energy into seeing CSS mature to Level 2. We are still committed to complete implementations of the Recommendations of the W3C in this area (CSS and HTML and the DOM).

May I have one (1) more change? Please? Then I would make IE7 support TrueType downloadable fonts. Microsoft's record in fonts isn't that bad. They made their core fonts available for anyone to use, and IE supports downloadable fonts. Unfortunately, only the proprietary EOT format is supported. A few lines of code would be sufficient to support zipped TrueType fonts as well, and this would unleash a new wave of typography on the web. (To protect yourself, make sure you use a browser where author style sheets can be turned off — Shift-G in Opera). > As a bonus question: What do you think of Slashdot's CSS? ;)

The new design looks great! The style sheets behind the scene are more complex than what the average web page needs. But, we wouldn't expect anything average from Slashdot, would we?

> 6)  Opera
 > by taskforce
 >
 > Opera 9.0 seems to offer a lot of decent additions to Opera's
 > standards pool. How satisfied are you personally with the work the
 > team has done on implementing standards, and is there anything in
 > there you feel is superflous and anything you would have preferred
 > to see which wasn't in there?

I'm very proud of the standards support in Opera 9. Acid2 is an obvious favorite of mine and seeing that smiley face makes me very happy.

Among the more experimental features is support for Audio in HTML5. Web applications can now make sounds in a sensible way! Combined with the canvas element, developers can create Flash-like content without resorting to a proprietary format.

Having support for Bittorrent is also great. From a technical point of view, it makes much sense. Also, it's a political statement of sorts.

During the development of Opera9. Geir Ivarsøy, who founded Opera with Jon von Tetzchner, died after fighting cancer for years. Geir did a spectacular initial CSS implementation in Opera, thus convincing me to join the company. In music, the 9th is legendary. Beethoven, Schubert, Bruckner and Mahler all did 9 symphonies. Opera 9 was Geir's last symphony.

> Included styles, aliases
 > by Spy der Mann
 >
 > I always wanted to have "included" substyles or "aliases" in my
 > CSS definition, to save redundancy.
 >
 > (For includes)
 >
 >     .class1 { color:#ff0000; }
 >     .class2 { background-color:#ffffff; }
 >     .class3 { include:class1,class2;font-weight:bold; }
 >
 > (For aliases)
 >
 >     @alias color1 #ff0000;
 >     @alias color2 #ffffff;
 >     @alias default_image url('/img/image1.jpg');
 >
 >     .class1 { color:color1; }
 >     .class2 { background-image:default_image;background-color:co lor2; }
 >
 > This way we could change colors or images for a whole webpage
 > by editing a reduced number of lines.
 >
 > Had you considered any of these ideas in the past? If so,
 > why were they rejected?

Yes, aliases and constants have been considered. As David Wheeler noted, "Any problem in computer science can be solved with another layer of indirection."

CSS is already an indirection. Instead of putting properties and values directly on elements, it associates properties and values with selectors. What you (and others) are proposing is to add another layer of indirection. By doing so, one could possible write shorter, more manageable style sheets. However, there are also some downsides. It requires a new syntactic construct (@alias) and implementations must be able to remember a list of aliases. What if aliases are defined in one style sheet and referenced in another -- should that work? If so, what if the first style sheet isn't available?

For CSS1, the downsides of aliases were considered more significant than the benefits.

 > Definition of pixel
 > by Sara Chan
 >
 > The word pixel meant "picture element", but CSS redefined it
 >to mean something quite different (a particular subtended angle
 >of view [w3.org]). This causes confusion: CSS pixels are not pixels.
 >(Indeed, I have seen misinformed comments on Slashdot due to
 >that confusion.)
 >
 > My question is this: why call the subtended angle a "pixel", instead of
 >something else (e.g. "subangle")? If CSS wanted to use the subtended
 >angle for something, that is fine, but calling it a pixel seems to follow
 >the approach of Humpty Dumpty "When I use a word, it means just
 >what I choose it to mean".

In most cases, a CSS pixel will be equal to a device pixel. But, as you point out, the definition of a CSS pixel will sometimes be different. For example, on a laser printer, one CSS pixel can be equal to 3x3 device pixels to avoid printing illegibly small text and images. I don't recall anyone ever proposing another name for it. Subangle? Personally, I think most people would prefer the pragmatic "px" to the non-intuitive "sa".

> Vertical CSS Support
 > by infestedsenses
 >
 > As a developer who works with CSS every day, I find one
 > complication that continues to bother me in my daily work.
 > Support for CSS has always been good on the horizontal scope,
 > but vertical positioning has always been quite complicated.
 > Alone the procedure to affix a footer to the bottom of a screen
 > in dependance of the amount of content is unnecessarily difficult,
 > spawning hackish solutions such as "footerStickAlt"
 > [themaninblue.com]. Centering an object in the dead center of a
 > page also requires strange procedures such as this one [wpdfd.com],
 > which still aren't ideal (try making the viewport really small). The old
 > table method provided much easier methods for this. What are your
 > thoughts on this and do you see improvement following in future
 > CSS revisions?

Indeed, the CSS formatting model allows more control horizontally than vertically. This is due to (typically) having a known width, but an unknown height. As such, the height is harder to deal with.

However, CSS2 fixed positioning allows you to place content relative to the viewport (which is CSS-speak for window) instead of the document. For example, by setting position: fixed; bottom: 0 on an element, it will stick to the bottom. This works in Opera, Safari and Mozilla-based browsers. IE6 doesn't support it, however. It remains to be seen if IE7 will support it.

> About Microsoft...
 > by Chabil Ha'
 >
 > With MS's next browser release (IE 7), you mentioned in other
 > interviews that their decision to not supprt CSS2 was more a political
 > decision than a mechanical one. Aside from their obvious desire to
 > dominate the world, what politics do you think are in play that make
 > them not want to conform to the standard, and what do you think would
 > change that landscape so that they would have some initiative to
 > fully support it?

Great question. It's quite clear that Microsoft has the resources and talent to support CSS2 fully in IE and that plenty of people have reminded them why this is important. So, why don't they do it? The fundamental reason, I believe, is that standards don't benefit monopolists. Accepted, well-functioning, standards lower the barrier of entry to a market, and is therefore a threat to a monopolist.

From that perspective, it makes sense to leave CSS2 half-implemented. You can claim support (and many journalists will believe you), and you also ensure that no-one can use the unimplemented (or worse: buggily implemented) features of the standard. The only way to change the equation is to remind Microsoft how embarrassing it is to offer a sub-standard browser. And to use better browsers.

Another reason for not making a IE too good is that it will compete with Windows. A modern browser is an application platform; the combination of HTML, JavaScript, CSS and DOM allows developers to target the web instead of Windows, Linux, or Mac.

> From linvir
 > How long since you last used Linux?

I'm using it right now. Ubuntu on a IBM Thinkpad X41 is the environment I live in. Ubuntu rocks -- especially with Opera on top! (And Emacs right underneath.)

 > From Rob T Firefly (844560)
 > Why the curly brackets?

The initial CSS proposal didn't use them, instead relying on newlines to separate statements. TimBL didn't really like that and I therefore borrowed the curly braces from the C programming language. The syntax for comments came along as well. I think it works quite well.

 > why not XML?
 > by slashdot.org
 > Simple question (hopefully simple answer ;-)): why
 > did you not use XML?

The simple answer is that the development of CSS preceded XML by a year or so. However, if XML had been available, would we have used it? Probably not. And I suspect Brendan Eich of JavaScript fame would answer the same way on behalf of his language.

XML is a great syntax for structured data, but not suitable for all languages. Still, I think the SGML-based syntax for the FOSI style sheet language.

 > Padding
 > by Anonymous Coward

 > Why was the decision made to make padding apply outside
 > of the width of a 'box', rather than inside, which would seem
 > to make more sense?

It makes sense in some situations, but not in others. For example, when a child element is set to width: 100%, I don't think it should cover the padding of its parent. The box-sizing property in CSS3 addresses this issue. Ideally, the issue should have been addressed earlier, though.

> by nuzak

 > why not float:

 > DSSSL had this sort of thing solved before HTML even existed,
 > let alone CSS. But scheme is too scary and icky, and the W3C
 > believes in a principle of least power, so CSS has to be fully declarative,
 > static, and crippled until patched later.

You're wrong about DSSSL -- it didn't support floating text (as in having text wrap around images) at all. And the DSSSL specification only became publically available around 1996, years after HTML.

> by MagicM

 > How frustrating is it to write a specification knowing
 > that you're at the browser vendors' mercy?

That's part of the game. I don't think any specification has a birthright to be fully supported by all browsers. There should be healthy competition between different specifications. I believe simple, author-friendly specifications will prevail in this environment.

Microformats are another way of developing new formats. Instead of having to convince browser vendors to support your favorite specification, microformats add semantics to HTML through the CLASS attribute. And style it with CSS.

> New standards
 > by iamsure
 >
 > In your work at Opera, you have clearly paved a path that includes
 > going beyond the W3C standards. Whether it is WhatWG
 > implementations, or new functionality specific to Opera (2dgame),
 > you are pushing into new territory. Can you explain why W3C isn't
 > sufficient, and why efforts at Opera to expand beyond the standards
 > differ from Microsoft's embrace/extend model?

It's a fair question. The WhatWG was set up when it seemed as if W3C didn't care much about browsers anymore. That has definitely changed and work items from WhatWG are now channeled into W3C (e.g., XMLHttpRequest).

At Opera, we sometimes include experimental features before they have been standardized. When this happens they are labeled as such, but we still try to document them. For example, we support some Opera-only CSS properties for XML. If these features gain traction, we are happy to work with other organizations to standardize them. If they don't become popular, the features will most likely disappear.

 > Beyond HTML
 > by pr1000

 > How far can CSS be taken beyond the web page--that is,
 > have generalized or non-web specific features for such things
 > as page formatting or type setting? Do you plan/wish/hope to
 > take it farther than it currently is?

Yes, I think it's possible to take CSS further in several directions. I'm eager to see CSS being used in paper-based publishing and I joined the board of YesLogic — which makes the Prince XML to PDF converter — to make sure they added my favorite features. Bert and I used Prince to generate PDF from HTML and CSS sources for the third edition of our book. W3C just published a new Working Draft which describes features for printing, e.g., footnotes, cross-references, and even generated indexes.

For mobile units, I think Media Queries will be important. For example, they can express that large images should not be sent to mobile devices.

Another great opportunity for CSS is Web Applications. Just like documents, applications need to be styled and CSS is an intrinsic component of AJAX. The "AJAX" name sounds great, but allow me to propose a few alternate spellings that I find more accurate:

• AJACX: Asynchronous JavaScript, CSS and XMLHttpRequest
• ADJACS: Asynchronous DOM, JavaScript and CSS
• ADHJACS: Asynchronous DOM, HTML, JavaScript and CSS
• AJAHCS: Asynchronous JavaScript, HTML and CSS
• AJACS: Asynchronous JavaScript, HTML and CSS

Opera, Mozilla and Safari developers are collaborating in the WHAT WG and in W3C to make sure we have interoperable specifications for AJAX. I mean, ADHJACS.

 > by crush

 > Is the difficulty of producing a layout that consists of
 > three or more columns of equal height justification for
 > adding some new feature to the specification to make this easier?

I don't think so. CSS2 defines a table layout that can be used for this purpose. The problem is, and I'm repeating myself here, that the dominant browser doesn't support it. Adding yet more features to the specification wouldn't help.

 > How come, we um, lie?

Right. My name is, um, a bit troublesome to pronounce in English. But I'm a nice person who generally tells the truth. I often tell non-Norwegians that my first name is pronounced "howcome". That's close, but not quite. It does make for a great email address like howcome@opera.com, though.

So I may be a Lie, but I'm just a little white one :-)

You submitted questions for Håkon Wium Lie on June 20. Today we have his answers, not only to the (+5 moderated) questions we sent him, but to a bunch of others he thought would also be interesting to answer.

 > Where... by bcat24
 >
 > Do you think the W3C development process is too slow? I know that
 > you guys want everything to be perfect, but it seems to take far
 > longer than necessary. CSS 3 shows promise and I wouldn't want it
 > to die a slow death in standardization.

No, I don't think W3C is too slow. W3C isn't the bottleneck, browsers are. The dominant browser on the web hasn't been updated for years, and it doesn't make sense for specifications to get too far ahead. Rather, the CSS Working Group in W3C has focused on specification maintenance and achieving interoperability between implementations. This work is not so glamorous and some people — even within W3C — would prefer if they concentrate on new specifications. However, I think the focus on interoperability (which has resulted in CSS 2.1) has been crucial to the success of CSS.

CSS3 is a set of specifications that are developed more or less independently of each other. The best way to push a specification forward is to implement it. In the past year, we've seen some encouraging CSS3 implementations come along. For example, Mozilla supports multi-column layouts, Opera supports media queries, Prince supports cross-references and Safari supports borders and backgrounds. A few years from now, I think a select group of CSS3 modules will be interoperably supported in all browsers.

 > Why is CSS such a good idea but a pain to use?
 > by rar
 >
 > CSS is clearly very useful for separating style from content. But
 > apparently people tend to have problems when using it for layouts.
 > Would you say this is because people have not yet understood how to
 > properly do layout in CSS, or is it CSS that is lacking in this
 > area? What can be done to improve the situation? --- Would the web
 > benefit from HTML and CSS being complemented with some kind of
 > "layout language"?

I think layout and style should be tackled by the same language and the two are intertwined. Trying to split the two is like splitting the HTML specification in two, one specification describing inline elements and the other describing block elements. It's not worth the effort.

I think CSS is capable of describing beautiful and scalable layouts. The CSS Zen Garden has been a eye-opening showcase of what is possible today. If MS IE had supported CSS tables, another set of layouts would have been possible. So, there is still lots of potential in the existing CSS specifications which should be the next milestone. Beyond that, the CSS Working Group has started work on a new CSS3 module for advanced layout. Feedback is welcome.

 > CSS Evolution!
 > by eieken
 >
 > Is the wave of webpages designed completely in CSS what you
 > intially intended when you came up with CSS? Do you see that
 > changing? Is that good or bad?

I saw a clear need for a web style sheet language when proposing CSS in 1994. I also wanted CSS to fully describe the presentation of a web pages -- not just add some styling. All in all, I think it has turned out quite well. It has taken longer than I expected, but the scale -- due to the growth of the web -- is more than anyone could imagine.

I used "I" too many times in the previous paragraph. It's important to realize that CSS is a community effort rather that one man's work. Bert Bos joined me early and we worked out the initial designs on a whiteboard during the summer of 1995. The www-style mailing lists and the W3C CSS Working Group have also been crucial in ensuring the success of CSS.

If you're interested in the history of web style sheets, you'll find plenty of material in my PhD thesis on the subject.

 > Two questions (cut to 1.5 by editor Roblimo)
 > by Dolda2000

 > If you were allowed (perhaps by court order, which wouldn't be
 > unthinkable) to force Microsoft to do one (1) change in Internet
 > Explorer, what would that be?

I would force them to support one (1) single web page before shipping IE7, namely Acid2. By using a tiny amount of resources to get Acid2 right, Microsoft can save web designers and users endless amounts of frustration in the future. It would also be an honorable thing to do. This is what Microsoft's W3C representative wrote in 1998:

Microsoft has a deep commitment to working with the W3C on HTML and CSS. We have the first commercial implementation of HTML4, we were the first vendor anywhere to implement even portions of CSS, and we have put a tremendous amount of energy into seeing CSS mature to Level 2. We are still committed to complete implementations of the Recommendations of the W3C in this area (CSS and HTML and the DOM).

May I have one (1) more change? Please? Then I would make IE7 support TrueType downloadable fonts. Microsoft's record in fonts isn't that bad. They made their core fonts available for anyone to use, and IE supports downloadable fonts. Unfortunately, only the proprietary EOT format is supported. A few lines of code would be sufficient to support zipped TrueType fonts as well, and this would unleash a new wave of typography on the web. (To protect yourself, make sure you use a browser where author style sheets can be turned off — Shift-G in Opera). > As a bonus question: What do you think of Slashdot's CSS? ;)

The new design looks great! The style sheets behind the scene are more complex than what the average web page needs. But, we wouldn't expect anything average from Slashdot, would we?

> 6)  Opera
 > by taskforce
 >
 > Opera 9.0 seems to offer a lot of decent additions to Opera's
 > standards pool. How satisfied are you personally with the work the
 > team has done on implementing standards, and is there anything in
 > there you feel is superflous and anything you would have preferred
 > to see which wasn't in there?

I'm very proud of the standards support in Opera 9. Acid2 is an obvious favorite of mine and seeing that smiley face makes me very happy.

Among the more experimental features is support for Audio in HTML5. Web applications can now make sounds in a sensible way! Combined with the canvas element, developers can create Flash-like content without resorting to a proprietary format.

Having support for Bittorrent is also great. From a technical point of view, it makes much sense. Also, it's a political statement of sorts.

During the development of Opera9. Geir Ivarsøy, who founded Opera with Jon von Tetzchner, died after fighting cancer for years. Geir did a spectacular initial CSS implementation in Opera, thus convincing me to join the company. In music, the 9th is legendary. Beethoven, Schubert, Bruckner and Mahler all did 9 symphonies. Opera 9 was Geir's last symphony.

> Included styles, aliases
 > by Spy der Mann
 >
 > I always wanted to have "included" substyles or "aliases" in my
 > CSS definition, to save redundancy.
 >
 > (For includes)
 >
 >     .class1 { color:#ff0000; }
 >     .class2 { background-color:#ffffff; }
 >     .class3 { include:class1,class2;font-weight:bold; }
 >
 > (For aliases)
 >
 >     @alias color1 #ff0000;
 >     @alias color2 #ffffff;
 >     @alias default_image url('/img/image1.jpg');
 >
 >     .class1 { color:color1; }
 >     .class2 { background-image:default_image;background-color:co lor2; }
 >
 > This way we could change colors or images for a whole webpage
 > by editing a reduced number of lines.
 >
 > Had you considered any of these ideas in the past? If so,
 > why were they rejected?

Yes, aliases and constants have been considered. As David Wheeler noted, "Any problem in computer science can be solved with another layer of indirection."

CSS is already an indirection. Instead of putting properties and values directly on elements, it associates properties and values with selectors. What you (and others) are proposing is to add another layer of indirection. By doing so, one could possible write shorter, more manageable style sheets. However, there are also some downsides. It requires a new syntactic construct (@alias) and implementations must be able to remember a list of aliases. What if aliases are defined in one style sheet and referenced in another -- should that work? If so, what if the first style sheet isn't available?

For CSS1, the downsides of aliases were considered more significant than the benefits.

 > Definition of pixel
 > by Sara Chan
 >
 > The word pixel meant "picture element", but CSS redefined it
 >to mean something quite different (a particular subtended angle
 >of view [w3.org]). This causes confusion: CSS pixels are not pixels.
 >(Indeed, I have seen misinformed comments on Slashdot due to
 >that confusion.)
 >
 > My question is this: why call the subtended angle a "pixel", instead of
 >something else (e.g. "subangle")? If CSS wanted to use the subtended
 >angle for something, that is fine, but calling it a pixel seems to follow
 >the approach of Humpty Dumpty "When I use a word, it means just
 >what I choose it to mean".

In most cases, a CSS pixel will be equal to a device pixel. But, as you point out, the definition of a CSS pixel will sometimes be different. For example, on a laser printer, one CSS pixel can be equal to 3x3 device pixels to avoid printing illegibly small text and images. I don't recall anyone ever proposing another name for it. Subangle? Personally, I think most people would prefer the pragmatic "px" to the non-intuitive "sa".

> Vertical CSS Support
 > by infestedsenses
 >
 > As a developer who works with CSS every day, I find one
 > complication that continues to bother me in my daily work.
 > Support for CSS has always been good on the horizontal scope,
 > but vertical positioning has always been quite complicated.
 > Alone the procedure to affix a footer to the bottom of a screen
 > in dependance of the amount of content is unnecessarily difficult,
 > spawning hackish solutions such as "footerStickAlt"
 > [themaninblue.com]. Centering an object in the dead center of a
 > page also requires strange procedures such as this one [wpdfd.com],
 > which still aren't ideal (try making the viewport really small). The old
 > table method provided much easier methods for this. What are your
 > thoughts on this and do you see improvement following in future
 > CSS revisions?

Indeed, the CSS formatting model allows more control horizontally than vertically. This is due to (typically) having a known width, but an unknown height. As such, the height is harder to deal with.

However, CSS2 fixed positioning allows you to place content relative to the viewport (which is CSS-speak for window) instead of the document. For example, by setting position: fixed; bottom: 0 on an element, it will stick to the bottom. This works in Opera, Safari and Mozilla-based browsers. IE6 doesn't support it, however. It remains to be seen if IE7 will support it.

> About Microsoft...
 > by Chabil Ha'
 >
 > With MS's next browser release (IE 7), you mentioned in other
 > interviews that their decision to not supprt CSS2 was more a political
 > decision than a mechanical one. Aside from their obvious desire to
 > dominate the world, what politics do you think are in play that make
 > them not want to conform to the standard, and what do you think would
 > change that landscape so that they would have some initiative to
 > fully support it?

Great question. It's quite clear that Microsoft has the resources and talent to support CSS2 fully in IE and that plenty of people have reminded them why this is important. So, why don't they do it? The fundamental reason, I believe, is that standards don't benefit monopolists. Accepted, well-functioning, standards lower the barrier of entry to a market, and is therefore a threat to a monopolist.

From that perspective, it makes sense to leave CSS2 half-implemented. You can claim support (and many journalists will believe you), and you also ensure that no-one can use the unimplemented (or worse: buggily implemented) features of the standard. The only way to change the equation is to remind Microsoft how embarrassing it is to offer a sub-standard browser. And to use better browsers.

Another reason for not making a IE too good is that it will compete with Windows. A modern browser is an application platform; the combination of HTML, JavaScript, CSS and DOM allows developers to target the web instead of Windows, Linux, or Mac.

> From linvir
 > How long since you last used Linux?

I'm using it right now. Ubuntu on a IBM Thinkpad X41 is the environment I live in. Ubuntu rocks -- especially with Opera on top! (And Emacs right underneath.)

 > From Rob T Firefly (844560)
 > Why the curly brackets?

The initial CSS proposal didn't use them, instead relying on newlines to separate statements. TimBL didn't really like that and I therefore borrowed the curly braces from the C programming language. The syntax for comments came along as well. I think it works quite well.

 > why not XML?
 > by slashdot.org
 > Simple question (hopefully simple answer ;-)): why
 > did you not use XML?

The simple answer is that the development of CSS preceded XML by a year or so. However, if XML had been available, would we have used it? Probably not. And I suspect Brendan Eich of JavaScript fame would answer the same way on behalf of his language.

XML is a great syntax for structured data, but not suitable for all languages. Still, I think the SGML-based syntax for the FOSI style sheet language.

 > Padding
 > by Anonymous Coward

 > Why was the decision made to make padding apply outside
 > of the width of a 'box', rather than inside, which would seem
 > to make more sense?

It makes sense in some situations, but not in others. For example, when a child element is set to width: 100%, I don't think it should cover the padding of its parent. The box-sizing property in CSS3 addresses this issue. Ideally, the issue should have been addressed earlier, though.

> by nuzak

 > why not float:

 > DSSSL had this sort of thing solved before HTML even existed,
 > let alone CSS. But scheme is too scary and icky, and the W3C
 > believes in a principle of least power, so CSS has to be fully declarative,
 > static, and crippled until patched later.

You're wrong about DSSSL -- it didn't support floating text (as in having text wrap around images) at all. And the DSSSL specification only became publically available around 1996, years after HTML.

> by MagicM

 > How frustrating is it to write a specification knowing
 > that you're at the browser vendors' mercy?

That's part of the game. I don't think any specification has a birthright to be fully supported by all browsers. There should be healthy competition between different specifications. I believe simple, author-friendly specifications will prevail in this environment.

Microformats are another way of developing new formats. Instead of having to convince browser vendors to support your favorite specification, microformats add semantics to HTML through the CLASS attribute. And style it with CSS.

> New standards
 > by iamsure
 >
 > In your work at Opera, you have clearly paved a path that includes
 > going beyond the W3C standards. Whether it is WhatWG
 > implementations, or new functionality specific to Opera (2dgame),
 > you are pushing into new territory. Can you explain why W3C isn't
 > sufficient, and why efforts at Opera to expand beyond the standards
 > differ from Microsoft's embrace/extend model?

It's a fair question. The WhatWG was set up when it seemed as if W3C didn't care much about browsers anymore. That has definitely changed and work items from WhatWG are now channeled into W3C (e.g., XMLHttpRequest).

At Opera, we sometimes include experimental features before they have been standardized. When this happens they are labeled as such, but we still try to document them. For example, we support some Opera-only CSS properties for XML. If these features gain traction, we are happy to work with other organizations to standardize them. If they don't become popular, the features will most likely disappear.

 > Beyond HTML
 > by pr1000

 > How far can CSS be taken beyond the web page--that is,
 > have generalized or non-web specific features for such things
 > as page formatting or type setting? Do you plan/wish/hope to
 > take it farther than it currently is?

Yes, I think it's possible to take CSS further in several directions. I'm eager to see CSS being used in paper-based publishing and I joined the board of YesLogic — which makes the Prince XML to PDF converter — to make sure they added my favorite features. Bert and I used Prince to generate PDF from HTML and CSS sources for the third edition of our book. W3C just published a new Working Draft which describes features for printing, e.g., footnotes, cross-references, and even generated indexes.

For mobile units, I think Media Queries will be important. For example, they can express that large images should not be sent to mobile devices.

Another great opportunity for CSS is Web Applications. Just like documents, applications need to be styled and CSS is an intrinsic component of AJAX. The "AJAX" name sounds great, but allow me to propose a few alternate spellings that I find more accurate:

• AJACX: Asynchronous JavaScript, CSS and XMLHttpRequest
• ADJACS: Asynchronous DOM, JavaScript and CSS
• ADHJACS: Asynchronous DOM, HTML, JavaScript and CSS
• AJAHCS: Asynchronous JavaScript, HTML and CSS
• AJACS: Asynchronous JavaScript, HTML and CSS

Opera, Mozilla and Safari developers are collaborating in the WHAT WG and in W3C to make sure we have interoperable specifications for AJAX. I mean, ADHJACS.

 > by crush

 > Is the difficulty of producing a layout that consists of
 > three or more columns of equal height justification for
 > adding some new feature to the specification to make this easier?

I don't think so. CSS2 defines a table layout that can be used for this purpose. The problem is, and I'm repeating myself here, that the dominant browser doesn't support it. Adding yet more features to the specification wouldn't help.

 > How come, we um, lie?

Right. My name is, um, a bit troublesome to pronounce in English. But I'm a nice person who generally tells the truth. I often tell non-Norwegians that my first name is pronounced "howcome". That's close, but not quite. It does make for a great email address like howcome@opera.com, though.

So I may be a Lie, but I'm just a little white one :-)

You submitted questions for Håkon Wium Lie on June 20. Today we have his answers, not only to the (+5 moderated) questions we sent him, but to a bunch of others he thought would also be interesting to answer.

 > Where... by bcat24
 >
 > Do you think the W3C development process is too slow? I know that
 > you guys want everything to be perfect, but it seems to take far
 > longer than necessary. CSS 3 shows promise and I wouldn't want it
 > to die a slow death in standardization.

No, I don't think W3C is too slow. W3C isn't the bottleneck, browsers are. The dominant browser on the web hasn't been updated for years, and it doesn't make sense for specifications to get too far ahead. Rather, the CSS Working Group in W3C has focused on specification maintenance and achieving interoperability between implementations. This work is not so glamorous and some people — even within W3C — would prefer if they concentrate on new specifications. However, I think the focus on interoperability (which has resulted in CSS 2.1) has been crucial to the success of CSS.

CSS3 is a set of specifications that are developed more or less independently of each other. The best way to push a specification forward is to implement it. In the past year, we've seen some encouraging CSS3 implementations come along. For example, Mozilla supports multi-column layouts, Opera supports media queries, Prince supports cross-references and Safari supports borders and backgrounds. A few years from now, I think a select group of CSS3 modules will be interoperably supported in all browsers.

 > Why is CSS such a good idea but a pain to use?
 > by rar
 >
 > CSS is clearly very useful for separating style from content. But
 > apparently people tend to have problems when using it for layouts.
 > Would you say this is because people have not yet understood how to
 > properly do layout in CSS, or is it CSS that is lacking in this
 > area? What can be done to improve the situation? --- Would the web
 > benefit from HTML and CSS being complemented with some kind of
 > "layout language"?

I think layout and style should be tackled by the same language and the two are intertwined. Trying to split the two is like splitting the HTML specification in two, one specification describing inline elements and the other describing block elements. It's not worth the effort.

I think CSS is capable of describing beautiful and scalable layouts. The CSS Zen Garden has been a eye-opening showcase of what is possible today. If MS IE had supported CSS tables, another set of layouts would have been possible. So, there is still lots of potential in the existing CSS specifications which should be the next milestone. Beyond that, the CSS Working Group has started work on a new CSS3 module for advanced layout. Feedback is welcome.

 > CSS Evolution!
 > by eieken
 >
 > Is the wave of webpages designed completely in CSS what you
 > intially intended when you came up with CSS? Do you see that
 > changing? Is that good or bad?

I saw a clear need for a web style sheet language when proposing CSS in 1994. I also wanted CSS to fully describe the presentation of a web pages -- not just add some styling. All in all, I think it has turned out quite well. It has taken longer than I expected, but the scale -- due to the growth of the web -- is more than anyone could imagine.

I used "I" too many times in the previous paragraph. It's important to realize that CSS is a community effort rather that one man's work. Bert Bos joined me early and we worked out the initial designs on a whiteboard during the summer of 1995. The www-style mailing lists and the W3C CSS Working Group have also been crucial in ensuring the success of CSS.

If you're interested in the history of web style sheets, you'll find plenty of material in my PhD thesis on the subject.

 > Two questions (cut to 1.5 by editor Roblimo)
 > by Dolda2000

 > If you were allowed (perhaps by court order, which wouldn't be
 > unthinkable) to force Microsoft to do one (1) change in Internet
 > Explorer, what would that be?

I would force them to support one (1) single web page before shipping IE7, namely Acid2. By using a tiny amount of resources to get Acid2 right, Microsoft can save web designers and users endless amounts of frustration in the future. It would also be an honorable thing to do. This is what Microsoft's W3C representative wrote in 1998:

Microsoft has a deep commitment to working with the W3C on HTML and CSS. We have the first commercial implementation of HTML4, we were the first vendor anywhere to implement even portions of CSS, and we have put a tremendous amount of energy into seeing CSS mature to Level 2. We are still committed to complete implementations of the Recommendations of the W3C in this area (CSS and HTML and the DOM).

May I have one (1) more change? Please? Then I would make IE7 support TrueType downloadable fonts. Microsoft's record in fonts isn't that bad. They made their core fonts available for anyone to use, and IE supports downloadable fonts. Unfortunately, only the proprietary EOT format is supported. A few lines of code would be sufficient to support zipped TrueType fonts as well, and this would unleash a new wave of typography on the web. (To protect yourself, make sure you use a browser where author style sheets can be turned off — Shift-G in Opera). > As a bonus question: What do you think of Slashdot's CSS? ;)

The new design looks great! The style sheets behind the scene are more complex than what the average web page needs. But, we wouldn't expect anything average from Slashdot, would we?

> 6)  Opera
 > by taskforce
 >
 > Opera 9.0 seems to offer a lot of decent additions to Opera's
 > standards pool. How satisfied are you personally with the work the
 > team has done on implementing standards, and is there anything in
 > there you feel is superflous and anything you would have preferred
 > to see which wasn't in there?

I'm very proud of the standards support in Opera 9. Acid2 is an obvious favorite of mine and seeing that smiley face makes me very happy.

Among the more experimental features is support for Audio in HTML5. Web applications can now make sounds in a sensible way! Combined with the canvas element, developers can create Flash-like content without resorting to a proprietary format.

Having support for Bittorrent is also great. From a technical point of view, it makes much sense. Also, it's a political statement of sorts.

During the development of Opera9. Geir Ivarsøy, who founded Opera with Jon von Tetzchner, died after fighting cancer for years. Geir did a spectacular initial CSS implementation in Opera, thus convincing me to join the company. In music, the 9th is legendary. Beethoven, Schubert, Bruckner and Mahler all did 9 symphonies. Opera 9 was Geir's last symphony.

> Included styles, aliases
 > by Spy der Mann
 >
 > I always wanted to have "included" substyles or "aliases" in my
 > CSS definition, to save redundancy.
 >
 > (For includes)
 >
 >     .class1 { color:#ff0000; }
 >     .class2 { background-color:#ffffff; }
 >     .class3 { include:class1,class2;font-weight:bold; }
 >
 > (For aliases)
 >
 >     @alias color1 #ff0000;
 >     @alias color2 #ffffff;
 >     @alias default_image url('/img/image1.jpg');
 >
 >     .class1 { color:color1; }
 >     .class2 { background-image:default_image;background-color:co lor2; }
 >
 > This way we could change colors or images for a whole webpage
 > by editing a reduced number of lines.
 >
 > Had you considered any of these ideas in the past? If so,
 > why were they rejected?

Yes, aliases and constants have been considered. As David Wheeler noted, "Any problem in computer science can be solved with another layer of indirection."

CSS is already an indirection. Instead of putting properties and values directly on elements, it associates properties and values with selectors. What you (and others) are proposing is to add another layer of indirection. By doing so, one could possible write shorter, more manageable style sheets. However, there are also some downsides. It requires a new syntactic construct (@alias) and implementations must be able to remember a list of aliases. What if aliases are defined in one style sheet and referenced in another -- should that work? If so, what if the first style sheet isn't available?

For CSS1, the downsides of aliases were considered more significant than the benefits.

 > Definition of pixel
 > by Sara Chan
 >
 > The word pixel meant "picture element", but CSS redefined it
 >to mean something quite different (a particular subtended angle
 >of view [w3.org]). This causes confusion: CSS pixels are not pixels.
 >(Indeed, I have seen misinformed comments on Slashdot due to
 >that confusion.)
 >
 > My question is this: why call the subtended angle a "pixel", instead of
 >something else (e.g. "subangle")? If CSS wanted to use the subtended
 >angle for something, that is fine, but calling it a pixel seems to follow
 >the approach of Humpty Dumpty "When I use a word, it means just
 >what I choose it to mean".

In most cases, a CSS pixel will be equal to a device pixel. But, as you point out, the definition of a CSS pixel will sometimes be different. For example, on a laser printer, one CSS pixel can be equal to 3x3 device pixels to avoid printing illegibly small text and images. I don't recall anyone ever proposing another name for it. Subangle? Personally, I think most people would prefer the pragmatic "px" to the non-intuitive "sa".

> Vertical CSS Support
 > by infestedsenses
 >
 > As a developer who works with CSS every day, I find one
 > complication that continues to bother me in my daily work.
 > Support for CSS has always been good on the horizontal scope,
 > but vertical positioning has always been quite complicated.
 > Alone the procedure to affix a footer to the bottom of a screen
 > in dependance of the amount of content is unnecessarily difficult,
 > spawning hackish solutions such as "footerStickAlt"
 > [themaninblue.com]. Centering an object in the dead center of a
 > page also requires strange procedures such as this one [wpdfd.com],
 > which still aren't ideal (try making the viewport really small). The old
 > table method provided much easier methods for this. What are your
 > thoughts on this and do you see improvement following in future
 > CSS revisions?

Indeed, the CSS formatting model allows more control horizontally than vertically. This is due to (typically) having a known width, but an unknown height. As such, the height is harder to deal with.

However, CSS2 fixed positioning allows you to place content relative to the viewport (which is CSS-speak for window) instead of the document. For example, by setting position: fixed; bottom: 0 on an element, it will stick to the bottom. This works in Opera, Safari and Mozilla-based browsers. IE6 doesn't support it, however. It remains to be seen if IE7 will support it.

> About Microsoft...
 > by Chabil Ha'
 >
 > With MS's next browser release (IE 7), you mentioned in other
 > interviews that their decision to not supprt CSS2 was more a political
 > decision than a mechanical one. Aside from their obvious desire to
 > dominate the world, what politics do you think are in play that make
 > them not want to conform to the standard, and what do you think would
 > change that landscape so that they would have some initiative to
 > fully support it?

Great question. It's quite clear that Microsoft has the resources and talent to support CSS2 fully in IE and that plenty of people have reminded them why this is important. So, why don't they do it? The fundamental reason, I believe, is that standards don't benefit monopolists. Accepted, well-functioning, standards lower the barrier of entry to a market, and is therefore a threat to a monopolist.

From that perspective, it makes sense to leave CSS2 half-implemented. You can claim support (and many journalists will believe you), and you also ensure that no-one can use the unimplemented (or worse: buggily implemented) features of the standard. The only way to change the equation is to remind Microsoft how embarrassing it is to offer a sub-standard browser. And to use better browsers.

Another reason for not making a IE too good is that it will compete with Windows. A modern browser is an application platform; the combination of HTML, JavaScript, CSS and DOM allows developers to target the web instead of Windows, Linux, or Mac.

> From linvir
 > How long since you last used Linux?

I'm using it right now. Ubuntu on a IBM Thinkpad X41 is the environment I live in. Ubuntu rocks -- especially with Opera on top! (And Emacs right underneath.)

 > From Rob T Firefly (844560)
 > Why the curly brackets?

The initial CSS proposal didn't use them, instead relying on newlines to separate statements. TimBL didn't really like that and I therefore borrowed the curly braces from the C programming language. The syntax for comments came along as well. I think it works quite well.

 > why not XML?
 > by slashdot.org
 > Simple question (hopefully simple answer ;-)): why
 > did you not use XML?

The simple answer is that the development of CSS preceded XML by a year or so. However, if XML had been available, would we have used it? Probably not. And I suspect Brendan Eich of JavaScript fame would answer the same way on behalf of his language.

XML is a great syntax for structured data, but not suitable for all languages. Still, I think the SGML-based syntax for the FOSI style sheet language.

 > Padding
 > by Anonymous Coward

 > Why was the decision made to make padding apply outside
 > of the width of a 'box', rather than inside, which would seem
 > to make more sense?

It makes sense in some situations, but not in others. For example, when a child element is set to width: 100%, I don't think it should cover the padding of its parent. The box-sizing property in CSS3 addresses this issue. Ideally, the issue should have been addressed earlier, though.

> by nuzak

 > why not float:

 > DSSSL had this sort of thing solved before HTML even existed,
 > let alone CSS. But scheme is too scary and icky, and the W3C
 > believes in a principle of least power, so CSS has to be fully declarative,
 > static, and crippled until patched later.

You're wrong about DSSSL -- it didn't support floating text (as in having text wrap around images) at all. And the DSSSL specification only became publically available around 1996, years after HTML.

> by MagicM

 > How frustrating is it to write a specification knowing
 > that you're at the browser vendors' mercy?

That's part of the game. I don't think any specification has a birthright to be fully supported by all browsers. There should be healthy competition between different specifications. I believe simple, author-friendly specifications will prevail in this environment.

Microformats are another way of developing new formats. Instead of having to convince browser vendors to support your favorite specification, microformats add semantics to HTML through the CLASS attribute. And style it with CSS.

> New standards
 > by iamsure
 >
 > In your work at Opera, you have clearly paved a path that includes
 > going beyond the W3C standards. Whether it is WhatWG
 > implementations, or new functionality specific to Opera (2dgame),
 > you are pushing into new territory. Can you explain why W3C isn't
 > sufficient, and why efforts at Opera to expand beyond the standards
 > differ from Microsoft's embrace/extend model?

It's a fair question. The WhatWG was set up when it seemed as if W3C didn't care much about browsers anymore. That has definitely changed and work items from WhatWG are now channeled into W3C (e.g., XMLHttpRequest).

At Opera, we sometimes include experimental features before they have been standardized. When this happens they are labeled as such, but we still try to document them. For example, we support some Opera-only CSS properties for XML. If these features gain traction, we are happy to work with other organizations to standardize them. If they don't become popular, the features will most likely disappear.

 > Beyond HTML
 > by pr1000

 > How far can CSS be taken beyond the web page--that is,
 > have generalized or non-web specific features for such things
 > as page formatting or type setting? Do you plan/wish/hope to
 > take it farther than it currently is?

Yes, I think it's possible to take CSS further in several directions. I'm eager to see CSS being used in paper-based publishing and I joined the board of YesLogic — which makes the Prince XML to PDF converter — to make sure they added my favorite features. Bert and I used Prince to generate PDF from HTML and CSS sources for the third edition of our book. W3C just published a new Working Draft which describes features for printing, e.g., footnotes, cross-references, and even generated indexes.

For mobile units, I think Media Queries will be important. For example, they can express that large images should not be sent to mobile devices.

Another great opportunity for CSS is Web Applications. Just like documents, applications need to be styled and CSS is an intrinsic component of AJAX. The "AJAX" name sounds great, but allow me to propose a few alternate spellings that I find more accurate:

• AJACX: Asynchronous JavaScript, CSS and XMLHttpRequest
• ADJACS: Asynchronous DOM, JavaScript and CSS
• ADHJACS: Asynchronous DOM, HTML, JavaScript and CSS
• AJAHCS: Asynchronous JavaScript, HTML and CSS
• AJACS: Asynchronous JavaScript, HTML and CSS

Opera, Mozilla and Safari developers are collaborating in the WHAT WG and in W3C to make sure we have interoperable specifications for AJAX. I mean, ADHJACS.

 > by crush

 > Is the difficulty of producing a layout that consists of
 > three or more columns of equal height justification for
 > adding some new feature to the specification to make this easier?

I don't think so. CSS2 defines a table layout that can be used for this purpose. The problem is, and I'm repeating myself here, that the dominant browser doesn't support it. Adding yet more features to the specification wouldn't help.

 > How come, we um, lie?

Right. My name is, um, a bit troublesome to pronounce in English. But I'm a nice person who generally tells the truth. I often tell non-Norwegians that my first name is pronounced "howcome". That's close, but not quite. It does make for a great email address like howcome@opera.com, though.

So I may be a Lie, but I'm just a little white one :-)

You submitted questions for Håkon Wium Lie on June 20. Today we have his answers, not only to the (+5 moderated) questions we sent him, but to a bunch of others he thought would also be interesting to answer.

 > Where... by bcat24
 >
 > Do you think the W3C development process is too slow? I know that
 > you guys want everything to be perfect, but it seems to take far
 > longer than necessary. CSS 3 shows promise and I wouldn't want it
 > to die a slow death in standardization.

No, I don't think W3C is too slow. W3C isn't the bottleneck, browsers are. The dominant browser on the web hasn't been updated for years, and it doesn't make sense for specifications to get too far ahead. Rather, the CSS Working Group in W3C has focused on specification maintenance and achieving interoperability between implementations. This work is not so glamorous and some people — even within W3C — would prefer if they concentrate on new specifications. However, I think the focus on interoperability (which has resulted in CSS 2.1) has been crucial to the success of CSS.

CSS3 is a set of specifications that are developed more or less independently of each other. The best way to push a specification forward is to implement it. In the past year, we've seen some encouraging CSS3 implementations come along. For example, Mozilla supports multi-column layouts, Opera supports media queries, Prince supports cross-references and Safari supports borders and backgrounds. A few years from now, I think a select group of CSS3 modules will be interoperably supported in all browsers.

 > Why is CSS such a good idea but a pain to use?
 > by rar
 >
 > CSS is clearly very useful for separating style from content. But
 > apparently people tend to have problems when using it for layouts.
 > Would you say this is because people have not yet understood how to
 > properly do layout in CSS, or is it CSS that is lacking in this
 > area? What can be done to improve the situation? --- Would the web
 > benefit from HTML and CSS being complemented with some kind of
 > "layout language"?

I think layout and style should be tackled by the same language and the two are intertwined. Trying to split the two is like splitting the HTML specification in two, one specification describing inline elements and the other describing block elements. It's not worth the effort.

I think CSS is capable of describing beautiful and scalable layouts. The CSS Zen Garden has been a eye-opening showcase of what is possible today. If MS IE had supported CSS tables, another set of layouts would have been possible. So, there is still lots of potential in the existing CSS specifications which should be the next milestone. Beyond that, the CSS Working Group has started work on a new CSS3 module for advanced layout. Feedback is welcome.

 > CSS Evolution!
 > by eieken
 >
 > Is the wave of webpages designed completely in CSS what you
 > intially intended when you came up with CSS? Do you see that
 > changing? Is that good or bad?

I saw a clear need for a web style sheet language when proposing CSS in 1994. I also wanted CSS to fully describe the presentation of a web pages -- not just add some styling. All in all, I think it has turned out quite well. It has taken longer than I expected, but the scale -- due to the growth of the web -- is more than anyone could imagine.

I used "I" too many times in the previous paragraph. It's important to realize that CSS is a community effort rather that one man's work. Bert Bos joined me early and we worked out the initial designs on a whiteboard during the summer of 1995. The www-style mailing lists and the W3C CSS Working Group have also been crucial in ensuring the success of CSS.

If you're interested in the history of web style sheets, you'll find plenty of material in my PhD thesis on the subject.

 > Two questions (cut to 1.5 by editor Roblimo)
 > by Dolda2000

 > If you were allowed (perhaps by court order, which wouldn't be
 > unthinkable) to force Microsoft to do one (1) change in Internet
 > Explorer, what would that be?

I would force them to support one (1) single web page before shipping IE7, namely Acid2. By using a tiny amount of resources to get Acid2 right, Microsoft can save web designers and users endless amounts of frustration in the future. It would also be an honorable thing to do. This is what Microsoft's W3C representative wrote in 1998:

Microsoft has a deep commitment to working with the W3C on HTML and CSS. We have the first commercial implementation of HTML4, we were the first vendor anywhere to implement even portions of CSS, and we have put a tremendous amount of energy into seeing CSS mature to Level 2. We are still committed to complete implementations of the Recommendations of the W3C in this area (CSS and HTML and the DOM).

May I have one (1) more change? Please? Then I would make IE7 support TrueType downloadable fonts. Microsoft's record in fonts isn't that bad. They made their core fonts available for anyone to use, and IE supports downloadable fonts. Unfortunately, only the proprietary EOT format is supported. A few lines of code would be sufficient to support zipped TrueType fonts as well, and this would unleash a new wave of typography on the web. (To protect yourself, make sure you use a browser where author style sheets can be turned off — Shift-G in Opera). > As a bonus question: What do you think of Slashdot's CSS? ;)

The new design looks great! The style sheets behind the scene are more complex than what the average web page needs. But, we wouldn't expect anything average from Slashdot, would we?

> 6)  Opera
 > by taskforce
 >
 > Opera 9.0 seems to offer a lot of decent additions to Opera's
 > standards pool. How satisfied are you personally with the work the
 > team has done on implementing standards, and is there anything in
 > there you feel is superflous and anything you would have preferred
 > to see which wasn't in there?

I'm very proud of the standards support in Opera 9. Acid2 is an obvious favorite of mine and seeing that smiley face makes me very happy.

Among the more experimental features is support for Audio in HTML5. Web applications can now make sounds in a sensible way! Combined with the canvas element, developers can create Flash-like content without resorting to a proprietary format.

Having support for Bittorrent is also great. From a technical point of view, it makes much sense. Also, it's a political statement of sorts.

During the development of Opera9. Geir Ivarsøy, who founded Opera with Jon von Tetzchner, died after fighting cancer for years. Geir did a spectacular initial CSS implementation in Opera, thus convincing me to join the company. In music, the 9th is legendary. Beethoven, Schubert, Bruckner and Mahler all did 9 symphonies. Opera 9 was Geir's last symphony.

> Included styles, aliases
 > by Spy der Mann
 >
 > I always wanted to have "included" substyles or "aliases" in my
 > CSS definition, to save redundancy.
 >
 > (For includes)
 >
 >     .class1 { color:#ff0000; }
 >     .class2 { background-color:#ffffff; }
 >     .class3 { include:class1,class2;font-weight:bold; }
 >
 > (For aliases)
 >
 >     @alias color1 #ff0000;
 >     @alias color2 #ffffff;
 >     @alias default_image url('/img/image1.jpg');
 >
 >     .class1 { color:color1; }
 >     .class2 { background-image:default_image;background-color:co lor2; }
 >
 > This way we could change colors or images for a whole webpage
 > by editing a reduced number of lines.
 >
 > Had you considered any of these ideas in the past? If so,
 > why were they rejected?

Yes, aliases and constants have been considered. As David Wheeler noted, "Any problem in computer science can be solved with another layer of indirection."

CSS is already an indirection. Instead of putting properties and values directly on elements, it associates properties and values with selectors. What you (and others) are proposing is to add another layer of indirection. By doing so, one could possible write shorter, more manageable style sheets. However, there are also some downsides. It requires a new syntactic construct (@alias) and implementations must be able to remember a list of aliases. What if aliases are defined in one style sheet and referenced in another -- should that work? If so, what if the first style sheet isn't available?

For CSS1, the downsides of aliases were considered more significant than the benefits.

 > Definition of pixel
 > by Sara Chan
 >
 > The word pixel meant "picture element", but CSS redefined it
 >to mean something quite different (a particular subtended angle
 >of view [w3.org]). This causes confusion: CSS pixels are not pixels.
 >(Indeed, I have seen misinformed comments on Slashdot due to
 >that confusion.)
 >
 > My question is this: why call the subtended angle a "pixel", instead of
 >something else (e.g. "subangle")? If CSS wanted to use the subtended
 >angle for something, that is fine, but calling it a pixel seems to follow
 >the approach of Humpty Dumpty "When I use a word, it means just
 >what I choose it to mean".

In most cases, a CSS pixel will be equal to a device pixel. But, as you point out, the definition of a CSS pixel will sometimes be different. For example, on a laser printer, one CSS pixel can be equal to 3x3 device pixels to avoid printing illegibly small text and images. I don't recall anyone ever proposing another name for it. Subangle? Personally, I think most people would prefer the pragmatic "px" to the non-intuitive "sa".

> Vertical CSS Support
 > by infestedsenses
 >
 > As a developer who works with CSS every day, I find one
 > complication that continues to bother me in my daily work.
 > Support for CSS has always been good on the horizontal scope,
 > but vertical positioning has always been quite complicated.
 > Alone the procedure to affix a footer to the bottom of a screen
 > in dependance of the amount of content is unnecessarily difficult,
 > spawning hackish solutions such as "footerStickAlt"
 > [themaninblue.com]. Centering an object in the dead center of a
 > page also requires strange procedures such as this one [wpdfd.com],
 > which still aren't ideal (try making the viewport really small). The old
 > table method provided much easier methods for this. What are your
 > thoughts on this and do you see improvement following in future
 > CSS revisions?

Indeed, the CSS formatting model allows more control horizontally than vertically. This is due to (typically) having a known width, but an unknown height. As such, the height is harder to deal with.

However, CSS2 fixed positioning allows you to place content relative to the viewport (which is CSS-speak for window) instead of the document. For example, by setting position: fixed; bottom: 0 on an element, it will stick to the bottom. This works in Opera, Safari and Mozilla-based browsers. IE6 doesn't support it, however. It remains to be seen if IE7 will support it.

> About Microsoft...
 > by Chabil Ha'
 >
 > With MS's next browser release (IE 7), you mentioned in other
 > interviews that their decision to not supprt CSS2 was more a political
 > decision than a mechanical one. Aside from their obvious desire to
 > dominate the world, what politics do you think are in play that make
 > them not want to conform to the standard, and what do you think would
 > change that landscape so that they would have some initiative to
 > fully support it?

Great question. It's quite clear that Microsoft has the resources and talent to support CSS2 fully in IE and that plenty of people have reminded them why this is important. So, why don't they do it? The fundamental reason, I believe, is that standards don't benefit monopolists. Accepted, well-functioning, standards lower the barrier of entry to a market, and is therefore a threat to a monopolist.

From that perspective, it makes sense to leave CSS2 half-implemented. You can claim support (and many journalists will believe you), and you also ensure that no-one can use the unimplemented (or worse: buggily implemented) features of the standard. The only way to change the equation is to remind Microsoft how embarrassing it is to offer a sub-standard browser. And to use better browsers.

Another reason for not making a IE too good is that it will compete with Windows. A modern browser is an application platform; the combination of HTML, JavaScript, CSS and DOM allows developers to target the web instead of Windows, Linux, or Mac.

> From linvir
 > How long since you last used Linux?

I'm using it right now. Ubuntu on a IBM Thinkpad X41 is the environment I live in. Ubuntu rocks -- especially with Opera on top! (And Emacs right underneath.)

 > From Rob T Firefly (844560)
 > Why the curly brackets?

The initial CSS proposal didn't use them, instead relying on newlines to separate statements. TimBL didn't really like that and I therefore borrowed the curly braces from the C programming language. The syntax for comments came along as well. I think it works quite well.

 > why not XML?
 > by slashdot.org
 > Simple question (hopefully simple answer ;-)): why
 > did you not use XML?

The simple answer is that the development of CSS preceded XML by a year or so. However, if XML had been available, would we have used it? Probably not. And I suspect Brendan Eich of JavaScript fame would answer the same way on behalf of his language.

XML is a great syntax for structured data, but not suitable for all languages. Still, I think the SGML-based syntax for the FOSI style sheet language.

 > Padding
 > by Anonymous Coward

 > Why was the decision made to make padding apply outside
 > of the width of a 'box', rather than inside, which would seem
 > to make more sense?

It makes sense in some situations, but not in others. For example, when a child element is set to width: 100%, I don't think it should cover the padding of its parent. The box-sizing property in CSS3 addresses this issue. Ideally, the issue should have been addressed earlier, though.

> by nuzak

 > why not float:

 > DSSSL had this sort of thing solved before HTML even existed,
 > let alone CSS. But scheme is too scary and icky, and the W3C
 > believes in a principle of least power, so CSS has to be fully declarative,
 > static, and crippled until patched later.

You're wrong about DSSSL -- it didn't support floating text (as in having text wrap around images) at all. And the DSSSL specification only became publically available around 1996, years after HTML.

> by MagicM

 > How frustrating is it to write a specification knowing
 > that you're at the browser vendors' mercy?

That's part of the game. I don't think any specification has a birthright to be fully supported by all browsers. There should be healthy competition between different specifications. I believe simple, author-friendly specifications will prevail in this environment.

Microformats are another way of developing new formats. Instead of having to convince browser vendors to support your favorite specification, microformats add semantics to HTML through the CLASS attribute. And style it with CSS.

> New standards
 > by iamsure
 >
 > In your work at Opera, you have clearly paved a path that includes
 > going beyond the W3C standards. Whether it is WhatWG
 > implementations, or new functionality specific to Opera (2dgame),
 > you are pushing into new territory. Can you explain why W3C isn't
 > sufficient, and why efforts at Opera to expand beyond the standards
 > differ from Microsoft's embrace/extend model?

It's a fair question. The WhatWG was set up when it seemed as if W3C didn't care much about browsers anymore. That has definitely changed and work items from WhatWG are now channeled into W3C (e.g., XMLHttpRequest).

At Opera, we sometimes include experimental features before they have been standardized. When this happens they are labeled as such, but we still try to document them. For example, we support some Opera-only CSS properties for XML. If these features gain traction, we are happy to work with other organizations to standardize them. If they don't become popular, the features will most likely disappear.

 > Beyond HTML
 > by pr1000

 > How far can CSS be taken beyond the web page--that is,
 > have generalized or non-web specific features for such things
 > as page formatting or type setting? Do you plan/wish/hope to
 > take it farther than it currently is?

Yes, I think it's possible to take CSS further in several directions. I'm eager to see CSS being used in paper-based publishing and I joined the board of YesLogic — which makes the Prince XML to PDF converter — to make sure they added my favorite features. Bert and I used Prince to generate PDF from HTML and CSS sources for the third edition of our book. W3C just published a new Working Draft which describes features for printing, e.g., footnotes, cross-references, and even generated indexes.

For mobile units, I think Media Queries will be important. For example, they can express that large images should not be sent to mobile devices.

Another great opportunity for CSS is Web Applications. Just like documents, applications need to be styled and CSS is an intrinsic component of AJAX. The "AJAX" name sounds great, but allow me to propose a few alternate spellings that I find more accurate:

• AJACX: Asynchronous JavaScript, CSS and XMLHttpRequest
• ADJACS: Asynchronous DOM, JavaScript and CSS
• ADHJACS: Asynchronous DOM, HTML, JavaScript and CSS
• AJAHCS: Asynchronous JavaScript, HTML and CSS
• AJACS: Asynchronous JavaScript, HTML and CSS

Opera, Mozilla and Safari developers are collaborating in the WHAT WG and in W3C to make sure we have interoperable specifications for AJAX. I mean, ADHJACS.

 > by crush

 > Is the difficulty of producing a layout that consists of
 > three or more columns of equal height justification for
 > adding some new feature to the specification to make this easier?

I don't think so. CSS2 defines a table layout that can be used for this purpose. The problem is, and I'm repeating myself here, that the dominant browser doesn't support it. Adding yet more features to the specification wouldn't help.

 > How come, we um, lie?

Right. My name is, um, a bit troublesome to pronounce in English. But I'm a nice person who generally tells the truth. I often tell non-Norwegians that my first name is pronounced "howcome". That's close, but not quite. It does make for a great email address like howcome@opera.com, though.

So I may be a Lie, but I'm just a little white one :-)

You submitted questions for Håkon Wium Lie on June 20. Today we have his answers, not only to the (+5 moderated) questions we sent him, but to a bunch of others he thought would also be interesting to answer.

 > Where... by bcat24
 >
 > Do you think the W3C development process is too slow? I know that
 > you guys want everything to be perfect, but it seems to take far
 > longer than necessary. CSS 3 shows promise and I wouldn't want it
 > to die a slow death in standardization.

No, I don't think W3C is too slow. W3C isn't the bottleneck, browsers are. The dominant browser on the web hasn't been updated for years, and it doesn't make sense for specifications to get too far ahead. Rather, the CSS Working Group in W3C has focused on specification maintenance and achieving interoperability between implementations. This work is not so glamorous and some people — even within W3C — would prefer if they concentrate on new specifications. However, I think the focus on interoperability (which has resulted in CSS 2.1) has been crucial to the success of CSS.

CSS3 is a set of specifications that are developed more or less independently of each other. The best way to push a specification forward is to implement it. In the past year, we've seen some encouraging CSS3 implementations come along. For example, Mozilla supports multi-column layouts, Opera supports media queries, Prince supports cross-references and Safari supports borders and backgrounds. A few years from now, I think a select group of CSS3 modules will be interoperably supported in all browsers.

 > Why is CSS such a good idea but a pain to use?
 > by rar
 >
 > CSS is clearly very useful for separating style from content. But
 > apparently people tend to have problems when using it for layouts.
 > Would you say this is because people have not yet understood how to
 > properly do layout in CSS, or is it CSS that is lacking in this
 > area? What can be done to improve the situation? --- Would the web
 > benefit from HTML and CSS being complemented with some kind of
 > "layout language"?

I think layout and style should be tackled by the same language and the two are intertwined. Trying to split the two is like splitting the HTML specification in two, one specification describing inline elements and the other describing block elements. It's not worth the effort.

I think CSS is capable of describing beautiful and scalable layouts. The CSS Zen Garden has been a eye-opening showcase of what is possible today. If MS IE had supported CSS tables, another set of layouts would have been possible. So, there is still lots of potential in the existing CSS specifications which should be the next milestone. Beyond that, the CSS Working Group has started work on a new CSS3 module for advanced layout. Feedback is welcome.

 > CSS Evolution!
 > by eieken
 >
 > Is the wave of webpages designed completely in CSS what you
 > intially intended when you came up with CSS? Do you see that
 > changing? Is that good or bad?

I saw a clear need for a web style sheet language when proposing CSS in 1994. I also wanted CSS to fully describe the presentation of a web pages -- not just add some styling. All in all, I think it has turned out quite well. It has taken longer than I expected, but the scale -- due to the growth of the web -- is more than anyone could imagine.

I used "I" too many times in the previous paragraph. It's important to realize that CSS is a community effort rather that one man's work. Bert Bos joined me early and we worked out the initial designs on a whiteboard during the summer of 1995. The www-style mailing lists and the W3C CSS Working Group have also been crucial in ensuring the success of CSS.

If you're interested in the history of web style sheets, you'll find plenty of material in my PhD thesis on the subject.

 > Two questions (cut to 1.5 by editor Roblimo)
 > by Dolda2000

 > If you were allowed (perhaps by court order, which wouldn't be
 > unthinkable) to force Microsoft to do one (1) change in Internet
 > Explorer, what would that be?

I would force them to support one (1) single web page before shipping IE7, namely Acid2. By using a tiny amount of resources to get Acid2 right, Microsoft can save web designers and users endless amounts of frustration in the future. It would also be an honorable thing to do. This is what Microsoft's W3C representative wrote in 1998:

Microsoft has a deep commitment to working with the W3C on HTML and CSS. We have the first commercial implementation of HTML4, we were the first vendor anywhere to implement even portions of CSS, and we have put a tremendous amount of energy into seeing CSS mature to Level 2. We are still committed to complete implementations of the Recommendations of the W3C in this area (CSS and HTML and the DOM).

May I have one (1) more change? Please? Then I would make IE7 support TrueType downloadable fonts. Microsoft's record in fonts isn't that bad. They made their core fonts available for anyone to use, and IE supports downloadable fonts. Unfortunately, only the proprietary EOT format is supported. A few lines of code would be sufficient to support zipped TrueType fonts as well, and this would unleash a new wave of typography on the web. (To protect yourself, make sure you use a browser where author style sheets can be turned off — Shift-G in Opera). > As a bonus question: What do you think of Slashdot's CSS? ;)

The new design looks great! The style sheets behind the scene are more complex than what the average web page needs. But, we wouldn't expect anything average from Slashdot, would we?

> 6)  Opera
 > by taskforce
 >
 > Opera 9.0 seems to offer a lot of decent additions to Opera's
 > standards pool. How satisfied are you personally with the work the
 > team has done on implementing standards, and is there anything in
 > there you feel is superflous and anything you would have preferred
 > to see which wasn't in there?

I'm very proud of the standards support in Opera 9. Acid2 is an obvious favorite of mine and seeing that smiley face makes me very happy.

Among the more experimental features is support for Audio in HTML5. Web applications can now make sounds in a sensible way! Combined with the canvas element, developers can create Flash-like content without resorting to a proprietary format.

Having support for Bittorrent is also great. From a technical point of view, it makes much sense. Also, it's a political statement of sorts.

During the development of Opera9. Geir Ivarsøy, who founded Opera with Jon von Tetzchner, died after fighting cancer for years. Geir did a spectacular initial CSS implementation in Opera, thus convincing me to join the company. In music, the 9th is legendary. Beethoven, Schubert, Bruckner and Mahler all did 9 symphonies. Opera 9 was Geir's last symphony.

> Included styles, aliases
 > by Spy der Mann
 >
 > I always wanted to have "included" substyles or "aliases" in my
 > CSS definition, to save redundancy.
 >
 > (For includes)
 >
 >     .class1 { color:#ff0000; }
 >     .class2 { background-color:#ffffff; }
 >     .class3 { include:class1,class2;font-weight:bold; }
 >
 > (For aliases)
 >
 >     @alias color1 #ff0000;
 >     @alias color2 #ffffff;
 >     @alias default_image url('/img/image1.jpg');
 >
 >     .class1 { color:color1; }
 >     .class2 { background-image:default_image;background-color:co lor2; }
 >
 > This way we could change colors or images for a whole webpage
 > by editing a reduced number of lines.
 >
 > Had you considered any of these ideas in the past? If so,
 > why were they rejected?

Yes, aliases and constants have been considered. As David Wheeler noted, "Any problem in computer science can be solved with another layer of indirection."

CSS is already an indirection. Instead of putting properties and values directly on elements, it associates properties and values with selectors. What you (and others) are proposing is to add another layer of indirection. By doing so, one could possible write shorter, more manageable style sheets. However, there are also some downsides. It requires a new syntactic construct (@alias) and implementations must be able to remember a list of aliases. What if aliases are defined in one style sheet and referenced in another -- should that work? If so, what if the first style sheet isn't available?

For CSS1, the downsides of aliases were considered more significant than the benefits.

 > Definition of pixel
 > by Sara Chan
 >
 > The word pixel meant "picture element", but CSS redefined it
 >to mean something quite different (a particular subtended angle
 >of view [w3.org]). This causes confusion: CSS pixels are not pixels.
 >(Indeed, I have seen misinformed comments on Slashdot due to
 >that confusion.)
 >
 > My question is this: why call the subtended angle a "pixel", instead of
 >something else (e.g. "subangle")? If CSS wanted to use the subtended
 >angle for something, that is fine, but calling it a pixel seems to follow
 >the approach of Humpty Dumpty "When I use a word, it means just
 >what I choose it to mean".

In most cases, a CSS pixel will be equal to a device pixel. But, as you point out, the definition of a CSS pixel will sometimes be different. For example, on a laser printer, one CSS pixel can be equal to 3x3 device pixels to avoid printing illegibly small text and images. I don't recall anyone ever proposing another name for it. Subangle? Personally, I think most people would prefer the pragmatic "px" to the non-intuitive "sa".

> Vertical CSS Support
 > by infestedsenses
 >
 > As a developer who works with CSS every day, I find one
 > complication that continues to bother me in my daily work.
 > Support for CSS has always been good on the horizontal scope,
 > but vertical positioning has always been quite complicated.
 > Alone the procedure to affix a footer to the bottom of a screen
 > in dependance of the amount of content is unnecessarily difficult,
 > spawning hackish solutions such as "footerStickAlt"
 > [themaninblue.com]. Centering an object in the dead center of a
 > page also requires strange procedures such as this one [wpdfd.com],
 > which still aren't ideal (try making the viewport really small). The old
 > table method provided much easier methods for this. What are your
 > thoughts on this and do you see improvement following in future
 > CSS revisions?

Indeed, the CSS formatting model allows more control horizontally than vertically. This is due to (typically) having a known width, but an unknown height. As such, the height is harder to deal with.

However, CSS2 fixed positioning allows you to place content relative to the viewport (which is CSS-speak for window) instead of the document. For example, by setting position: fixed; bottom: 0 on an element, it will stick to the bottom. This works in Opera, Safari and Mozilla-based browsers. IE6 doesn't support it, however. It remains to be seen if IE7 will support it.

> About Microsoft...
 > by Chabil Ha'
 >
 > With MS's next browser release (IE 7), you mentioned in other
 > interviews that their decision to not supprt CSS2 was more a political
 > decision than a mechanical one. Aside from their obvious desire to
 > dominate the world, what politics do you think are in play that make
 > them not want to conform to the standard, and what do you think would
 > change that landscape so that they would have some initiative to
 > fully support it?

Great question. It's quite clear that Microsoft has the resources and talent to support CSS2 fully in IE and that plenty of people have reminded them why this is important. So, why don't they do it? The fundamental reason, I believe, is that standards don't benefit monopolists. Accepted, well-functioning, standards lower the barrier of entry to a market, and is therefore a threat to a monopolist.

From that perspective, it makes sense to leave CSS2 half-implemented. You can claim support (and many journalists will believe you), and you also ensure that no-one can use the unimplemented (or worse: buggily implemented) features of the standard. The only way to change the equation is to remind Microsoft how embarrassing it is to offer a sub-standard browser. And to use better browsers.

Another reason for not making a IE too good is that it will compete with Windows. A modern browser is an application platform; the combination of HTML, JavaScript, CSS and DOM allows developers to target the web instead of Windows, Linux, or Mac.

> From linvir
 > How long since you last used Linux?

I'm using it right now. Ubuntu on a IBM Thinkpad X41 is the environment I live in. Ubuntu rocks -- especially with Opera on top! (And Emacs right underneath.)

 > From Rob T Firefly (844560)
 > Why the curly brackets?

The initial CSS proposal didn't use them, instead relying on newlines to separate statements. TimBL didn't really like that and I therefore borrowed the curly braces from the C programming language. The syntax for comments came along as well. I think it works quite well.

 > why not XML?
 > by slashdot.org
 > Simple question (hopefully simple answer ;-)): why
 > did you not use XML?

The simple answer is that the development of CSS preceded XML by a year or so. However, if XML had been available, would we have used it? Probably not. And I suspect Brendan Eich of JavaScript fame would answer the same way on behalf of his language.

XML is a great syntax for structured data, but not suitable for all languages. Still, I think the SGML-based syntax for the FOSI style sheet language.

 > Padding
 > by Anonymous Coward

 > Why was the decision made to make padding apply outside
 > of the width of a 'box', rather than inside, which would seem
 > to make more sense?

It makes sense in some situations, but not in others. For example, when a child element is set to width: 100%, I don't think it should cover the padding of its parent. The box-sizing property in CSS3 addresses this issue. Ideally, the issue should have been addressed earlier, though.

> by nuzak

 > why not float:

 > DSSSL had this sort of thing solved before HTML even existed,
 > let alone CSS. But scheme is too scary and icky, and the W3C
 > believes in a principle of least power, so CSS has to be fully declarative,
 > static, and crippled until patched later.

You're wrong about DSSSL -- it didn't support floating text (as in having text wrap around images) at all. And the DSSSL specification only became publically available around 1996, years after HTML.

> by MagicM

 > How frustrating is it to write a specification knowing
 > that you're at the browser vendors' mercy?

That's part of the game. I don't think any specification has a birthright to be fully supported by all browsers. There should be healthy competition between different specifications. I believe simple, author-friendly specifications will prevail in this environment.

Microformats are another way of developing new formats. Instead of having to convince browser vendors to support your favorite specification, microformats add semantics to HTML through the CLASS attribute. And style it with CSS.

> New standards
 > by iamsure
 >
 > In your work at Opera, you have clearly paved a path that includes
 > going beyond the W3C standards. Whether it is WhatWG
 > implementations, or new functionality specific to Opera (2dgame),
 > you are pushing into new territory. Can you explain why W3C isn't
 > sufficient, and why efforts at Opera to expand beyond the standards
 > differ from Microsoft's embrace/extend model?

It's a fair question. The WhatWG was set up when it seemed as if W3C didn't care much about browsers anymore. That has definitely changed and work items from WhatWG are now channeled into W3C (e.g., XMLHttpRequest).

At Opera, we sometimes include experimental features before they have been standardized. When this happens they are labeled as such, but we still try to document them. For example, we support some Opera-only CSS properties for XML. If these features gain traction, we are happy to work with other organizations to standardize them. If they don't become popular, the features will most likely disappear.

 > Beyond HTML
 > by pr1000

 > How far can CSS be taken beyond the web page--that is,
 > have generalized or non-web specific features for such things
 > as page formatting or type setting? Do you plan/wish/hope to
 > take it farther than it currently is?

Yes, I think it's possible to take CSS further in several directions. I'm eager to see CSS being used in paper-based publishing and I joined the board of YesLogic — which makes the Prince XML to PDF converter — to make sure they added my favorite features. Bert and I used Prince to generate PDF from HTML and CSS sources for the third edition of our book. W3C just published a new Working Draft which describes features for printing, e.g., footnotes, cross-references, and even generated indexes.

For mobile units, I think Media Queries will be important. For example, they can express that large images should not be sent to mobile devices.

Another great opportunity for CSS is Web Applications. Just like documents, applications need to be styled and CSS is an intrinsic component of AJAX. The "AJAX" name sounds great, but allow me to propose a few alternate spellings that I find more accurate:

• AJACX: Asynchronous JavaScript, CSS and XMLHttpRequest
• ADJACS: Asynchronous DOM, JavaScript and CSS
• ADHJACS: Asynchronous DOM, HTML, JavaScript and CSS
• AJAHCS: Asynchronous JavaScript, HTML and CSS
• AJACS: Asynchronous JavaScript, HTML and CSS

Opera, Mozilla and Safari developers are collaborating in the WHAT WG and in W3C to make sure we have interoperable specifications for AJAX. I mean, ADHJACS.

 > by crush

 > Is the difficulty of producing a layout that consists of
 > three or more columns of equal height justification for
 > adding some new feature to the specification to make this easier?

I don't think so. CSS2 defines a table layout that can be used for this purpose. The problem is, and I'm repeating myself here, that the dominant browser doesn't support it. Adding yet more features to the specification wouldn't help.

 > How come, we um, lie?

Right. My name is, um, a bit troublesome to pronounce in English. But I'm a nice person who generally tells the truth. I often tell non-Norwegians that my first name is pronounced "howcome". That's close, but not quite. It does make for a great email address like howcome@opera.com, though.

So I may be a Lie, but I'm just a little white one :-)

You submitted questions for Håkon Wium Lie on June 20. Today we have his answers, not only to the (+5 moderated) questions we sent him, but to a bunch of others he thought would also be interesting to answer.

 > Where... by bcat24
 >
 > Do you think the W3C development process is too slow? I know that
 > you guys want everything to be perfect, but it seems to take far
 > longer than necessary. CSS 3 shows promise and I wouldn't want it
 > to die a slow death in standardization.

No, I don't think W3C is too slow. W3C isn't the bottleneck, browsers are. The dominant browser on the web hasn't been updated for years, and it doesn't make sense for specifications to get too far ahead. Rather, the CSS Working Group in W3C has focused on specification maintenance and achieving interoperability between implementations. This work is not so glamorous and some people — even within W3C — would prefer if they concentrate on new specifications. However, I think the focus on interoperability (which has resulted in CSS 2.1) has been crucial to the success of CSS.

CSS3 is a set of specifications that are developed more or less independently of each other. The best way to push a specification forward is to implement it. In the past year, we've seen some encouraging CSS3 implementations come along. For example, Mozilla supports multi-column layouts, Opera supports media queries, Prince supports cross-references and Safari supports borders and backgrounds. A few years from now, I think a select group of CSS3 modules will be interoperably supported in all browsers.

 > Why is CSS such a good idea but a pain to use?
 > by rar
 >
 > CSS is clearly very useful for separating style from content. But
 > apparently people tend to have problems when using it for layouts.
 > Would you say this is because people have not yet understood how to
 > properly do layout in CSS, or is it CSS that is lacking in this
 > area? What can be done to improve the situation? --- Would the web
 > benefit from HTML and CSS being complemented with some kind of
 > "layout language"?

I think layout and style should be tackled by the same language and the two are intertwined. Trying to split the two is like splitting the HTML specification in two, one specification describing inline elements and the other describing block elements. It's not worth the effort.

I think CSS is capable of describing beautiful and scalable layouts. The CSS Zen Garden has been a eye-opening showcase of what is possible today. If MS IE had supported CSS tables, another set of layouts would have been possible. So, there is still lots of potential in the existing CSS specifications which should be the next milestone. Beyond that, the CSS Working Group has started work on a new CSS3 module for advanced layout. Feedback is welcome.

 > CSS Evolution!
 > by eieken
 >
 > Is the wave of webpages designed completely in CSS what you
 > intially intended when you came up with CSS? Do you see that
 > changing? Is that good or bad?

I saw a clear need for a web style sheet language when proposing CSS in 1994. I also wanted CSS to fully describe the presentation of a web pages -- not just add some styling. All in all, I think it has turned out quite well. It has taken longer than I expected, but the scale -- due to the growth of the web -- is more than anyone could imagine.

I used "I" too many times in the previous paragraph. It's important to realize that CSS is a community effort rather that one man's work. Bert Bos joined me early and we worked out the initial designs on a whiteboard during the summer of 1995. The www-style mailing lists and the W3C CSS Working Group have also been crucial in ensuring the success of CSS.

If you're interested in the history of web style sheets, you'll find plenty of material in my PhD thesis on the subject.

 > Two questions (cut to 1.5 by editor Roblimo)
 > by Dolda2000

 > If you were allowed (perhaps by court order, which wouldn't be
 > unthinkable) to force Microsoft to do one (1) change in Internet
 > Explorer, what would that be?

I would force them to support one (1) single web page before shipping IE7, namely Acid2. By using a tiny amount of resources to get Acid2 right, Microsoft can save web designers and users endless amounts of frustration in the future. It would also be an honorable thing to do. This is what Microsoft's W3C representative wrote in 1998:

Microsoft has a deep commitment to working with the W3C on HTML and CSS. We have the first commercial implementation of HTML4, we were the first vendor anywhere to implement even portions of CSS, and we have put a tremendous amount of energy into seeing CSS mature to Level 2. We are still committed to complete implementations of the Recommendations of the W3C in this area (CSS and HTML and the DOM).

May I have one (1) more change? Please? Then I would make IE7 support TrueType downloadable fonts. Microsoft's record in fonts isn't that bad. They made their core fonts available for anyone to use, and IE supports downloadable fonts. Unfortunately, only the proprietary EOT format is supported. A few lines of code would be sufficient to support zipped TrueType fonts as well, and this would unleash a new wave of typography on the web. (To protect yourself, make sure you use a browser where author style sheets can be turned off — Shift-G in Opera). > As a bonus question: What do you think of Slashdot's CSS? ;)

The new design looks great! The style sheets behind the scene are more complex than what the average web page needs. But, we wouldn't expect anything average from Slashdot, would we?

> 6)  Opera
 > by taskforce
 >
 > Opera 9.0 seems to offer a lot of decent additions to Opera's
 > standards pool. How satisfied are you personally with the work the
 > team has done on implementing standards, and is there anything in
 > there you feel is superflous and anything you would have preferred
 > to see which wasn't in there?

I'm very proud of the standards support in Opera 9. Acid2 is an obvious favorite of mine and seeing that smiley face makes me very happy.

Among the more experimental features is support for Audio in HTML5. Web applications can now make sounds in a sensible way! Combined with the canvas element, developers can create Flash-like content without resorting to a proprietary format.

Having support for Bittorrent is also great. From a technical point of view, it makes much sense. Also, it's a political statement of sorts.

During the development of Opera9. Geir Ivarsøy, who founded Opera with Jon von Tetzchner, died after fighting cancer for years. Geir did a spectacular initial CSS implementation in Opera, thus convincing me to join the company. In music, the 9th is legendary. Beethoven, Schubert, Bruckner and Mahler all did 9 symphonies. Opera 9 was Geir's last symphony.

> Included styles, aliases
 > by Spy der Mann
 >
 > I always wanted to have "included" substyles or "aliases" in my
 > CSS definition, to save redundancy.
 >
 > (For includes)
 >
 >     .class1 { color:#ff0000; }
 >     .class2 { background-color:#ffffff; }
 >     .class3 { include:class1,class2;font-weight:bold; }
 >
 > (For aliases)
 >
 >     @alias color1 #ff0000;
 >     @alias color2 #ffffff;
 >     @alias default_image url('/img/image1.jpg');
 >
 >     .class1 { color:color1; }
 >     .class2 { background-image:default_image;background-color:co lor2; }
 >
 > This way we could change colors or images for a whole webpage
 > by editing a reduced number of lines.
 >
 > Had you considered any of these ideas in the past? If so,
 > why were they rejected?

Yes, aliases and constants have been considered. As David Wheeler noted, "Any problem in computer science can be solved with another layer of indirection."

CSS is already an indirection. Instead of putting properties and values directly on elements, it associates properties and values with selectors. What you (and others) are proposing is to add another layer of indirection. By doing so, one could possible write shorter, more manageable style sheets. However, there are also some downsides. It requires a new syntactic construct (@alias) and implementations must be able to remember a list of aliases. What if aliases are defined in one style sheet and referenced in another -- should that work? If so, what if the first style sheet isn't available?

For CSS1, the downsides of aliases were considered more significant than the benefits.

 > Definition of pixel
 > by Sara Chan
 >
 > The word pixel meant "picture element", but CSS redefined it
 >to mean something quite different (a particular subtended angle
 >of view [w3.org]). This causes confusion: CSS pixels are not pixels.
 >(Indeed, I have seen misinformed comments on Slashdot due to
 >that confusion.)
 >
 > My question is this: why call the subtended angle a "pixel", instead of
 >something else (e.g. "subangle")? If CSS wanted to use the subtended
 >angle for something, that is fine, but calling it a pixel seems to follow
 >the approach of Humpty Dumpty "When I use a word, it means just
 >what I choose it to mean".

In most cases, a CSS pixel will be equal to a device pixel. But, as you point out, the definition of a CSS pixel will sometimes be different. For example, on a laser printer, one CSS pixel can be equal to 3x3 device pixels to avoid printing illegibly small text and images. I don't recall anyone ever proposing another name for it. Subangle? Personally, I think most people would prefer the pragmatic "px" to the non-intuitive "sa".

> Vertical CSS Support
 > by infestedsenses
 >
 > As a developer who works with CSS every day, I find one
 > complication that continues to bother me in my daily work.
 > Support for CSS has always been good on the horizontal scope,
 > but vertical positioning has always been quite complicated.
 > Alone the procedure to affix a footer to the bottom of a screen
 > in dependance of the amount of content is unnecessarily difficult,
 > spawning hackish solutions such as "footerStickAlt"
 > [themaninblue.com]. Centering an object in the dead center of a
 > page also requires strange procedures such as this one [wpdfd.com],
 > which still aren't ideal (try making the viewport really small). The old
 > table method provided much easier methods for this. What are your
 > thoughts on this and do you see improvement following in future
 > CSS revisions?

Indeed, the CSS formatting model allows more control horizontally than vertically. This is due to (typically) having a known width, but an unknown height. As such, the height is harder to deal with.

However, CSS2 fixed positioning allows you to place content relative to the viewport (which is CSS-speak for window) instead of the document. For example, by setting position: fixed; bottom: 0 on an element, it will stick to the bottom. This works in Opera, Safari and Mozilla-based browsers. IE6 doesn't support it, however. It remains to be seen if IE7 will support it.

> About Microsoft...
 > by Chabil Ha'
 >
 > With MS's next browser release (IE 7), you mentioned in other
 > interviews that their decision to not supprt CSS2 was more a political
 > decision than a mechanical one. Aside from their obvious desire to
 > dominate the world, what politics do you think are in play that make
 > them not want to conform to the standard, and what do you think would
 > change that landscape so that they would have some initiative to
 > fully support it?

Great question. It's quite clear that Microsoft has the resources and talent to support CSS2 fully in IE and that plenty of people have reminded them why this is important. So, why don't they do it? The fundamental reason, I believe, is that standards don't benefit monopolists. Accepted, well-functioning, standards lower the barrier of entry to a market, and is therefore a threat to a monopolist.

From that perspective, it makes sense to leave CSS2 half-implemented. You can claim support (and many journalists will believe you), and you also ensure that no-one can use the unimplemented (or worse: buggily implemented) features of the standard. The only way to change the equation is to remind Microsoft how embarrassing it is to offer a sub-standard browser. And to use better browsers.

Another reason for not making a IE too good is that it will compete with Windows. A modern browser is an application platform; the combination of HTML, JavaScript, CSS and DOM allows developers to target the web instead of Windows, Linux, or Mac.

> From linvir
 > How long since you last used Linux?

I'm using it right now. Ubuntu on a IBM Thinkpad X41 is the environment I live in. Ubuntu rocks -- especially with Opera on top! (And Emacs right underneath.)

 > From Rob T Firefly (844560)
 > Why the curly brackets?

The initial CSS proposal didn't use them, instead relying on newlines to separate statements. TimBL didn't really like that and I therefore borrowed the curly braces from the C programming language. The syntax for comments came along as well. I think it works quite well.

 > why not XML?
 > by slashdot.org
 > Simple question (hopefully simple answer ;-)): why
 > did you not use XML?

The simple answer is that the development of CSS preceded XML by a year or so. However, if XML had been available, would we have used it? Probably not. And I suspect Brendan Eich of JavaScript fame would answer the same way on behalf of his language.

XML is a great syntax for structured data, but not suitable for all languages. Still, I think the SGML-based syntax for the FOSI style sheet language.

 > Padding
 > by Anonymous Coward

 > Why was the decision made to make padding apply outside
 > of the width of a 'box', rather than inside, which would seem
 > to make more sense?

It makes sense in some situations, but not in others. For example, when a child element is set to width: 100%, I don't think it should cover the padding of its parent. The box-sizing property in CSS3 addresses this issue. Ideally, the issue should have been addressed earlier, though.

> by nuzak

 > why not float:

 > DSSSL had this sort of thing solved before HTML even existed,
 > let alone CSS. But scheme is too scary and icky, and the W3C
 > believes in a principle of least power, so CSS has to be fully declarative,
 > static, and crippled until patched later.

You're wrong about DSSSL -- it didn't support floating text (as in having text wrap around images) at all. And the DSSSL specification only became publically available around 1996, years after HTML.

> by MagicM

 > How frustrating is it to write a specification knowing
 > that you're at the browser vendors' mercy?

That's part of the game. I don't think any specification has a birthright to be fully supported by all browsers. There should be healthy competition between different specifications. I believe simple, author-friendly specifications will prevail in this environment.

Microformats are another way of developing new formats. Instead of having to convince browser vendors to support your favorite specification, microformats add semantics to HTML through the CLASS attribute. And style it with CSS.

> New standards
 > by iamsure
 >
 > In your work at Opera, you have clearly paved a path that includes
 > going beyond the W3C standards. Whether it is WhatWG
 > implementations, or new functionality specific to Opera (2dgame),
 > you are pushing into new territory. Can you explain why W3C isn't
 > sufficient, and why efforts at Opera to expand beyond the standards
 > differ from Microsoft's embrace/extend model?

It's a fair question. The WhatWG was set up when it seemed as if W3C didn't care much about browsers anymore. That has definitely changed and work items from WhatWG are now channeled into W3C (e.g., XMLHttpRequest).

At Opera, we sometimes include experimental features before they have been standardized. When this happens they are labeled as such, but we still try to document them. For example, we support some Opera-only CSS properties for XML. If these features gain traction, we are happy to work with other organizations to standardize them. If they don't become popular, the features will most likely disappear.

 > Beyond HTML
 > by pr1000

 > How far can CSS be taken beyond the web page--that is,
 > have generalized or non-web specific features for such things
 > as page formatting or type setting? Do you plan/wish/hope to
 > take it farther than it currently is?

Yes, I think it's possible to take CSS further in several directions. I'm eager to see CSS being used in paper-based publishing and I joined the board of YesLogic — which makes the Prince XML to PDF converter — to make sure they added my favorite features. Bert and I used Prince to generate PDF from HTML and CSS sources for the third edition of our book. W3C just published a new Working Draft which describes features for printing, e.g., footnotes, cross-references, and even generated indexes.

For mobile units, I think Media Queries will be important. For example, they can express that large images should not be sent to mobile devices.

Another great opportunity for CSS is Web Applications. Just like documents, applications need to be styled and CSS is an intrinsic component of AJAX. The "AJAX" name sounds great, but allow me to propose a few alternate spellings that I find more accurate:

• AJACX: Asynchronous JavaScript, CSS and XMLHttpRequest
• ADJACS: Asynchronous DOM, JavaScript and CSS
• ADHJACS: Asynchronous DOM, HTML, JavaScript and CSS
• AJAHCS: Asynchronous JavaScript, HTML and CSS
• AJACS: Asynchronous JavaScript, HTML and CSS

Opera, Mozilla and Safari developers are collaborating in the WHAT WG and in W3C to make sure we have interoperable specifications for AJAX. I mean, ADHJACS.

 > by crush

 > Is the difficulty of producing a layout that consists of
 > three or more columns of equal height justification for
 > adding some new feature to the specification to make this easier?

I don't think so. CSS2 defines a table layout that can be used for this purpose. The problem is, and I'm repeating myself here, that the dominant browser doesn't support it. Adding yet more features to the specification wouldn't help.

 > How come, we um, lie?

Right. My name is, um, a bit troublesome to pronounce in English. But I'm a nice person who generally tells the truth. I often tell non-Norwegians that my first name is pronounced "howcome". That's close, but not quite. It does make for a great email address like howcome@opera.com, though.

So I may be a Lie, but I'm just a little white one :-)

You submitted questions for Håkon Wium Lie on June 20. Today we have his answers, not only to the (+5 moderated) questions we sent him, but to a bunch of others he thought would also be interesting to answer.

 > Where... by bcat24
 >
 > Do you think the W3C development process is too slow? I know that
 > you guys want everything to be perfect, but it seems to take far
 > longer than necessary. CSS 3 shows promise and I wouldn't want it
 > to die a slow death in standardization.

No, I don't think W3C is too slow. W3C isn't the bottleneck, browsers are. The dominant browser on the web hasn't been updated for years, and it doesn't make sense for specifications to get too far ahead. Rather, the CSS Working Group in W3C has focused on specification maintenance and achieving interoperability between implementations. This work is not so glamorous and some people — even within W3C — would prefer if they concentrate on new specifications. However, I think the focus on interoperability (which has resulted in CSS 2.1) has been crucial to the success of CSS.

CSS3 is a set of specifications that are developed more or less independently of each other. The best way to push a specification forward is to implement it. In the past year, we've seen some encouraging CSS3 implementations come along. For example, Mozilla supports multi-column layouts, Opera supports media queries, Prince supports cross-references and Safari supports borders and backgrounds. A few years from now, I think a select group of CSS3 modules will be interoperably supported in all browsers.

 > Why is CSS such a good idea but a pain to use?
 > by rar
 >
 > CSS is clearly very useful for separating style from content. But
 > apparently people tend to have problems when using it for layouts.
 > Would you say this is because people have not yet understood how to
 > properly do layout in CSS, or is it CSS that is lacking in this
 > area? What can be done to improve the situation? --- Would the web
 > benefit from HTML and CSS being complemented with some kind of
 > "layout language"?

I think layout and style should be tackled by the same language and the two are intertwined. Trying to split the two is like splitting the HTML specification in two, one specification describing inline elements and the other describing block elements. It's not worth the effort.

I think CSS is capable of describing beautiful and scalable layouts. The CSS Zen Garden has been a eye-opening showcase of what is possible today. If MS IE had supported CSS tables, another set of layouts would have been possible. So, there is still lots of potential in the existing CSS specifications which should be the next milestone. Beyond that, the CSS Working Group has started work on a new CSS3 module for advanced layout. Feedback is welcome.

 > CSS Evolution!
 > by eieken
 >
 > Is the wave of webpages designed completely in CSS what you
 > intially intended when you came up with CSS? Do you see that
 > changing? Is that good or bad?

I saw a clear need for a web style sheet language when proposing CSS in 1994. I also wanted CSS to fully describe the presentation of a web pages -- not just add some styling. All in all, I think it has turned out quite well. It has taken longer than I expected, but the scale -- due to the growth of the web -- is more than anyone could imagine.

I used "I" too many times in the previous paragraph. It's important to realize that CSS is a community effort rather that one man's work. Bert Bos joined me early and we worked out the initial designs on a whiteboard during the summer of 1995. The www-style mailing lists and the W3C CSS Working Group have also been crucial in ensuring the success of CSS.

If you're interested in the history of web style sheets, you'll find plenty of material in my PhD thesis on the subject.

 > Two questions (cut to 1.5 by editor Roblimo)
 > by Dolda2000

 > If you were allowed (perhaps by court order, which wouldn't be
 > unthinkable) to force Microsoft to do one (1) change in Internet
 > Explorer, what would that be?

I would force them to support one (1) single web page before shipping IE7, namely Acid2. By using a tiny amount of resources to get Acid2 right, Microsoft can save web designers and users endless amounts of frustration in the future. It would also be an honorable thing to do. This is what Microsoft's W3C representative wrote in 1998:

Microsoft has a deep commitment to working with the W3C on HTML and CSS. We have the first commercial implementation of HTML4, we were the first vendor anywhere to implement even portions of CSS, and we have put a tremendous amount of energy into seeing CSS mature to Level 2. We are still committed to complete implementations of the Recommendations of the W3C in this area (CSS and HTML and the DOM).

May I have one (1) more change? Please? Then I would make IE7 support TrueType downloadable fonts. Microsoft's record in fonts isn't that bad. They made their core fonts available for anyone to use, and IE supports downloadable fonts. Unfortunately, only the proprietary EOT format is supported. A few lines of code would be sufficient to support zipped TrueType fonts as well, and this would unleash a new wave of typography on the web. (To protect yourself, make sure you use a browser where author style sheets can be turned off — Shift-G in Opera). > As a bonus question: What do you think of Slashdot's CSS? ;)

The new design looks great! The style sheets behind the scene are more complex than what the average web page needs. But, we wouldn't expect anything average from Slashdot, would we?

> 6)  Opera
 > by taskforce
 >
 > Opera 9.0 seems to offer a lot of decent additions to Opera's
 > standards pool. How satisfied are you personally with the work the
 > team has done on implementing standards, and is there anything in
 > there you feel is superflous and anything you would have preferred
 > to see which wasn't in there?

I'm very proud of the standards support in Opera 9. Acid2 is an obvious favorite of mine and seeing that smiley face makes me very happy.

Among the more experimental features is support for Audio in HTML5. Web applications can now make sounds in a sensible way! Combined with the canvas element, developers can create Flash-like content without resorting to a proprietary format.

Having support for Bittorrent is also great. From a technical point of view, it makes much sense. Also, it's a political statement of sorts.

During the development of Opera9. Geir Ivarsøy, who founded Opera with Jon von Tetzchner, died after fighting cancer for years. Geir did a spectacular initial CSS implementation in Opera, thus convincing me to join the company. In music, the 9th is legendary. Beethoven, Schubert, Bruckner and Mahler all did 9 symphonies. Opera 9 was Geir's last symphony.

> Included styles, aliases
 > by Spy der Mann
 >
 > I always wanted to have "included" substyles or "aliases" in my
 > CSS definition, to save redundancy.
 >
 > (For includes)
 >
 >     .class1 { color:#ff0000; }
 >     .class2 { background-color:#ffffff; }
 >     .class3 { include:class1,class2;font-weight:bold; }
 >
 > (For aliases)
 >
 >     @alias color1 #ff0000;
 >     @alias color2 #ffffff;
 >     @alias default_image url('/img/image1.jpg');
 >
 >     .class1 { color:color1; }
 >     .class2 { background-image:default_image;background-color:co lor2; }
 >
 > This way we could change colors or images for a whole webpage
 > by editing a reduced number of lines.
 >
 > Had you considered any of these ideas in the past? If so,
 > why were they rejected?

Yes, aliases and constants have been considered. As David Wheeler noted, "Any problem in computer science can be solved with another layer of indirection."

CSS is already an indirection. Instead of putting properties and values directly on elements, it associates properties and values with selectors. What you (and others) are proposing is to add another layer of indirection. By doing so, one could possible write shorter, more manageable style sheets. However, there are also some downsides. It requires a new syntactic construct (@alias) and implementations must be able to remember a list of aliases. What if aliases are defined in one style sheet and referenced in another -- should that work? If so, what if the first style sheet isn't available?

For CSS1, the downsides of aliases were considered more significant than the benefits.

 > Definition of pixel
 > by Sara Chan
 >
 > The word pixel meant "picture element", but CSS redefined it
 >to mean something quite different (a particular subtended angle
 >of view [w3.org]). This causes confusion: CSS pixels are not pixels.
 >(Indeed, I have seen misinformed comments on Slashdot due to
 >that confusion.)
 >
 > My question is this: why call the subtended angle a "pixel", instead of
 >something else (e.g. "subangle")? If CSS wanted to use the subtended
 >angle for something, that is fine, but calling it a pixel seems to follow
 >the approach of Humpty Dumpty "When I use a word, it means just
 >what I choose it to mean".

In most cases, a CSS pixel will be equal to a device pixel. But, as you point out, the definition of a CSS pixel will sometimes be different. For example, on a laser printer, one CSS pixel can be equal to 3x3 device pixels to avoid printing illegibly small text and images. I don't recall anyone ever proposing another name for it. Subangle? Personally, I think most people would prefer the pragmatic "px" to the non-intuitive "sa".

> Vertical CSS Support
 > by infestedsenses
 >
 > As a developer who works with CSS every day, I find one
 > complication that continues to bother me in my daily work.
 > Support for CSS has always been good on the horizontal scope,
 > but vertical positioning has always been quite complicated.
 > Alone the procedure to affix a footer to the bottom of a screen
 > in dependance of the amount of content is unnecessarily difficult,
 > spawning hackish solutions such as "footerStickAlt"
 > [themaninblue.com]. Centering an object in the dead center of a
 > page also requires strange procedures such as this one [wpdfd.com],
 > which still aren't ideal (try making the viewport really small). The old
 > table method provided much easier methods for this. What are your
 > thoughts on this and do you see improvement following in future
 > CSS revisions?

Indeed, the CSS formatting model allows more control horizontally than vertically. This is due to (typically) having a known width, but an unknown height. As such, the height is harder to deal with.

However, CSS2 fixed positioning allows you to place content relative to the viewport (which is CSS-speak for window) instead of the document. For example, by setting position: fixed; bottom: 0 on an element, it will stick to the bottom. This works in Opera, Safari and Mozilla-based browsers. IE6 doesn't support it, however. It remains to be seen if IE7 will support it.

> About Microsoft...
 > by Chabil Ha'
 >
 > With MS's next browser release (IE 7), you mentioned in other
 > interviews that their decision to not supprt CSS2 was more a political
 > decision than a mechanical one. Aside from their obvious desire to
 > dominate the world, what politics do you think are in play that make
 > them not want to conform to the standard, and what do you think would
 > change that landscape so that they would have some initiative to
 > fully support it?

Great question. It's quite clear that Microsoft has the resources and talent to support CSS2 fully in IE and that plenty of people have reminded them why this is important. So, why don't they do it? The fundamental reason, I believe, is that standards don't benefit monopolists. Accepted, well-functioning, standards lower the barrier of entry to a market, and is therefore a threat to a monopolist.

From that perspective, it makes sense to leave CSS2 half-implemented. You can claim support (and many journalists will believe you), and you also ensure that no-one can use the unimplemented (or worse: buggily implemented) features of the standard. The only way to change the equation is to remind Microsoft how embarrassing it is to offer a sub-standard browser. And to use better browsers.

Another reason for not making a IE too good is that it will compete with Windows. A modern browser is an application platform; the combination of HTML, JavaScript, CSS and DOM allows developers to target the web instead of Windows, Linux, or Mac.

> From linvir
 > How long since you last used Linux?

I'm using it right now. Ubuntu on a IBM Thinkpad X41 is the environment I live in. Ubuntu rocks -- especially with Opera on top! (And Emacs right underneath.)

 > From Rob T Firefly (844560)
 > Why the curly brackets?

The initial CSS proposal didn't use them, instead relying on newlines to separate statements. TimBL didn't really like that and I therefore borrowed the curly braces from the C programming language. The syntax for comments came along as well. I think it works quite well.

 > why not XML?
 > by slashdot.org
 > Simple question (hopefully simple answer ;-)): why
 > did you not use XML?

The simple answer is that the development of CSS preceded XML by a year or so. However, if XML had been available, would we have used it? Probably not. And I suspect Brendan Eich of JavaScript fame would answer the same way on behalf of his language.

XML is a great syntax for structured data, but not suitable for all languages. Still, I think the SGML-based syntax for the FOSI style sheet language.

 > Padding
 > by Anonymous Coward

 > Why was the decision made to make padding apply outside
 > of the width of a 'box', rather than inside, which would seem
 > to make more sense?

It makes sense in some situations, but not in others. For example, when a child element is set to width: 100%, I don't think it should cover the padding of its parent. The box-sizing property in CSS3 addresses this issue. Ideally, the issue should have been addressed earlier, though.

> by nuzak

 > why not float:

 > DSSSL had this sort of thing solved before HTML even existed,
 > let alone CSS. But scheme is too scary and icky, and the W3C
 > believes in a principle of least power, so CSS has to be fully declarative,
 > static, and crippled until patched later.

You're wrong about DSSSL -- it didn't support floating text (as in having text wrap around images) at all. And the DSSSL specification only became publically available around 1996, years after HTML.

> by MagicM

 > How frustrating is it to write a specification knowing
 > that you're at the browser vendors' mercy?

That's part of the game. I don't think any specification has a birthright to be fully supported by all browsers. There should be healthy competition between different specifications. I believe simple, author-friendly specifications will prevail in this environment.

Microformats are another way of developing new formats. Instead of having to convince browser vendors to support your favorite specification, microformats add semantics to HTML through the CLASS attribute. And style it with CSS.

> New standards
 > by iamsure
 >
 > In your work at Opera, you have clearly paved a path that includes
 > going beyond the W3C standards. Whether it is WhatWG
 > implementations, or new functionality specific to Opera (2dgame),
 > you are pushing into new territory. Can you explain why W3C isn't
 > sufficient, and why efforts at Opera to expand beyond the standards
 > differ from Microsoft's embrace/extend model?

It's a fair question. The WhatWG was set up when it seemed as if W3C didn't care much about browsers anymore. That has definitely changed and work items from WhatWG are now channeled into W3C (e.g., XMLHttpRequest).

At Opera, we sometimes include experimental features before they have been standardized. When this happens they are labeled as such, but we still try to document them. For example, we support some Opera-only CSS properties for XML. If these features gain traction, we are happy to work with other organizations to standardize them. If they don't become popular, the features will most likely disappear.

 > Beyond HTML
 > by pr1000

 > How far can CSS be taken beyond the web page--that is,
 > have generalized or non-web specific features for such things
 > as page formatting or type setting? Do you plan/wish/hope to
 > take it farther than it currently is?

Yes, I think it's possible to take CSS further in several directions. I'm eager to see CSS being used in paper-based publishing and I joined the board of YesLogic — which makes the Prince XML to PDF converter — to make sure they added my favorite features. Bert and I used Prince to generate PDF from HTML and CSS sources for the third edition of our book. W3C just published a new Working Draft which describes features for printing, e.g., footnotes, cross-references, and even generated indexes.

For mobile units, I think Media Queries will be important. For example, they can express that large images should not be sent to mobile devices.

Another great opportunity for CSS is Web Applications. Just like documents, applications need to be styled and CSS is an intrinsic component of AJAX. The "AJAX" name sounds great, but allow me to propose a few alternate spellings that I find more accurate:

• AJACX: Asynchronous JavaScript, CSS and XMLHttpRequest
• ADJACS: Asynchronous DOM, JavaScript and CSS
• ADHJACS: Asynchronous DOM, HTML, JavaScript and CSS
• AJAHCS: Asynchronous JavaScript, HTML and CSS
• AJACS: Asynchronous JavaScript, HTML and CSS

Opera, Mozilla and Safari developers are collaborating in the WHAT WG and in W3C to make sure we have interoperable specifications for AJAX. I mean, ADHJACS.

 > by crush

 > Is the difficulty of producing a layout that consists of
 > three or more columns of equal height justification for
 > adding some new feature to the specification to make this easier?

I don't think so. CSS2 defines a table layout that can be used for this purpose. The problem is, and I'm repeating myself here, that the dominant browser doesn't support it. Adding yet more features to the specification wouldn't help.

 > How come, we um, lie?

Right. My name is, um, a bit troublesome to pronounce in English. But I'm a nice person who generally tells the truth. I often tell non-Norwegians that my first name is pronounced "howcome". That's close, but not quite. It does make for a great email address like howcome@opera.com, though.

So I may be a Lie, but I'm just a little white one :-)

You submitted questions for Håkon Wium Lie on June 20. Today we have his answers, not only to the (+5 moderated) questions we sent him, but to a bunch of others he thought would also be interesting to answer.

 > Where... by bcat24
 >
 > Do you think the W3C development process is too slow? I know that
 > you guys want everything to be perfect, but it seems to take far
 > longer than necessary. CSS 3 shows promise and I wouldn't want it
 > to die a slow death in standardization.

No, I don't think W3C is too slow. W3C isn't the bottleneck, browsers are. The dominant browser on the web hasn't been updated for years, and it doesn't make sense for specifications to get too far ahead. Rather, the CSS Working Group in W3C has focused on specification maintenance and achieving interoperability between implementations. This work is not so glamorous and some people — even within W3C — would prefer if they concentrate on new specifications. However, I think the focus on interoperability (which has resulted in CSS 2.1) has been crucial to the success of CSS.

CSS3 is a set of specifications that are developed more or less independently of each other. The best way to push a specification forward is to implement it. In the past year, we've seen some encouraging CSS3 implementations come along. For example, Mozilla supports multi-column layouts, Opera supports media queries, Prince supports cross-references and Safari supports borders and backgrounds. A few years from now, I think a select group of CSS3 modules will be interoperably supported in all browsers.

 > Why is CSS such a good idea but a pain to use?
 > by rar
 >
 > CSS is clearly very useful for separating style from content. But
 > apparently people tend to have problems when using it for layouts.
 > Would you say this is because people have not yet understood how to
 > properly do layout in CSS, or is it CSS that is lacking in this
 > area? What can be done to improve the situation? --- Would the web
 > benefit from HTML and CSS being complemented with some kind of
 > "layout language"?

I think layout and style should be tackled by the same language and the two are intertwined. Trying to split the two is like splitting the HTML specification in two, one specification describing inline elements and the other describing block elements. It's not worth the effort.

I think CSS is capable of describing beautiful and scalable layouts. The CSS Zen Garden has been a eye-opening showcase of what is possible today. If MS IE had supported CSS tables, another set of layouts would have been possible. So, there is still lots of potential in the existing CSS specifications which should be the next milestone. Beyond that, the CSS Working Group has started work on a new CSS3 module for advanced layout. Feedback is welcome.

 > CSS Evolution!
 > by eieken
 >
 > Is the wave of webpages designed completely in CSS what you
 > intially intended when you came up with CSS? Do you see that
 > changing? Is that good or bad?

I saw a clear need for a web style sheet language when proposing CSS in 1994. I also wanted CSS to fully describe the presentation of a web pages -- not just add some styling. All in all, I think it has turned out quite well. It has taken longer than I expected, but the scale -- due to the growth of the web -- is more than anyone could imagine.

I used "I" too many times in the previous paragraph. It's important to realize that CSS is a community effort rather that one man's work. Bert Bos joined me early and we worked out the initial designs on a whiteboard during the summer of 1995. The www-style mailing lists and the W3C CSS Working Group have also been crucial in ensuring the success of CSS.

If you're interested in the history of web style sheets, you'll find plenty of material in my PhD thesis on the subject.

 > Two questions (cut to 1.5 by editor Roblimo)
 > by Dolda2000

 > If you were allowed (perhaps by court order, which wouldn't be
 > unthinkable) to force Microsoft to do one (1) change in Internet
 > Explorer, what would that be?

I would force them to support one (1) single web page before shipping IE7, namely Acid2. By using a tiny amount of resources to get Acid2 right, Microsoft can save web designers and users endless amounts of frustration in the future. It would also be an honorable thing to do. This is what Microsoft's W3C representative wrote in 1998:

Microsoft has a deep commitment to working with the W3C on HTML and CSS. We have the first commercial implementation of HTML4, we were the first vendor anywhere to implement even portions of CSS, and we have put a tremendous amount of energy into seeing CSS mature to Level 2. We are still committed to complete implementations of the Recommendations of the W3C in this area (CSS and HTML and the DOM).

May I have one (1) more change? Please? Then I would make IE7 support TrueType downloadable fonts. Microsoft's record in fonts isn't that bad. They made their core fonts available for anyone to use, and IE supports downloadable fonts. Unfortunately, only the proprietary EOT format is supported. A few lines of code would be sufficient to support zipped TrueType fonts as well, and this would unleash a new wave of typography on the web. (To protect yourself, make sure you use a browser where author style sheets can be turned off — Shift-G in Opera). > As a bonus question: What do you think of Slashdot's CSS? ;)

The new design looks great! The style sheets behind the scene are more complex than what the average web page needs. But, we wouldn't expect anything average from Slashdot, would we?

> 6)  Opera
 > by taskforce
 >
 > Opera 9.0 seems to offer a lot of decent additions to Opera's
 > standards pool. How satisfied are you personally with the work the
 > team has done on implementing standards, and is there anything in
 > there you feel is superflous and anything you would have preferred
 > to see which wasn't in there?

I'm very proud of the standards support in Opera 9. Acid2 is an obvious favorite of mine and seeing that smiley face makes me very happy.

Among the more experimental features is support for Audio in HTML5. Web applications can now make sounds in a sensible way! Combined with the canvas element, developers can create Flash-like content without resorting to a proprietary format.

Having support for Bittorrent is also great. From a technical point of view, it makes much sense. Also, it's a political statement of sorts.

During the development of Opera9. Geir Ivarsøy, who founded Opera with Jon von Tetzchner, died after fighting cancer for years. Geir did a spectacular initial CSS implementation in Opera, thus convincing me to join the company. In music, the 9th is legendary. Beethoven, Schubert, Bruckner and Mahler all did 9 symphonies. Opera 9 was Geir's last symphony.

> Included styles, aliases
 > by Spy der Mann
 >
 > I always wanted to have "included" substyles or "aliases" in my
 > CSS definition, to save redundancy.
 >
 > (For includes)
 >
 >     .class1 { color:#ff0000; }
 >     .class2 { background-color:#ffffff; }
 >     .class3 { include:class1,class2;font-weight:bold; }
 >
 > (For aliases)
 >
 >     @alias color1 #ff0000;
 >     @alias color2 #ffffff;
 >     @alias default_image url('/img/image1.jpg');
 >
 >     .class1 { color:color1; }
 >     .class2 { background-image:default_image;background-color:co lor2; }
 >
 > This way we could change colors or images for a whole webpage
 > by editing a reduced number of lines.
 >
 > Had you considered any of these ideas in the past? If so,
 > why were they rejected?

Yes, aliases and constants have been considered. As David Wheeler noted, "Any problem in computer science can be solved with another layer of indirection."

CSS is already an indirection. Instead of putting properties and values directly on elements, it associates properties and values with selectors. What you (and others) are proposing is to add another layer of indirection. By doing so, one could possible write shorter, more manageable style sheets. However, there are also some downsides. It requires a new syntactic construct (@alias) and implementations must be able to remember a list of aliases. What if aliases are defined in one style sheet and referenced in another -- should that work? If so, what if the first style sheet isn't available?

For CSS1, the downsides of aliases were considered more significant than the benefits.

 > Definition of pixel
 > by Sara Chan
 >
 > The word pixel meant "picture element", but CSS redefined it
 >to mean something quite different (a particular subtended angle
 >of view [w3.org]). This causes confusion: CSS pixels are not pixels.
 >(Indeed, I have seen misinformed comments on Slashdot due to
 >that confusion.)
 >
 > My question is this: why call the subtended angle a "pixel", instead of
 >something else (e.g. "subangle")? If CSS wanted to use the subtended
 >angle for something, that is fine, but calling it a pixel seems to follow
 >the approach of Humpty Dumpty "When I use a word, it means just
 >what I choose it to mean".

In most cases, a CSS pixel will be equal to a device pixel. But, as you point out, the definition of a CSS pixel will sometimes be different. For example, on a laser printer, one CSS pixel can be equal to 3x3 device pixels to avoid printing illegibly small text and images. I don't recall anyone ever proposing another name for it. Subangle? Personally, I think most people would prefer the pragmatic "px" to the non-intuitive "sa".

> Vertical CSS Support
 > by infestedsenses
 >
 > As a developer who works with CSS every day, I find one
 > complication that continues to bother me in my daily work.
 > Support for CSS has always been good on the horizontal scope,
 > but vertical positioning has always been quite complicated.
 > Alone the procedure to affix a footer to the bottom of a screen
 > in dependance of the amount of content is unnecessarily difficult,
 > spawning hackish solutions such as "footerStickAlt"
 > [themaninblue.com]. Centering an object in the dead center of a
 > page also requires strange procedures such as this one [wpdfd.com],
 > which still aren't ideal (try making the viewport really small). The old
 > table method provided much easier methods for this. What are your
 > thoughts on this and do you see improvement following in future
 > CSS revisions?

Indeed, the CSS formatting model allows more control horizontally than vertically. This is due to (typically) having a known width, but an unknown height. As such, the height is harder to deal with.

However, CSS2 fixed positioning allows you to place content relative to the viewport (which is CSS-speak for window) instead of the document. For example, by setting position: fixed; bottom: 0 on an element, it will stick to the bottom. This works in Opera, Safari and Mozilla-based browsers. IE6 doesn't support it, however. It remains to be seen if IE7 will support it.

> About Microsoft...
 > by Chabil Ha'
 >
 > With MS's next browser release (IE 7), you mentioned in other
 > interviews that their decision to not supprt CSS2 was more a political
 > decision than a mechanical one. Aside from their obvious desire to
 > dominate the world, what politics do you think are in play that make
 > them not want to conform to the standard, and what do you think would
 > change that landscape so that they would have some initiative to
 > fully support it?

Great question. It's quite clear that Microsoft has the resources and talent to support CSS2 fully in IE and that plenty of people have reminded them why this is important. So, why don't they do it? The fundamental reason, I believe, is that standards don't benefit monopolists. Accepted, well-functioning, standards lower the barrier of entry to a market, and is therefore a threat to a monopolist.

From that perspective, it makes sense to leave CSS2 half-implemented. You can claim support (and many journalists will believe you), and you also ensure that no-one can use the unimplemented (or worse: buggily implemented) features of the standard. The only way to change the equation is to remind Microsoft how embarrassing it is to offer a sub-standard browser. And to use better browsers.

Another reason for not making a IE too good is that it will compete with Windows. A modern browser is an application platform; the combination of HTML, JavaScript, CSS and DOM allows developers to target the web instead of Windows, Linux, or Mac.

> From linvir
 > How long since you last used Linux?

I'm using it right now. Ubuntu on a IBM Thinkpad X41 is the environment I live in. Ubuntu rocks -- especially with Opera on top! (And Emacs right underneath.)

 > From Rob T Firefly (844560)
 > Why the curly brackets?

The initial CSS proposal didn't use them, instead relying on newlines to separate statements. TimBL didn't really like that and I therefore borrowed the curly braces from the C programming language. The syntax for comments came along as well. I think it works quite well.

 > why not XML?
 > by slashdot.org
 > Simple question (hopefully simple answer ;-)): why
 > did you not use XML?

The simple answer is that the development of CSS preceded XML by a year or so. However, if XML had been available, would we have used it? Probably not. And I suspect Brendan Eich of JavaScript fame would answer the same way on behalf of his language.

XML is a great syntax for structured data, but not suitable for all languages. Still, I think the SGML-based syntax for the FOSI style sheet language.

 > Padding
 > by Anonymous Coward

 > Why was the decision made to make padding apply outside
 > of the width of a 'box', rather than inside, which would seem
 > to make more sense?

It makes sense in some situations, but not in others. For example, when a child element is set to width: 100%, I don't think it should cover the padding of its parent. The box-sizing property in CSS3 addresses this issue. Ideally, the issue should have been addressed earlier, though.

> by nuzak

 > why not float:

 > DSSSL had this sort of thing solved before HTML even existed,
 > let alone CSS. But scheme is too scary and icky, and the W3C
 > believes in a principle of least power, so CSS has to be fully declarative,
 > static, and crippled until patched later.

You're wrong about DSSSL -- it didn't support floating text (as in having text wrap around images) at all. And the DSSSL specification only became publically available around 1996, years after HTML.

> by MagicM

 > How frustrating is it to write a specification knowing
 > that you're at the browser vendors' mercy?

That's part of the game. I don't think any specification has a birthright to be fully supported by all browsers. There should be healthy competition between different specifications. I believe simple, author-friendly specifications will prevail in this environment.

Microformats are another way of developing new formats. Instead of having to convince browser vendors to support your favorite specification, microformats add semantics to HTML through the CLASS attribute. And style it with CSS.

> New standards
 > by iamsure
 >
 > In your work at Opera, you have clearly paved a path that includes
 > going beyond the W3C standards. Whether it is WhatWG
 > implementations, or new functionality specific to Opera (2dgame),
 > you are pushing into new territory. Can you explain why W3C isn't
 > sufficient, and why efforts at Opera to expand beyond the standards
 > differ from Microsoft's embrace/extend model?

It's a fair question. The WhatWG was set up when it seemed as if W3C didn't care much about browsers anymore. That has definitely changed and work items from WhatWG are now channeled into W3C (e.g., XMLHttpRequest).

At Opera, we sometimes include experimental features before they have been standardized. When this happens they are labeled as such, but we still try to document them. For example, we support some Opera-only CSS properties for XML. If these features gain traction, we are happy to work with other organizations to standardize them. If they don't become popular, the features will most likely disappear.

 > Beyond HTML
 > by pr1000

 > How far can CSS be taken beyond the web page--that is,
 > have generalized or non-web specific features for such things
 > as page formatting or type setting? Do you plan/wish/hope to
 > take it farther than it currently is?

Yes, I think it's possible to take CSS further in several directions. I'm eager to see CSS being used in paper-based publishing and I joined the board of YesLogic — which makes the Prince XML to PDF converter — to make sure they added my favorite features. Bert and I used Prince to generate PDF from HTML and CSS sources for the third edition of our book. W3C just published a new Working Draft which describes features for printing, e.g., footnotes, cross-references, and even generated indexes.

For mobile units, I think Media Queries will be important. For example, they can express that large images should not be sent to mobile devices.

Another great opportunity for CSS is Web Applications. Just like documents, applications need to be styled and CSS is an intrinsic component of AJAX. The "AJAX" name sounds great, but allow me to propose a few alternate spellings that I find more accurate:

• AJACX: Asynchronous JavaScript, CSS and XMLHttpRequest
• ADJACS: Asynchronous DOM, JavaScript and CSS
• ADHJACS: Asynchronous DOM, HTML, JavaScript and CSS
• AJAHCS: Asynchronous JavaScript, HTML and CSS
• AJACS: Asynchronous JavaScript, HTML and CSS

Opera, Mozilla and Safari developers are collaborating in the WHAT WG and in W3C to make sure we have interoperable specifications for AJAX. I mean, ADHJACS.

 > by crush

 > Is the difficulty of producing a layout that consists of
 > three or more columns of equal height justification for
 > adding some new feature to the specification to make this easier?

I don't think so. CSS2 defines a table layout that can be used for this purpose. The problem is, and I'm repeating myself here, that the dominant browser doesn't support it. Adding yet more features to the specification wouldn't help.

 > How come, we um, lie?

Right. My name is, um, a bit troublesome to pronounce in English. But I'm a nice person who generally tells the truth. I often tell non-Norwegians that my first name is pronounced "howcome". That's close, but not quite. It does make for a great email address like howcome@opera.com, though.

So I may be a Lie, but I'm just a little white one :-)

You submitted questions for Håkon Wium Lie on June 20. Today we have his answers, not only to the (+5 moderated) questions we sent him, but to a bunch of others he thought would also be interesting to answer.

 > Where... by bcat24
 >
 > Do you think the W3C development process is too slow? I know that
 > you guys want everything to be perfect, but it seems to take far
 > longer than necessary. CSS 3 shows promise and I wouldn't want it
 > to die a slow death in standardization.

No, I don't think W3C is too slow. W3C isn't the bottleneck, browsers are. The dominant browser on the web hasn't been updated for years, and it doesn't make sense for specifications to get too far ahead. Rather, the CSS Working Group in W3C has focused on specification maintenance and achieving interoperability between implementations. This work is not so glamorous and some people — even within W3C — would prefer if they concentrate on new specifications. However, I think the focus on interoperability (which has resulted in CSS 2.1) has been crucial to the success of CSS.

CSS3 is a set of specifications that are developed more or less independently of each other. The best way to push a specification forward is to implement it. In the past year, we've seen some encouraging CSS3 implementations come along. For example, Mozilla supports multi-column layouts, Opera supports media queries, Prince supports cross-references and Safari supports borders and backgrounds. A few years from now, I think a select group of CSS3 modules will be interoperably supported in all browsers.

 > Why is CSS such a good idea but a pain to use?
 > by rar
 >
 > CSS is clearly very useful for separating style from content. But
 > apparently people tend to have problems when using it for layouts.
 > Would you say this is because people have not yet understood how to
 > properly do layout in CSS, or is it CSS that is lacking in this
 > area? What can be done to improve the situation? --- Would the web
 > benefit from HTML and CSS being complemented with some kind of
 > "layout language"?

I think layout and style should be tackled by the same language and the two are intertwined. Trying to split the two is like splitting the HTML specification in two, one specification describing inline elements and the other describing block elements. It's not worth the effort.

I think CSS is capable of describing beautiful and scalable layouts. The CSS Zen Garden has been a eye-opening showcase of what is possible today. If MS IE had supported CSS tables, another set of layouts would have been possible. So, there is still lots of potential in the existing CSS specifications which should be the next milestone. Beyond that, the CSS Working Group has started work on a new CSS3 module for advanced layout. Feedback is welcome.

 > CSS Evolution!
 > by eieken
 >
 > Is the wave of webpages designed completely in CSS what you
 > intially intended when you came up with CSS? Do you see that
 > changing? Is that good or bad?

I saw a clear need for a web style sheet language when proposing CSS in 1994. I also wanted CSS to fully describe the presentation of a web pages -- not just add some styling. All in all, I think it has turned out quite well. It has taken longer than I expected, but the scale -- due to the growth of the web -- is more than anyone could imagine.

I used "I" too many times in the previous paragraph. It's important to realize that CSS is a community effort rather that one man's work. Bert Bos joined me early and we worked out the initial designs on a whiteboard during the summer of 1995. The www-style mailing lists and the W3C CSS Working Group have also been crucial in ensuring the success of CSS.

If you're interested in the history of web style sheets, you'll find plenty of material in my PhD thesis on the subject.

 > Two questions (cut to 1.5 by editor Roblimo)
 > by Dolda2000

 > If you were allowed (perhaps by court order, which wouldn't be
 > unthinkable) to force Microsoft to do one (1) change in Internet
 > Explorer, what would that be?

I would force them to support one (1) single web page before shipping IE7, namely Acid2. By using a tiny amount of resources to get Acid2 right, Microsoft can save web designers and users endless amounts of frustration in the future. It would also be an honorable thing to do. This is what Microsoft's W3C representative wrote in 1998:

Microsoft has a deep commitment to working with the W3C on HTML and CSS. We have the first commercial implementation of HTML4, we were the first vendor anywhere to implement even portions of CSS, and we have put a tremendous amount of energy into seeing CSS mature to Level 2. We are still committed to complete implementations of the Recommendations of the W3C in this area (CSS and HTML and the DOM).

May I have one (1) more change? Please? Then I would make IE7 support TrueType downloadable fonts. Microsoft's record in fonts isn't that bad. They made their core fonts available for anyone to use, and IE supports downloadable fonts. Unfortunately, only the proprietary EOT format is supported. A few lines of code would be sufficient to support zipped TrueType fonts as well, and this would unleash a new wave of typography on the web. (To protect yourself, make sure you use a browser where author style sheets can be turned off — Shift-G in Opera). > As a bonus question: What do you think of Slashdot's CSS? ;)

The new design looks great! The style sheets behind the scene are more complex than what the average web page needs. But, we wouldn't expect anything average from Slashdot, would we?

> 6)  Opera
 > by taskforce
 >
 > Opera 9.0 seems to offer a lot of decent additions to Opera's
 > standards pool. How satisfied are you personally with the work the
 > team has done on implementing standards, and is there anything in
 > there you feel is superflous and anything you would have preferred
 > to see which wasn't in there?

I'm very proud of the standards support in Opera 9. Acid2 is an obvious favorite of mine and seeing that smiley face makes me very happy.

Among the more experimental features is support for Audio in HTML5. Web applications can now make sounds in a sensible way! Combined with the canvas element, developers can create Flash-like content without resorting to a proprietary format.

Having support for Bittorrent is also great. From a technical point of view, it makes much sense. Also, it's a political statement of sorts.

During the development of Opera9. Geir Ivarsøy, who founded Opera with Jon von Tetzchner, died after fighting cancer for years. Geir did a spectacular initial CSS implementation in Opera, thus convincing me to join the company. In music, the 9th is legendary. Beethoven, Schubert, Bruckner and Mahler all did 9 symphonies. Opera 9 was Geir's last symphony.

> Included styles, aliases
 > by Spy der Mann
 >
 > I always wanted to have "included" substyles or "aliases" in my
 > CSS definition, to save redundancy.
 >
 > (For includes)
 >
 >     .class1 { color:#ff0000; }
 >     .class2 { background-color:#ffffff; }
 >     .class3 { include:class1,class2;font-weight:bold; }
 >
 > (For aliases)
 >
 >     @alias color1 #ff0000;
 >     @alias color2 #ffffff;
 >     @alias default_image url('/img/image1.jpg');
 >
 >     .class1 { color:color1; }
 >     .class2 { background-image:default_image;background-color:co lor2; }
 >
 > This way we could change colors or images for a whole webpage
 > by editing a reduced number of lines.
 >
 > Had you considered any of these ideas in the past? If so,
 > why were they rejected?

Yes, aliases and constants have been considered. As David Wheeler noted, "Any problem in computer science can be solved with another layer of indirection."

CSS is already an indirection. Instead of putting properties and values directly on elements, it associates properties and values with selectors. What you (and others) are proposing is to add another layer of indirection. By doing so, one could possible write shorter, more manageable style sheets. However, there are also some downsides. It requires a new syntactic construct (@alias) and implementations must be able to remember a list of aliases. What if aliases are defined in one style sheet and referenced in another -- should that work? If so, what if the first style sheet isn't available?

For CSS1, the downsides of aliases were considered more significant than the benefits.

 > Definition of pixel
 > by Sara Chan
 >
 > The word pixel meant "picture element", but CSS redefined it
 >to mean something quite different (a particular subtended angle
 >of view [w3.org]). This causes confusion: CSS pixels are not pixels.
 >(Indeed, I have seen misinformed comments on Slashdot due to
 >that confusion.)
 >
 > My question is this: why call the subtended angle a "pixel", instead of
 >something else (e.g. "subangle")? If CSS wanted to use the subtended
 >angle for something, that is fine, but calling it a pixel seems to follow
 >the approach of Humpty Dumpty "When I use a word, it means just
 >what I choose it to mean".

In most cases, a CSS pixel will be equal to a device pixel. But, as you point out, the definition of a CSS pixel will sometimes be different. For example, on a laser printer, one CSS pixel can be equal to 3x3 device pixels to avoid printing illegibly small text and images. I don't recall anyone ever proposing another name for it. Subangle? Personally, I think most people would prefer the pragmatic "px" to the non-intuitive "sa".

> Vertical CSS Support
 > by infestedsenses
 >
 > As a developer who works with CSS every day, I find one
 > complication that continues to bother me in my daily work.
 > Support for CSS has always been good on the horizontal scope,
 > but vertical positioning has always been quite complicated.
 > Alone the procedure to affix a footer to the bottom of a screen
 > in dependance of the amount of content is unnecessarily difficult,
 > spawning hackish solutions such as "footerStickAlt"
 > [themaninblue.com]. Centering an object in the dead center of a
 > page also requires strange procedures such as this one [wpdfd.com],
 > which still aren't ideal (try making the viewport really small). The old
 > table method provided much easier methods for this. What are your
 > thoughts on this and do you see improvement following in future
 > CSS revisions?

Indeed, the CSS formatting model allows more control horizontally than vertically. This is due to (typically) having a known width, but an unknown height. As such, the height is harder to deal with.

However, CSS2 fixed positioning allows you to place content relative to the viewport (which is CSS-speak for window) instead of the document. For example, by setting position: fixed; bottom: 0 on an element, it will stick to the bottom. This works in Opera, Safari and Mozilla-based browsers. IE6 doesn't support it, however. It remains to be seen if IE7 will support it.

> About Microsoft...
 > by Chabil Ha'
 >
 > With MS's next browser release (IE 7), you mentioned in other
 > interviews that their decision to not supprt CSS2 was more a political
 > decision than a mechanical one. Aside from their obvious desire to
 > dominate the world, what politics do you think are in play that make
 > them not want to conform to the standard, and what do you think would
 > change that landscape so that they would have some initiative to
 > fully support it?

Great question. It's quite clear that Microsoft has the resources and talent to support CSS2 fully in IE and that plenty of people have reminded them why this is important. So, why don't they do it? The fundamental reason, I believe, is that standards don't benefit monopolists. Accepted, well-functioning, standards lower the barrier of entry to a market, and is therefore a threat to a monopolist.

From that perspective, it makes sense to leave CSS2 half-implemented. You can claim support (and many journalists will believe you), and you also ensure that no-one can use the unimplemented (or worse: buggily implemented) features of the standard. The only way to change the equation is to remind Microsoft how embarrassing it is to offer a sub-standard browser. And to use better browsers.

Another reason for not making a IE too good is that it will compete with Windows. A modern browser is an application platform; the combination of HTML, JavaScript, CSS and DOM allows developers to target the web instead of Windows, Linux, or Mac.

> From linvir
 > How long since you last used Linux?

I'm using it right now. Ubuntu on a IBM Thinkpad X41 is the environment I live in. Ubuntu rocks -- especially with Opera on top! (And Emacs right underneath.)

 > From Rob T Firefly (844560)
 > Why the curly brackets?

The initial CSS proposal didn't use them, instead relying on newlines to separate statements. TimBL didn't really like that and I therefore borrowed the curly braces from the C programming language. The syntax for comments came along as well. I think it works quite well.

 > why not XML?
 > by slashdot.org
 > Simple question (hopefully simple answer ;-)): why
 > did you not use XML?

The simple answer is that the development of CSS preceded XML by a year or so. However, if XML had been available, would we have used it? Probably not. And I suspect Brendan Eich of JavaScript fame would answer the same way on behalf of his language.

XML is a great syntax for structured data, but not suitable for all languages. Still, I think the SGML-based syntax for the FOSI style sheet language.

 > Padding
 > by Anonymous Coward

 > Why was the decision made to make padding apply outside
 > of the width of a 'box', rather than inside, which would seem
 > to make more sense?

It makes sense in some situations, but not in others. For example, when a child element is set to width: 100%, I don't think it should cover the padding of its parent. The box-sizing property in CSS3 addresses this issue. Ideally, the issue should have been addressed earlier, though.

> by nuzak

 > why not float:

 > DSSSL had this sort of thing solved before HTML even existed,
 > let alone CSS. But scheme is too scary and icky, and the W3C
 > believes in a principle of least power, so CSS has to be fully declarative,
 > static, and crippled until patched later.

You're wrong about DSSSL -- it didn't support floating text (as in having text wrap around images) at all. And the DSSSL specification only became publically available around 1996, years after HTML.

> by MagicM

 > How frustrating is it to write a specification knowing
 > that you're at the browser vendors' mercy?

That's part of the game. I don't think any specification has a birthright to be fully supported by all browsers. There should be healthy competition between different specifications. I believe simple, author-friendly specifications will prevail in this environment.

Microformats are another way of developing new formats. Instead of having to convince browser vendors to support your favorite specification, microformats add semantics to HTML through the CLASS attribute. And style it with CSS.

> New standards
 > by iamsure
 >
 > In your work at Opera, you have clearly paved a path that includes
 > going beyond the W3C standards. Whether it is WhatWG
 > implementations, or new functionality specific to Opera (2dgame),
 > you are pushing into new territory. Can you explain why W3C isn't
 > sufficient, and why efforts at Opera to expand beyond the standards
 > differ from Microsoft's embrace/extend model?

It's a fair question. The WhatWG was set up when it seemed as if W3C didn't care much about browsers anymore. That has definitely changed and work items from WhatWG are now channeled into W3C (e.g., XMLHttpRequest).

At Opera, we sometimes include experimental features before they have been standardized. When this happens they are labeled as such, but we still try to document them. For example, we support some Opera-only CSS properties for XML. If these features gain traction, we are happy to work with other organizations to standardize them. If they don't become popular, the features will most likely disappear.

 > Beyond HTML
 > by pr1000

 > How far can CSS be taken beyond the web page--that is,
 > have generalized or non-web specific features for such things
 > as page formatting or type setting? Do you plan/wish/hope to
 > take it farther than it currently is?

Yes, I think it's possible to take CSS further in several directions. I'm eager to see CSS being used in paper-based publishing and I joined the board of YesLogic — which makes the Prince XML to PDF converter — to make sure they added my favorite features. Bert and I used Prince to generate PDF from HTML and CSS sources for the third edition of our book. W3C just published a new Working Draft which describes features for printing, e.g., footnotes, cross-references, and even generated indexes.

For mobile units, I think Media Queries will be important. For example, they can express that large images should not be sent to mobile devices.

Another great opportunity for CSS is Web Applications. Just like documents, applications need to be styled and CSS is an intrinsic component of AJAX. The "AJAX" name sounds great, but allow me to propose a few alternate spellings that I find more accurate:

• AJACX: Asynchronous JavaScript, CSS and XMLHttpRequest
• ADJACS: Asynchronous DOM, JavaScript and CSS
• ADHJACS: Asynchronous DOM, HTML, JavaScript and CSS
• AJAHCS: Asynchronous JavaScript, HTML and CSS
• AJACS: Asynchronous JavaScript, HTML and CSS

Opera, Mozilla and Safari developers are collaborating in the WHAT WG and in W3C to make sure we have interoperable specifications for AJAX. I mean, ADHJACS.

 > by crush

 > Is the difficulty of producing a layout that consists of
 > three or more columns of equal height justification for
 > adding some new feature to the specification to make this easier?

I don't think so. CSS2 defines a table layout that can be used for this purpose. The problem is, and I'm repeating myself here, that the dominant browser doesn't support it. Adding yet more features to the specification wouldn't help.

 > How come, we um, lie?

Right. My name is, um, a bit troublesome to pronounce in English. But I'm a nice person who generally tells the truth. I often tell non-Norwegians that my first name is pronounced "howcome". That's close, but not quite. It does make for a great email address like howcome@opera.com, though.

So I may be a Lie, but I'm just a little white one :-)

You submitted questions for Håkon Wium Lie on June 20. Today we have his answers, not only to the (+5 moderated) questions we sent him, but to a bunch of others he thought would also be interesting to answer.

 > Where... by bcat24
 >
 > Do you think the W3C development process is too slow? I know that
 > you guys want everything to be perfect, but it seems to take far
 > longer than necessary. CSS 3 shows promise and I wouldn't want it
 > to die a slow death in standardization.

No, I don't think W3C is too slow. W3C isn't the bottleneck, browsers are. The dominant browser on the web hasn't been updated for years, and it doesn't make sense for specifications to get too far ahead. Rather, the CSS Working Group in W3C has focused on specification maintenance and achieving interoperability between implementations. This work is not so glamorous and some people — even within W3C — would prefer if they concentrate on new specifications. However, I think the focus on interoperability (which has resulted in CSS 2.1) has been crucial to the success of CSS.

CSS3 is a set of specifications that are developed more or less independently of each other. The best way to push a specification forward is to implement it. In the past year, we've seen some encouraging CSS3 implementations come along. For example, Mozilla supports multi-column layouts, Opera supports media queries, Prince supports cross-references and Safari supports borders and backgrounds. A few years from now, I think a select group of CSS3 modules will be interoperably supported in all browsers.

 > Why is CSS such a good idea but a pain to use?
 > by rar
 >
 > CSS is clearly very useful for separating style from content. But
 > apparently people tend to have problems when using it for layouts.
 > Would you say this is because people have not yet understood how to
 > properly do layout in CSS, or is it CSS that is lacking in this
 > area? What can be done to improve the situation? --- Would the web
 > benefit from HTML and CSS being complemented with some kind of
 > "layout language"?

I think layout and style should be tackled by the same language and the two are intertwined. Trying to split the two is like splitting the HTML specification in two, one specification describing inline elements and the other describing block elements. It's not worth the effort.

I think CSS is capable of describing beautiful and scalable layouts. The CSS Zen Garden has been a eye-opening showcase of what is possible today. If MS IE had supported CSS tables, another set of layouts would have been possible. So, there is still lots of potential in the existing CSS specifications which should be the next milestone. Beyond that, the CSS Working Group has started work on a new CSS3 module for advanced layout. Feedback is welcome.

 > CSS Evolution!
 > by eieken
 >
 > Is the wave of webpages designed completely in CSS what you
 > intially intended when you came up with CSS? Do you see that
 > changing? Is that good or bad?

I saw a clear need for a web style sheet language when proposing CSS in 1994. I also wanted CSS to fully describe the presentation of a web pages -- not just add some styling. All in all, I think it has turned out quite well. It has taken longer than I expected, but the scale -- due to the growth of the web -- is more than anyone could imagine.

I used "I" too many times in the previous paragraph. It's important to realize that CSS is a community effort rather that one man's work. Bert Bos joined me early and we worked out the initial designs on a whiteboard during the summer of 1995. The www-style mailing lists and the W3C CSS Working Group have also been crucial in ensuring the success of CSS.

If you're interested in the history of web style sheets, you'll find plenty of material in my PhD thesis on the subject.

 > Two questions (cut to 1.5 by editor Roblimo)
 > by Dolda2000

 > If you were allowed (perhaps by court order, which wouldn't be
 > unthinkable) to force Microsoft to do one (1) change in Internet
 > Explorer, what would that be?

I would force them to support one (1) single web page before shipping IE7, namely Acid2. By using a tiny amount of resources to get Acid2 right, Microsoft can save web designers and users endless amounts of frustration in the future. It would also be an honorable thing to do. This is what Microsoft's W3C representative wrote in 1998:

Microsoft has a deep commitment to working with the W3C on HTML and CSS. We have the first commercial implementation of HTML4, we were the first vendor anywhere to implement even portions of CSS, and we have put a tremendous amount of energy into seeing CSS mature to Level 2. We are still committed to complete implementations of the Recommendations of the W3C in this area (CSS and HTML and the DOM).

May I have one (1) more change? Please? Then I would make IE7 support TrueType downloadable fonts. Microsoft's record in fonts isn't that bad. They made their core fonts available for anyone to use, and IE supports downloadable fonts. Unfortunately, only the proprietary EOT format is supported. A few lines of code would be sufficient to support zipped TrueType fonts as well, and this would unleash a new wave of typography on the web. (To protect yourself, make sure you use a browser where author style sheets can be turned off — Shift-G in Opera). > As a bonus question: What do you think of Slashdot's CSS? ;)

The new design looks great! The style sheets behind the scene are more complex than what the average web page needs. But, we wouldn't expect anything average from Slashdot, would we?

> 6)  Opera
 > by taskforce
 >
 > Opera 9.0 seems to offer a lot of decent additions to Opera's
 > standards pool. How satisfied are you personally with the work the
 > team has done on implementing standards, and is there anything in
 > there you feel is superflous and anything you would have preferred
 > to see which wasn't in there?

I'm very proud of the standards support in Opera 9. Acid2 is an obvious favorite of mine and seeing that smiley face makes me very happy.

Among the more experimental features is support for Audio in HTML5. Web applications can now make sounds in a sensible way! Combined with the canvas element, developers can create Flash-like content without resorting to a proprietary format.

Having support for Bittorrent is also great. From a technical point of view, it makes much sense. Also, it's a political statement of sorts.

During the development of Opera9. Geir Ivarsøy, who founded Opera with Jon von Tetzchner, died after fighting cancer for years. Geir did a spectacular initial CSS implementation in Opera, thus convincing me to join the company. In music, the 9th is legendary. Beethoven, Schubert, Bruckner and Mahler all did 9 symphonies. Opera 9 was Geir's last symphony.

> Included styles, aliases
 > by Spy der Mann
 >
 > I always wanted to have "included" substyles or "aliases" in my
 > CSS definition, to save redundancy.
 >
 > (For includes)
 >
 >     .class1 { color:#ff0000; }
 >     .class2 { background-color:#ffffff; }
 >     .class3 { include:class1,class2;font-weight:bold; }
 >
 > (For aliases)
 >
 >     @alias color1 #ff0000;
 >     @alias color2 #ffffff;
 >     @alias default_image url('/img/image1.jpg');
 >
 >     .class1 { color:color1; }
 >     .class2 { background-image:default_image;background-color:co lor2; }
 >
 > This way we could change colors or images for a whole webpage
 > by editing a reduced number of lines.
 >
 > Had you considered any of these ideas in the past? If so,
 > why were they rejected?

Yes, aliases and constants have been considered. As David Wheeler noted, "Any problem in computer science can be solved with another layer of indirection."

CSS is already an indirection. Instead of putting properties and values directly on elements, it associates properties and values with selectors. What you (and others) are proposing is to add another layer of indirection. By doing so, one could possible write shorter, more manageable style sheets. However, there are also some downsides. It requires a new syntactic construct (@alias) and implementations must be able to remember a list of aliases. What if aliases are defined in one style sheet and referenced in another -- should that work? If so, what if the first style sheet isn't available?

For CSS1, the downsides of aliases were considered more significant than the benefits.

 > Definition of pixel
 > by Sara Chan
 >
 > The word pixel meant "picture element", but CSS redefined it
 >to mean something quite different (a particular subtended angle
 >of view [w3.org]). This causes confusion: CSS pixels are not pixels.
 >(Indeed, I have seen misinformed comments on Slashdot due to
 >that confusion.)
 >
 > My question is this: why call the subtended angle a "pixel", instead of
 >something else (e.g. "subangle")? If CSS wanted to use the subtended
 >angle for something, that is fine, but calling it a pixel seems to follow
 >the approach of Humpty Dumpty "When I use a word, it means just
 >what I choose it to mean".

In most cases, a CSS pixel will be equal to a device pixel. But, as you point out, the definition of a CSS pixel will sometimes be different. For example, on a laser printer, one CSS pixel can be equal to 3x3 device pixels to avoid printing illegibly small text and images. I don't recall anyone ever proposing another name for it. Subangle? Personally, I think most people would prefer the pragmatic "px" to the non-intuitive "sa".

> Vertical CSS Support
 > by infestedsenses
 >
 > As a developer who works with CSS every day, I find one
 > complication that continues to bother me in my daily work.
 > Support for CSS has always been good on the horizontal scope,
 > but vertical positioning has always been quite complicated.
 > Alone the procedure to affix a footer to the bottom of a screen
 > in dependance of the amount of content is unnecessarily difficult,
 > spawning hackish solutions such as "footerStickAlt"
 > [themaninblue.com]. Centering an object in the dead center of a
 > page also requires strange procedures such as this one [wpdfd.com],
 > which still aren't ideal (try making the viewport really small). The old
 > table method provided much easier methods for this. What are your
 > thoughts on this and do you see improvement following in future
 > CSS revisions?

Indeed, the CSS formatting model allows more control horizontally than vertically. This is due to (typically) having a known width, but an unknown height. As such, the height is harder to deal with.

However, CSS2 fixed positioning allows you to place content relative to the viewport (which is CSS-speak for window) instead of the document. For example, by setting position: fixed; bottom: 0 on an element, it will stick to the bottom. This works in Opera, Safari and Mozilla-based browsers. IE6 doesn't support it, however. It remains to be seen if IE7 will support it.

> About Microsoft...
 > by Chabil Ha'
 >
 > With MS's next browser release (IE 7), you mentioned in other
 > interviews that their decision to not supprt CSS2 was more a political
 > decision than a mechanical one. Aside from their obvious desire to
 > dominate the world, what politics do you think are in play that make
 > them not want to conform to the standard, and what do you think would
 > change that landscape so that they would have some initiative to
 > fully support it?

Great question. It's quite clear that Microsoft has the resources and talent to support CSS2 fully in IE and that plenty of people have reminded them why this is important. So, why don't they do it? The fundamental reason, I believe, is that standards don't benefit monopolists. Accepted, well-functioning, standards lower the barrier of entry to a market, and is therefore a threat to a monopolist.

From that perspective, it makes sense to leave CSS2 half-implemented. You can claim support (and many journalists will believe you), and you also ensure that no-one can use the unimplemented (or worse: buggily implemented) features of the standard. The only way to change the equation is to remind Microsoft how embarrassing it is to offer a sub-standard browser. And to use better browsers.

Another reason for not making a IE too good is that it will compete with Windows. A modern browser is an application platform; the combination of HTML, JavaScript, CSS and DOM allows developers to target the web instead of Windows, Linux, or Mac.

> From linvir
 > How long since you last used Linux?

I'm using it right now. Ubuntu on a IBM Thinkpad X41 is the environment I live in. Ubuntu rocks -- especially with Opera on top! (And Emacs right underneath.)

 > From Rob T Firefly (844560)
 > Why the curly brackets?

The initial CSS proposal didn't use them, instead relying on newlines to separate statements. TimBL didn't really like that and I therefore borrowed the curly braces from the C programming language. The syntax for comments came along as well. I think it works quite well.

 > why not XML?
 > by slashdot.org
 > Simple question (hopefully simple answer ;-)): why
 > did you not use XML?

The simple answer is that the development of CSS preceded XML by a year or so. However, if XML had been available, would we have used it? Probably not. And I suspect Brendan Eich of JavaScript fame would answer the same way on behalf of his language.

XML is a great syntax for structured data, but not suitable for all languages. Still, I think the SGML-based syntax for the FOSI style sheet language.

 > Padding
 > by Anonymous Coward

 > Why was the decision made to make padding apply outside
 > of the width of a 'box', rather than inside, which would seem
 > to make more sense?

It makes sense in some situations, but not in others. For example, when a child element is set to width: 100%, I don't think it should cover the padding of its parent. The box-sizing property in CSS3 addresses this issue. Ideally, the issue should have been addressed earlier, though.

> by nuzak

 > why not float:

 > DSSSL had this sort of thing solved before HTML even existed,
 > let alone CSS. But scheme is too scary and icky, and the W3C
 > believes in a principle of least power, so CSS has to be fully declarative,
 > static, and crippled until patched later.

You're wrong about DSSSL -- it didn't support floating text (as in having text wrap around images) at all. And the DSSSL specification only became publically available around 1996, years after HTML.

> by MagicM

 > How frustrating is it to write a specification knowing
 > that you're at the browser vendors' mercy?

That's part of the game. I don't think any specification has a birthright to be fully supported by all browsers. There should be healthy competition between different specifications. I believe simple, author-friendly specifications will prevail in this environment.

Microformats are another way of developing new formats. Instead of having to convince browser vendors to support your favorite specification, microformats add semantics to HTML through the CLASS attribute. And style it with CSS.

> New standards
 > by iamsure
 >
 > In your work at Opera, you have clearly paved a path that includes
 > going beyond the W3C standards. Whether it is WhatWG
 > implementations, or new functionality specific to Opera (2dgame),
 > you are pushing into new territory. Can you explain why W3C isn't
 > sufficient, and why efforts at Opera to expand beyond the standards
 > differ from Microsoft's embrace/extend model?

It's a fair question. The WhatWG was set up when it seemed as if W3C didn't care much about browsers anymore. That has definitely changed and work items from WhatWG are now channeled into W3C (e.g., XMLHttpRequest).

At Opera, we sometimes include experimental features before they have been standardized. When this happens they are labeled as such, but we still try to document them. For example, we support some Opera-only CSS properties for XML. If these features gain traction, we are happy to work with other organizations to standardize them. If they don't become popular, the features will most likely disappear.

 > Beyond HTML
 > by pr1000

 > How far can CSS be taken beyond the web page--that is,
 > have generalized or non-web specific features for such things
 > as page formatting or type setting? Do you plan/wish/hope to
 > take it farther than it currently is?

Yes, I think it's possible to take CSS further in several directions. I'm eager to see CSS being used in paper-based publishing and I joined the board of YesLogic — which makes the Prince XML to PDF converter — to make sure they added my favorite features. Bert and I used Prince to generate PDF from HTML and CSS sources for the third edition of our book. W3C just published a new Working Draft which describes features for printing, e.g., footnotes, cross-references, and even generated indexes.

For mobile units, I think Media Queries will be important. For example, they can express that large images should not be sent to mobile devices.

Another great opportunity for CSS is Web Applications. Just like documents, applications need to be styled and CSS is an intrinsic component of AJAX. The "AJAX" name sounds great, but allow me to propose a few alternate spellings that I find more accurate:

• AJACX: Asynchronous JavaScript, CSS and XMLHttpRequest
• ADJACS: Asynchronous DOM, JavaScript and CSS
• ADHJACS: Asynchronous DOM, HTML, JavaScript and CSS
• AJAHCS: Asynchronous JavaScript, HTML and CSS
• AJACS: Asynchronous JavaScript, HTML and CSS

Opera, Mozilla and Safari developers are collaborating in the WHAT WG and in W3C to make sure we have interoperable specifications for AJAX. I mean, ADHJACS.

 > by crush

 > Is the difficulty of producing a layout that consists of
 > three or more columns of equal height justification for
 > adding some new feature to the specification to make this easier?

I don't think so. CSS2 defines a table layout that can be used for this purpose. The problem is, and I'm repeating myself here, that the dominant browser doesn't support it. Adding yet more features to the specification wouldn't help.

 > How come, we um, lie?

Right. My name is, um, a bit troublesome to pronounce in English. But I'm a nice person who generally tells the truth. I often tell non-Norwegians that my first name is pronounced "howcome". That's close, but not quite. It does make for a great email address like howcome@opera.com, though.

So I may be a Lie, but I'm just a little white one :-)

You submitted questions for Håkon Wium Lie on June 20. Today we have his answers, not only to the (+5 moderated) questions we sent him, but to a bunch of others he thought would also be interesting to answer.

 > Where... by bcat24
 >
 > Do you think the W3C development process is too slow? I know that
 > you guys want everything to be perfect, but it seems to take far
 > longer than necessary. CSS 3 shows promise and I wouldn't want it
 > to die a slow death in standardization.

No, I don't think W3C is too slow. W3C isn't the bottleneck, browsers are. The dominant browser on the web hasn't been updated for years, and it doesn't make sense for specifications to get too far ahead. Rather, the CSS Working Group in W3C has focused on specification maintenance and achieving interoperability between implementations. This work is not so glamorous and some people — even within W3C — would prefer if they concentrate on new specifications. However, I think the focus on interoperability (which has resulted in CSS 2.1) has been crucial to the success of CSS.

CSS3 is a set of specifications that are developed more or less independently of each other. The best way to push a specification forward is to implement it. In the past year, we've seen some encouraging CSS3 implementations come along. For example, Mozilla supports multi-column layouts, Opera supports media queries, Prince supports cross-references and Safari supports borders and backgrounds. A few years from now, I think a select group of CSS3 modules will be interoperably supported in all browsers.

 > Why is CSS such a good idea but a pain to use?
 > by rar
 >
 > CSS is clearly very useful for separating style from content. But
 > apparently people tend to have problems when using it for layouts.
 > Would you say this is because people have not yet understood how to
 > properly do layout in CSS, or is it CSS that is lacking in this
 > area? What can be done to improve the situation? --- Would the web
 > benefit from HTML and CSS being complemented with some kind of
 > "layout language"?

I think layout and style should be tackled by the same language and the two are intertwined. Trying to split the two is like splitting the HTML specification in two, one specification describing inline elements and the other describing block elements. It's not worth the effort.

I think CSS is capable of describing beautiful and scalable layouts. The CSS Zen Garden has been a eye-opening showcase of what is possible today. If MS IE had supported CSS tables, another set of layouts would have been possible. So, there is still lots of potential in the existing CSS specifications which should be the next milestone. Beyond that, the CSS Working Group has started work on a new CSS3 module for advanced layout. Feedback is welcome.

 > CSS Evolution!
 > by eieken
 >
 > Is the wave of webpages designed completely in CSS what you
 > intially intended when you came up with CSS? Do you see that
 > changing? Is that good or bad?

I saw a clear need for a web style sheet language when proposing CSS in 1994. I also wanted CSS to fully describe the presentation of a web pages -- not just add some styling. All in all, I think it has turned out quite well. It has taken longer than I expected, but the scale -- due to the growth of the web -- is more than anyone could imagine.

I used "I" too many times in the previous paragraph. It's important to realize that CSS is a community effort rather that one man's work. Bert Bos joined me early and we worked out the initial designs on a whiteboard during the summer of 1995. The www-style mailing lists and the W3C CSS Working Group have also been crucial in ensuring the success of CSS.

If you're interested in the history of web style sheets, you'll find plenty of material in my PhD thesis on the subject.

 > Two questions (cut to 1.5 by editor Roblimo)
 > by Dolda2000

 > If you were allowed (perhaps by court order, which wouldn't be
 > unthinkable) to force Microsoft to do one (1) change in Internet
 > Explorer, what would that be?

I would force them to support one (1) single web page before shipping IE7, namely Acid2. By using a tiny amount of resources to get Acid2 right, Microsoft can save web designers and users endless amounts of frustration in the future. It would also be an honorable thing to do. This is what Microsoft's W3C representative wrote in 1998:

Microsoft has a deep commitment to working with the W3C on HTML and CSS. We have the first commercial implementation of HTML4, we were the first vendor anywhere to implement even portions of CSS, and we have put a tremendous amount of energy into seeing CSS mature to Level 2. We are still committed to complete implementations of the Recommendations of the W3C in this area (CSS and HTML and the DOM).

May I have one (1) more change? Please? Then I would make IE7 support TrueType downloadable fonts. Microsoft's record in fonts isn't that bad. They made their core fonts available for anyone to use, and IE supports downloadable fonts. Unfortunately, only the proprietary EOT format is supported. A few lines of code would be sufficient to support zipped TrueType fonts as well, and this would unleash a new wave of typography on the web. (To protect yourself, make sure you use a browser where author style sheets can be turned off — Shift-G in Opera). > As a bonus question: What do you think of Slashdot's CSS? ;)

The new design looks great! The style sheets behind the scene are more complex than what the average web page needs. But, we wouldn't expect anything average from Slashdot, would we?

> 6)  Opera
 > by taskforce
 >
 > Opera 9.0 seems to offer a lot of decent additions to Opera's
 > standards pool. How satisfied are you personally with the work the
 > team has done on implementing standards, and is there anything in
 > there you feel is superflous and anything you would have preferred
 > to see which wasn't in there?

I'm very proud of the standards support in Opera 9. Acid2 is an obvious favorite of mine and seeing that smiley face makes me very happy.

Among the more experimental features is support for Audio in HTML5. Web applications can now make sounds in a sensible way! Combined with the canvas element, developers can create Flash-like content without resorting to a proprietary format.

Having support for Bittorrent is also great. From a technical point of view, it makes much sense. Also, it's a political statement of sorts.

During the development of Opera9. Geir Ivarsøy, who founded Opera with Jon von Tetzchner, died after fighting cancer for years. Geir did a spectacular initial CSS implementation in Opera, thus convincing me to join the company. In music, the 9th is legendary. Beethoven, Schubert, Bruckner and Mahler all did 9 symphonies. Opera 9 was Geir's last symphony.

> Included styles, aliases
 > by Spy der Mann
 >
 > I always wanted to have "included" substyles or "aliases" in my
 > CSS definition, to save redundancy.
 >
 > (For includes)
 >
 >     .class1 { color:#ff0000; }
 >     .class2 { background-color:#ffffff; }
 >     .class3 { include:class1,class2;font-weight:bold; }
 >
 > (For aliases)
 >
 >     @alias color1 #ff0000;
 >     @alias color2 #ffffff;
 >     @alias default_image url('/img/image1.jpg');
 >
 >     .class1 { color:color1; }
 >     .class2 { background-image:default_image;background-color:co lor2; }
 >
 > This way we could change colors or images for a whole webpage
 > by editing a reduced number of lines.
 >
 > Had you considered any of these ideas in the past? If so,
 > why were they rejected?

Yes, aliases and constants have been considered. As David Wheeler noted, "Any problem in computer science can be solved with another layer of indirection."

CSS is already an indirection. Instead of putting properties and values directly on elements, it associates properties and values with selectors. What you (and others) are proposing is to add another layer of indirection. By doing so, one could possible write shorter, more manageable style sheets. However, there are also some downsides. It requires a new syntactic construct (@alias) and implementations must be able to remember a list of aliases. What if aliases are defined in one style sheet and referenced in another -- should that work? If so, what if the first style sheet isn't available?

For CSS1, the downsides of aliases were considered more significant than the benefits.

 > Definition of pixel
 > by Sara Chan
 >
 > The word pixel meant "picture element", but CSS redefined it
 >to mean something quite different (a particular subtended angle
 >of view [w3.org]). This causes confusion: CSS pixels are not pixels.
 >(Indeed, I have seen misinformed comments on Slashdot due to
 >that confusion.)
 >
 > My question is this: why call the subtended angle a "pixel", instead of
 >something else (e.g. "subangle")? If CSS wanted to use the subtended
 >angle for something, that is fine, but calling it a pixel seems to follow
 >the approach of Humpty Dumpty "When I use a word, it means just
 >what I choose it to mean".

In most cases, a CSS pixel will be equal to a device pixel. But, as you point out, the definition of a CSS pixel will sometimes be different. For example, on a laser printer, one CSS pixel can be equal to 3x3 device pixels to avoid printing illegibly small text and images. I don't recall anyone ever proposing another name for it. Subangle? Personally, I think most people would prefer the pragmatic "px" to the non-intuitive "sa".

> Vertical CSS Support
 > by infestedsenses
 >
 > As a developer who works with CSS every day, I find one
 > complication that continues to bother me in my daily work.
 > Support for CSS has always been good on the horizontal scope,
 > but vertical positioning has always been quite complicated.
 > Alone the procedure to affix a footer to the bottom of a screen
 > in dependance of the amount of content is unnecessarily difficult,
 > spawning hackish solutions such as "footerStickAlt"
 > [themaninblue.com]. Centering an object in the dead center of a
 > page also requires strange procedures such as this one [wpdfd.com],
 > which still aren't ideal (try making the viewport really small). The old
 > table method provided much easier methods for this. What are your
 > thoughts on this and do you see improvement following in future
 > CSS revisions?

Indeed, the CSS formatting model allows more control horizontally than vertically. This is due to (typically) having a known width, but an unknown height. As such, the height is harder to deal with.

However, CSS2 fixed positioning allows you to place content relative to the viewport (which is CSS-speak for window) instead of the document. For example, by setting position: fixed; bottom: 0 on an element, it will stick to the bottom. This works in Opera, Safari and Mozilla-based browsers. IE6 doesn't support it, however. It remains to be seen if IE7 will support it.

> About Microsoft...
 > by Chabil Ha'
 >
 > With MS's next browser release (IE 7), you mentioned in other
 > interviews that their decision to not supprt CSS2 was more a political
 > decision than a mechanical one. Aside from their obvious desire to
 > dominate the world, what politics do you think are in play that make
 > them not want to conform to the standard, and what do you think would
 > change that landscape so that they would have some initiative to
 > fully support it?

Great question. It's quite clear that Microsoft has the resources and talent to support CSS2 fully in IE and that plenty of people have reminded them why this is important. So, why don't they do it? The fundamental reason, I believe, is that standards don't benefit monopolists. Accepted, well-functioning, standards lower the barrier of entry to a market, and is therefore a threat to a monopolist.

From that perspective, it makes sense to leave CSS2 half-implemented. You can claim support (and many journalists will believe you), and you also ensure that no-one can use the unimplemented (or worse: buggily implemented) features of the standard. The only way to change the equation is to remind Microsoft how embarrassing it is to offer a sub-standard browser. And to use better browsers.

Another reason for not making a IE too good is that it will compete with Windows. A modern browser is an application platform; the combination of HTML, JavaScript, CSS and DOM allows developers to target the web instead of Windows, Linux, or Mac.

> From linvir
 > How long since you last used Linux?

I'm using it right now. Ubuntu on a IBM Thinkpad X41 is the environment I live in. Ubuntu rocks -- especially with Opera on top! (And Emacs right underneath.)

 > From Rob T Firefly (844560)
 > Why the curly brackets?

The initial CSS proposal didn't use them, instead relying on newlines to separate statements. TimBL didn't really like that and I therefore borrowed the curly braces from the C programming language. The syntax for comments came along as well. I think it works quite well.

 > why not XML?
 > by slashdot.org
 > Simple question (hopefully simple answer ;-)): why
 > did you not use XML?

The simple answer is that the development of CSS preceded XML by a year or so. However, if XML had been available, would we have used it? Probably not. And I suspect Brendan Eich of JavaScript fame would answer the same way on behalf of his language.

XML is a great syntax for structured data, but not suitable for all languages. Still, I think the SGML-based syntax for the FOSI style sheet language.

 > Padding
 > by Anonymous Coward

 > Why was the decision made to make padding apply outside
 > of the width of a 'box', rather than inside, which would seem
 > to make more sense?

It makes sense in some situations, but not in others. For example, when a child element is set to width: 100%, I don't think it should cover the padding of its parent. The box-sizing property in CSS3 addresses this issue. Ideally, the issue should have been addressed earlier, though.

> by nuzak

 > why not float:

 > DSSSL had this sort of thing solved before HTML even existed,
 > let alone CSS. But scheme is too scary and icky, and the W3C
 > believes in a principle of least power, so CSS has to be fully declarative,
 > static, and crippled until patched later.

You're wrong about DSSSL -- it didn't support floating text (as in having text wrap around images) at all. And the DSSSL specification only became publically available around 1996, years after HTML.

> by MagicM

 > How frustrating is it to write a specification knowing
 > that you're at the browser vendors' mercy?

That's part of the game. I don't think any specification has a birthright to be fully supported by all browsers. There should be healthy competition between different specifications. I believe simple, author-friendly specifications will prevail in this environment.

Microformats are another way of developing new formats. Instead of having to convince browser vendors to support your favorite specification, microformats add semantics to HTML through the CLASS attribute. And style it with CSS.

> New standards
 > by iamsure
 >
 > In your work at Opera, you have clearly paved a path that includes
 > going beyond the W3C standards. Whether it is WhatWG
 > implementations, or new functionality specific to Opera (2dgame),
 > you are pushing into new territory. Can you explain why W3C isn't
 > sufficient, and why efforts at Opera to expand beyond the standards
 > differ from Microsoft's embrace/extend model?

It's a fair question. The WhatWG was set up when it seemed as if W3C didn't care much about browsers anymore. That has definitely changed and work items from WhatWG are now channeled into W3C (e.g., XMLHttpRequest).

At Opera, we sometimes include experimental features before they have been standardized. When this happens they are labeled as such, but we still try to document them. For example, we support some Opera-only CSS properties for XML. If these features gain traction, we are happy to work with other organizations to standardize them. If they don't become popular, the features will most likely disappear.

 > Beyond HTML
 > by pr1000

 > How far can CSS be taken beyond the web page--that is,
 > have generalized or non-web specific features for such things
 > as page formatting or type setting? Do you plan/wish/hope to
 > take it farther than it currently is?

Yes, I think it's possible to take CSS further in several directions. I'm eager to see CSS being used in paper-based publishing and I joined the board of YesLogic — which makes the Prince XML to PDF converter — to make sure they added my favorite features. Bert and I used Prince to generate PDF from HTML and CSS sources for the third edition of our book. W3C just published a new Working Draft which describes features for printing, e.g., footnotes, cross-references, and even generated indexes.

For mobile units, I think Media Queries will be important. For example, they can express that large images should not be sent to mobile devices.

Another great opportunity for CSS is Web Applications. Just like documents, applications need to be styled and CSS is an intrinsic component of AJAX. The "AJAX" name sounds great, but allow me to propose a few alternate spellings that I find more accurate:

• AJACX: Asynchronous JavaScript, CSS and XMLHttpRequest
• ADJACS: Asynchronous DOM, JavaScript and CSS
• ADHJACS: Asynchronous DOM, HTML, JavaScript and CSS
• AJAHCS: Asynchronous JavaScript, HTML and CSS
• AJACS: Asynchronous JavaScript, HTML and CSS

Opera, Mozilla and Safari developers are collaborating in the WHAT WG and in W3C to make sure we have interoperable specifications for AJAX. I mean, ADHJACS.

 > by crush

 > Is the difficulty of producing a layout that consists of
 > three or more columns of equal height justification for
 > adding some new feature to the specification to make this easier?

I don't think so. CSS2 defines a table layout that can be used for this purpose. The problem is, and I'm repeating myself here, that the dominant browser doesn't support it. Adding yet more features to the specification wouldn't help.

 > How come, we um, lie?

Right. My name is, um, a bit troublesome to pronounce in English. But I'm a nice person who generally tells the truth. I often tell non-Norwegians that my first name is pronounced "howcome". That's close, but not quite. It does make for a great email address like howcome@opera.com, though.

So I may be a Lie, but I'm just a little white one :-)

You submitted questions for Håkon Wium Lie on June 20. Today we have his answers, not only to the (+5 moderated) questions we sent him, but to a bunch of others he thought would also be interesting to answer.

 > Where... by bcat24
 >
 > Do you think the W3C development process is too slow? I know that
 > you guys want everything to be perfect, but it seems to take far
 > longer than necessary. CSS 3 shows promise and I wouldn't want it
 > to die a slow death in standardization.

No, I don't think W3C is too slow. W3C isn't the bottleneck, browsers are. The dominant browser on the web hasn't been updated for years, and it doesn't make sense for specifications to get too far ahead. Rather, the CSS Working Group in W3C has focused on specification maintenance and achieving interoperability between implementations. This work is not so glamorous and some people — even within W3C — would prefer if they concentrate on new specifications. However, I think the focus on interoperability (which has resulted in CSS 2.1) has been crucial to the success of CSS.

CSS3 is a set of specifications that are developed more or less independently of each other. The best way to push a specification forward is to implement it. In the past year, we've seen some encouraging CSS3 implementations come along. For example, Mozilla supports multi-column layouts, Opera supports media queries, Prince supports cross-references and Safari supports borders and backgrounds. A few years from now, I think a select group of CSS3 modules will be interoperably supported in all browsers.

 > Why is CSS such a good idea but a pain to use?
 > by rar
 >
 > CSS is clearly very useful for separating style from content. But
 > apparently people tend to have problems when using it for layouts.
 > Would you say this is because people have not yet understood how to
 > properly do layout in CSS, or is it CSS that is lacking in this
 > area? What can be done to improve the situation? --- Would the web
 > benefit from HTML and CSS being complemented with some kind of
 > "layout language"?

I think layout and style should be tackled by the same language and the two are intertwined. Trying to split the two is like splitting the HTML specification in two, one specification describing inline elements and the other describing block elements. It's not worth the effort.

I think CSS is capable of describing beautiful and scalable layouts. The CSS Zen Garden has been a eye-opening showcase of what is possible today. If MS IE had supported CSS tables, another set of layouts would have been possible. So, there is still lots of potential in the existing CSS specifications which should be the next milestone. Beyond that, the CSS Working Group has started work on a new CSS3 module for advanced layout. Feedback is welcome.

 > CSS Evolution!
 > by eieken
 >
 > Is the wave of webpages designed completely in CSS what you
 > intially intended when you came up with CSS? Do you see that
 > changing? Is that good or bad?

I saw a clear need for a web style sheet language when proposing CSS in 1994. I also wanted CSS to fully describe the presentation of a web pages -- not just add some styling. All in all, I think it has turned out quite well. It has taken longer than I expected, but the scale -- due to the growth of the web -- is more than anyone could imagine.

I used "I" too many times in the previous paragraph. It's important to realize that CSS is a community effort rather that one man's work. Bert Bos joined me early and we worked out the initial designs on a whiteboard during the summer of 1995. The www-style mailing lists and the W3C CSS Working Group have also been crucial in ensuring the success of CSS.

If you're interested in the history of web style sheets, you'll find plenty of material in my PhD thesis on the subject.

 > Two questions (cut to 1.5 by editor Roblimo)
 > by Dolda2000

 > If you were allowed (perhaps by court order, which wouldn't be
 > unthinkable) to force Microsoft to do one (1) change in Internet
 > Explorer, what would that be?

I would force them to support one (1) single web page before shipping IE7, namely Acid2. By using a tiny amount of resources to get Acid2 right, Microsoft can save web designers and users endless amounts of frustration in the future. It would also be an honorable thing to do. This is what Microsoft's W3C representative wrote in 1998:

Microsoft has a deep commitment to working with the W3C on HTML and CSS. We have the first commercial implementation of HTML4, we were the first vendor anywhere to implement even portions of CSS, and we have put a tremendous amount of energy into seeing CSS mature to Level 2. We are still committed to complete implementations of the Recommendations of the W3C in this area (CSS and HTML and the DOM).

May I have one (1) more change? Please? Then I would make IE7 support TrueType downloadable fonts. Microsoft's record in fonts isn't that bad. They made their core fonts available for anyone to use, and IE supports downloadable fonts. Unfortunately, only the proprietary EOT format is supported. A few lines of code would be sufficient to support zipped TrueType fonts as well, and this would unleash a new wave of typography on the web. (To protect yourself, make sure you use a browser where author style sheets can be turned off — Shift-G in Opera). > As a bonus question: What do you think of Slashdot's CSS? ;)

The new design looks great! The style sheets behind the scene are more complex than what the average web page needs. But, we wouldn't expect anything average from Slashdot, would we?

> 6)  Opera
 > by taskforce
 >
 > Opera 9.0 seems to offer a lot of decent additions to Opera's
 > standards pool. How satisfied are you personally with the work the
 > team has done on implementing standards, and is there anything in
 > there you feel is superflous and anything you would have preferred
 > to see which wasn't in there?

I'm very proud of the standards support in Opera 9. Acid2 is an obvious favorite of mine and seeing that smiley face makes me very happy.

Among the more experimental features is support for Audio in HTML5. Web applications can now make sounds in a sensible way! Combined with the canvas element, developers can create Flash-like content without resorting to a proprietary format.

Having support for Bittorrent is also great. From a technical point of view, it makes much sense. Also, it's a political statement of sorts.

During the development of Opera9. Geir Ivarsøy, who founded Opera with Jon von Tetzchner, died after fighting cancer for years. Geir did a spectacular initial CSS implementation in Opera, thus convincing me to join the company. In music, the 9th is legendary. Beethoven, Schubert, Bruckner and Mahler all did 9 symphonies. Opera 9 was Geir's last symphony.

> Included styles, aliases
 > by Spy der Mann
 >
 > I always wanted to have "included" substyles or "aliases" in my
 > CSS definition, to save redundancy.
 >
 > (For includes)
 >
 >     .class1 { color:#ff0000; }
 >     .class2 { background-color:#ffffff; }
 >     .class3 { include:class1,class2;font-weight:bold; }
 >
 > (For aliases)
 >
 >     @alias color1 #ff0000;
 >     @alias color2 #ffffff;
 >     @alias default_image url('/img/image1.jpg');
 >
 >     .class1 { color:color1; }
 >     .class2 { background-image:default_image;background-color:co lor2; }
 >
 > This way we could change colors or images for a whole webpage
 > by editing a reduced number of lines.
 >
 > Had you considered any of these ideas in the past? If so,
 > why were they rejected?

Yes, aliases and constants have been considered. As David Wheeler noted, "Any problem in computer science can be solved with another layer of indirection."

CSS is already an indirection. Instead of putting properties and values directly on elements, it associates properties and values with selectors. What you (and others) are proposing is to add another layer of indirection. By doing so, one could possible write shorter, more manageable style sheets. However, there are also some downsides. It requires a new syntactic construct (@alias) and implementations must be able to remember a list of aliases. What if aliases are defined in one style sheet and referenced in another -- should that work? If so, what if the first style sheet isn't available?

For CSS1, the downsides of aliases were considered more significant than the benefits.

 > Definition of pixel
 > by Sara Chan
 >
 > The word pixel meant "picture element", but CSS redefined it
 >to mean something quite different (a particular subtended angle
 >of view [w3.org]). This causes confusion: CSS pixels are not pixels.
 >(Indeed, I have seen misinformed comments on Slashdot due to
 >that confusion.)
 >
 > My question is this: why call the subtended angle a "pixel", instead of
 >something else (e.g. "subangle")? If CSS wanted to use the subtended
 >angle for something, that is fine, but calling it a pixel seems to follow
 >the approach of Humpty Dumpty "When I use a word, it means just
 >what I choose it to mean".

In most cases, a CSS pixel will be equal to a device pixel. But, as you point out, the definition of a CSS pixel will sometimes be different. For example, on a laser printer, one CSS pixel can be equal to 3x3 device pixels to avoid printing illegibly small text and images. I don't recall anyone ever proposing another name for it. Subangle? Personally, I think most people would prefer the pragmatic "px" to the non-intuitive "sa".

> Vertical CSS Support
 > by infestedsenses
 >
 > As a developer who works with CSS every day, I find one
 > complication that continues to bother me in my daily work.
 > Support for CSS has always been good on the horizontal scope,
 > but vertical positioning has always been quite complicated.
 > Alone the procedure to affix a footer to the bottom of a screen
 > in dependance of the amount of content is unnecessarily difficult,
 > spawning hackish solutions such as "footerStickAlt"
 > [themaninblue.com]. Centering an object in the dead center of a
 > page also requires strange procedures such as this one [wpdfd.com],
 > which still aren't ideal (try making the viewport really small). The old
 > table method provided much easier methods for this. What are your
 > thoughts on this and do you see improvement following in future
 > CSS revisions?

Indeed, the CSS formatting model allows more control horizontally than vertically. This is due to (typically) having a known width, but an unknown height. As such, the height is harder to deal with.

However, CSS2 fixed positioning allows you to place content relative to the viewport (which is CSS-speak for window) instead of the document. For example, by setting position: fixed; bottom: 0 on an element, it will stick to the bottom. This works in Opera, Safari and Mozilla-based browsers. IE6 doesn't support it, however. It remains to be seen if IE7 will support it.

> About Microsoft...
 > by Chabil Ha'
 >
 > With MS's next browser release (IE 7), you mentioned in other
 > interviews that their decision to not supprt CSS2 was more a political
 > decision than a mechanical one. Aside from their obvious desire to
 > dominate the world, what politics do you think are in play that make
 > them not want to conform to the standard, and what do you think would
 > change that landscape so that they would have some initiative to
 > fully support it?

Great question. It's quite clear that Microsoft has the resources and talent to support CSS2 fully in IE and that plenty of people have reminded them why this is important. So, why don't they do it? The fundamental reason, I believe, is that standards don't benefit monopolists. Accepted, well-functioning, standards lower the barrier of entry to a market, and is therefore a threat to a monopolist.

From that perspective, it makes sense to leave CSS2 half-implemented. You can claim support (and many journalists will believe you), and you also ensure that no-one can use the unimplemented (or worse: buggily implemented) features of the standard. The only way to change the equation is to remind Microsoft how embarrassing it is to offer a sub-standard browser. And to use better browsers.

Another reason for not making a IE too good is that it will compete with Windows. A modern browser is an application platform; the combination of HTML, JavaScript, CSS and DOM allows developers to target the web instead of Windows, Linux, or Mac.

> From linvir
 > How long since you last used Linux?

I'm using it right now. Ubuntu on a IBM Thinkpad X41 is the environment I live in. Ubuntu rocks -- especially with Opera on top! (And Emacs right underneath.)

 > From Rob T Firefly (844560)
 > Why the curly brackets?

The initial CSS proposal didn't use them, instead relying on newlines to separate statements. TimBL didn't really like that and I therefore borrowed the curly braces from the C programming language. The syntax for comments came along as well. I think it works quite well.

 > why not XML?
 > by slashdot.org
 > Simple question (hopefully simple answer ;-)): why
 > did you not use XML?

The simple answer is that the development of CSS preceded XML by a year or so. However, if XML had been available, would we have used it? Probably not. And I suspect Brendan Eich of JavaScript fame would answer the same way on behalf of his language.

XML is a great syntax for structured data, but not suitable for all languages. Still, I think the SGML-based syntax for the FOSI style sheet language.

 > Padding
 > by Anonymous Coward

 > Why was the decision made to make padding apply outside
 > of the width of a 'box', rather than inside, which would seem
 > to make more sense?

It makes sense in some situations, but not in others. For example, when a child element is set to width: 100%, I don't think it should cover the padding of its parent. The box-sizing property in CSS3 addresses this issue. Ideally, the issue should have been addressed earlier, though.

> by nuzak

 > why not float:

 > DSSSL had this sort of thing solved before HTML even existed,
 > let alone CSS. But scheme is too scary and icky, and the W3C
 > believes in a principle of least power, so CSS has to be fully declarative,
 > static, and crippled until patched later.

You're wrong about DSSSL -- it didn't support floating text (as in having text wrap around images) at all. And the DSSSL specification only became publically available around 1996, years after HTML.

> by MagicM

 > How frustrating is it to write a specification knowing
 > that you're at the browser vendors' mercy?

That's part of the game. I don't think any specification has a birthright to be fully supported by all browsers. There should be healthy competition between different specifications. I believe simple, author-friendly specifications will prevail in this environment.

Microformats are another way of developing new formats. Instead of having to convince browser vendors to support your favorite specification, microformats add semantics to HTML through the CLASS attribute. And style it with CSS.

> New standards
 > by iamsure
 >
 > In your work at Opera, you have clearly paved a path that includes
 > going beyond the W3C standards. Whether it is WhatWG
 > implementations, or new functionality specific to Opera (2dgame),
 > you are pushing into new territory. Can you explain why W3C isn't
 > sufficient, and why efforts at Opera to expand beyond the standards
 > differ from Microsoft's embrace/extend model?

It's a fair question. The WhatWG was set up when it seemed as if W3C didn't care much about browsers anymore. That has definitely changed and work items from WhatWG are now channeled into W3C (e.g., XMLHttpRequest).

At Opera, we sometimes include experimental features before they have been standardized. When this happens they are labeled as such, but we still try to document them. For example, we support some Opera-only CSS properties for XML. If these features gain traction, we are happy to work with other organizations to standardize them. If they don't become popular, the features will most likely disappear.

 > Beyond HTML
 > by pr1000

 > How far can CSS be taken beyond the web page--that is,
 > have generalized or non-web specific features for such things
 > as page formatting or type setting? Do you plan/wish/hope to
 > take it farther than it currently is?

Yes, I think it's possible to take CSS further in several directions. I'm eager to see CSS being used in paper-based publishing and I joined the board of YesLogic — which makes the Prince XML to PDF converter — to make sure they added my favorite features. Bert and I used Prince to generate PDF from HTML and CSS sources for the third edition of our book. W3C just published a new Working Draft which describes features for printing, e.g., footnotes, cross-references, and even generated indexes.

For mobile units, I think Media Queries will be important. For example, they can express that large images should not be sent to mobile devices.

Another great opportunity for CSS is Web Applications. Just like documents, applications need to be styled and CSS is an intrinsic component of AJAX. The "AJAX" name sounds great, but allow me to propose a few alternate spellings that I find more accurate:

• AJACX: Asynchronous JavaScript, CSS and XMLHttpRequest
• ADJACS: Asynchronous DOM, JavaScript and CSS
• ADHJACS: Asynchronous DOM, HTML, JavaScript and CSS
• AJAHCS: Asynchronous JavaScript, HTML and CSS
• AJACS: Asynchronous JavaScript, HTML and CSS

Opera, Mozilla and Safari developers are collaborating in the WHAT WG and in W3C to make sure we have interoperable specifications for AJAX. I mean, ADHJACS.

 > by crush

 > Is the difficulty of producing a layout that consists of
 > three or more columns of equal height justification for
 > adding some new feature to the specification to make this easier?

I don't think so. CSS2 defines a table layout that can be used for this purpose. The problem is, and I'm repeating myself here, that the dominant browser doesn't support it. Adding yet more features to the specification wouldn't help.

 > How come, we um, lie?

Right. My name is, um, a bit troublesome to pronounce in English. But I'm a nice person who generally tells the truth. I often tell non-Norwegians that my first name is pronounced "howcome". That's close, but not quite. It does make for a great email address like howcome@opera.com, though.

So I may be a Lie, but I'm just a little white one :-)

You submitted questions for Håkon Wium Lie on June 20. Today we have his answers, not only to the (+5 moderated) questions we sent him, but to a bunch of others he thought would also be interesting to answer.

 > Where... by bcat24
 >
 > Do you think the W3C development process is too slow? I know that
 > you guys want everything to be perfect, but it seems to take far
 > longer than necessary. CSS 3 shows promise and I wouldn't want it
 > to die a slow death in standardization.

No, I don't think W3C is too slow. W3C isn't the bottleneck, browsers are. The dominant browser on the web hasn't been updated for years, and it doesn't make sense for specifications to get too far ahead. Rather, the CSS Working Group in W3C has focused on specification maintenance and achieving interoperability between implementations. This work is not so glamorous and some people — even within W3C — would prefer if they concentrate on new specifications. However, I think the focus on interoperability (which has resulted in CSS 2.1) has been crucial to the success of CSS.

CSS3 is a set of specifications that are developed more or less independently of each other. The best way to push a specification forward is to implement it. In the past year, we've seen some encouraging CSS3 implementations come along. For example, Mozilla supports multi-column layouts, Opera supports media queries, Prince supports cross-references and Safari supports borders and backgrounds. A few years from now, I think a select group of CSS3 modules will be interoperably supported in all browsers.

 > Why is CSS such a good idea but a pain to use?
 > by rar
 >
 > CSS is clearly very useful for separating style from content. But
 > apparently people tend to have problems when using it for layouts.
 > Would you say this is because people have not yet understood how to
 > properly do layout in CSS, or is it CSS that is lacking in this
 > area? What can be done to improve the situation? --- Would the web
 > benefit from HTML and CSS being complemented with some kind of
 > "layout language"?

I think layout and style should be tackled by the same language and the two are intertwined. Trying to split the two is like splitting the HTML specification in two, one specification describing inline elements and the other describing block elements. It's not worth the effort.

I think CSS is capable of describing beautiful and scalable layouts. The CSS Zen Garden has been a eye-opening showcase of what is possible today. If MS IE had supported CSS tables, another set of layouts would have been possible. So, there is still lots of potential in the existing CSS specifications which should be the next milestone. Beyond that, the CSS Working Group has started work on a new CSS3 module for advanced layout. Feedback is welcome.

 > CSS Evolution!
 > by eieken
 >
 > Is the wave of webpages designed completely in CSS what you
 > intially intended when you came up with CSS? Do you see that
 > changing? Is that good or bad?

I saw a clear need for a web style sheet language when proposing CSS in 1994. I also wanted CSS to fully describe the presentation of a web pages -- not just add some styling. All in all, I think it has turned out quite well. It has taken longer than I expected, but the scale -- due to the growth of the web -- is more than anyone could imagine.

I used "I" too many times in the previous paragraph. It's important to realize that CSS is a community effort rather that one man's work. Bert Bos joined me early and we worked out the initial designs on a whiteboard during the summer of 1995. The www-style mailing lists and the W3C CSS Working Group have also been crucial in ensuring the success of CSS.

If you're interested in the history of web style sheets, you'll find plenty of material in my PhD thesis on the subject.

 > Two questions (cut to 1.5 by editor Roblimo)
 > by Dolda2000

 > If you were allowed (perhaps by court order, which wouldn't be
 > unthinkable) to force Microsoft to do one (1) change in Internet
 > Explorer, what would that be?

I would force them to support one (1) single web page before shipping IE7, namely Acid2. By using a tiny amount of resources to get Acid2 right, Microsoft can save web designers and users endless amounts of frustration in the future. It would also be an honorable thing to do. This is what Microsoft's W3C representative wrote in 1998:

Microsoft has a deep commitment to working with the W3C on HTML and CSS. We have the first commercial implementation of HTML4, we were the first vendor anywhere to implement even portions of CSS, and we have put a tremendous amount of energy into seeing CSS mature to Level 2. We are still committed to complete implementations of the Recommendations of the W3C in this area (CSS and HTML and the DOM).

May I have one (1) more change? Please? Then I would make IE7 support TrueType downloadable fonts. Microsoft's record in fonts isn't that bad. They made their core fonts available for anyone to use, and IE supports downloadable fonts. Unfortunately, only the proprietary EOT format is supported. A few lines of code would be sufficient to support zipped TrueType fonts as well, and this would unleash a new wave of typography on the web. (To protect yourself, make sure you use a browser where author style sheets can be turned off — Shift-G in Opera). > As a bonus question: What do you think of Slashdot's CSS? ;)

The new design looks great! The style sheets behind the scene are more complex than what the average web page needs. But, we wouldn't expect anything average from Slashdot, would we?

> 6)  Opera
 > by taskforce
 >
 > Opera 9.0 seems to offer a lot of decent additions to Opera's
 > standards pool. How satisfied are you personally with the work the
 > team has done on implementing standards, and is there anything in
 > there you feel is superflous and anything you would have preferred
 > to see which wasn't in there?

I'm very proud of the standards support in Opera 9. Acid2 is an obvious favorite of mine and seeing that smiley face makes me very happy.

Among the more experimental features is support for Audio in HTML5. Web applications can now make sounds in a sensible way! Combined with the canvas element, developers can create Flash-like content without resorting to a proprietary format.

Having support for Bittorrent is also great. From a technical point of view, it makes much sense. Also, it's a political statement of sorts.

During the development of Opera9. Geir Ivarsøy, who founded Opera with Jon von Tetzchner, died after fighting cancer for years. Geir did a spectacular initial CSS implementation in Opera, thus convincing me to join the company. In music, the 9th is legendary. Beethoven, Schubert, Bruckner and Mahler all did 9 symphonies. Opera 9 was Geir's last symphony.

> Included styles, aliases
 > by Spy der Mann
 >
 > I always wanted to have "included" substyles or "aliases" in my
 > CSS definition, to save redundancy.
 >
 > (For includes)
 >
 >     .class1 { color:#ff0000; }
 >     .class2 { background-color:#ffffff; }
 >     .class3 { include:class1,class2;font-weight:bold; }
 >
 > (For aliases)
 >
 >     @alias color1 #ff0000;
 >     @alias color2 #ffffff;
 >     @alias default_image url('/img/image1.jpg');
 >
 >     .class1 { color:color1; }
 >     .class2 { background-image:default_image;background-color:co lor2; }
 >
 > This way we could change colors or images for a whole webpage
 > by editing a reduced number of lines.
 >
 > Had you considered any of these ideas in the past? If so,
 > why were they rejected?

Yes, aliases and constants have been considered. As David Wheeler noted, "Any problem in computer science can be solved with another layer of indirection."

CSS is already an indirection. Instead of putting properties and values directly on elements, it associates properties and values with selectors. What you (and others) are proposing is to add another layer of indirection. By doing so, one could possible write shorter, more manageable style sheets. However, there are also some downsides. It requires a new syntactic construct (@alias) and implementations must be able to remember a list of aliases. What if aliases are defined in one style sheet and referenced in another -- should that work? If so, what if the first style sheet isn't available?

For CSS1, the downsides of aliases were considered more significant than the benefits.

 > Definition of pixel
 > by Sara Chan
 >
 > The word pixel meant "picture element", but CSS redefined it
 >to mean something quite different (a particular subtended angle
 >of view [w3.org]). This causes confusion: CSS pixels are not pixels.
 >(Indeed, I have seen misinformed comments on Slashdot due to
 >that confusion.)
 >
 > My question is this: why call the subtended angle a "pixel", instead of
 >something else (e.g. "subangle")? If CSS wanted to use the subtended
 >angle for something, that is fine, but calling it a pixel seems to follow
 >the approach of Humpty Dumpty "When I use a word, it means just
 >what I choose it to mean".

In most cases, a CSS pixel will be equal to a device pixel. But, as you point out, the definition of a CSS pixel will sometimes be different. For example, on a laser printer, one CSS pixel can be equal to 3x3 device pixels to avoid printing illegibly small text and images. I don't recall anyone ever proposing another name for it. Subangle? Personally, I think most people would prefer the pragmatic "px" to the non-intuitive "sa".

> Vertical CSS Support
 > by infestedsenses
 >
 > As a developer who works with CSS every day, I find one
 > complication that continues to bother me in my daily work.
 > Support for CSS has always been good on the horizontal scope,
 > but vertical positioning has always been quite complicated.
 > Alone the procedure to affix a footer to the bottom of a screen
 > in dependance of the amount of content is unnecessarily difficult,
 > spawning hackish solutions such as "footerStickAlt"
 > [themaninblue.com]. Centering an object in the dead center of a
 > page also requires strange procedures such as this one [wpdfd.com],
 > which still aren't ideal (try making the viewport really small). The old
 > table method provided much easier methods for this. What are your
 > thoughts on this and do you see improvement following in future
 > CSS revisions?

Indeed, the CSS formatting model allows more control horizontally than vertically. This is due to (typically) having a known width, but an unknown height. As such, the height is harder to deal with.

However, CSS2 fixed positioning allows you to place content relative to the viewport (which is CSS-speak for window) instead of the document. For example, by setting position: fixed; bottom: 0 on an element, it will stick to the bottom. This works in Opera, Safari and Mozilla-based browsers. IE6 doesn't support it, however. It remains to be seen if IE7 will support it.

> About Microsoft...
 > by Chabil Ha'
 >
 > With MS's next browser release (IE 7), you mentioned in other
 > interviews that their decision to not supprt CSS2 was more a political
 > decision than a mechanical one. Aside from their obvious desire to
 > dominate the world, what politics do you think are in play that make
 > them not want to conform to the standard, and what do you think would
 > change that landscape so that they would have some initiative to
 > fully support it?

Great question. It's quite clear that Microsoft has the resources and talent to support CSS2 fully in IE and that plenty of people have reminded them why this is important. So, why don't they do it? The fundamental reason, I believe, is that standards don't benefit monopolists. Accepted, well-functioning, standards lower the barrier of entry to a market, and is therefore a threat to a monopolist.

From that perspective, it makes sense to leave CSS2 half-implemented. You can claim support (and many journalists will believe you), and you also ensure that no-one can use the unimplemented (or worse: buggily implemented) features of the standard. The only way to change the equation is to remind Microsoft how embarrassing it is to offer a sub-standard browser. And to use better browsers.

Another reason for not making a IE too good is that it will compete with Windows. A modern browser is an application platform; the combination of HTML, JavaScript, CSS and DOM allows developers to target the web instead of Windows, Linux, or Mac.

> From linvir
 > How long since you last used Linux?

I'm using it right now. Ubuntu on a IBM Thinkpad X41 is the environment I live in. Ubuntu rocks -- especially with Opera on top! (And Emacs right underneath.)

 > From Rob T Firefly (844560)
 > Why the curly brackets?

The initial CSS proposal didn't use them, instead relying on newlines to separate statements. TimBL didn't really like that and I therefore borrowed the curly braces from the C programming language. The syntax for comments came along as well. I think it works quite well.

 > why not XML?
 > by slashdot.org
 > Simple question (hopefully simple answer ;-)): why
 > did you not use XML?

The simple answer is that the development of CSS preceded XML by a year or so. However, if XML had been available, would we have used it? Probably not. And I suspect Brendan Eich of JavaScript fame would answer the same way on behalf of his language.

XML is a great syntax for structured data, but not suitable for all languages. Still, I think the SGML-based syntax for the FOSI style sheet language.

 > Padding
 > by Anonymous Coward

 > Why was the decision made to make padding apply outside
 > of the width of a 'box', rather than inside, which would seem
 > to make more sense?

It makes sense in some situations, but not in others. For example, when a child element is set to width: 100%, I don't think it should cover the padding of its parent. The box-sizing property in CSS3 addresses this issue. Ideally, the issue should have been addressed earlier, though.

> by nuzak

 > why not float:

 > DSSSL had this sort of thing solved before HTML even existed,
 > let alone CSS. But scheme is too scary and icky, and the W3C
 > believes in a principle of least power, so CSS has to be fully declarative,
 > static, and crippled until patched later.

You're wrong about DSSSL -- it didn't support floating text (as in having text wrap around images) at all. And the DSSSL specification only became publically available around 1996, years after HTML.

> by MagicM

 > How frustrating is it to write a specification knowing
 > that you're at the browser vendors' mercy?

That's part of the game. I don't think any specification has a birthright to be fully supported by all browsers. There should be healthy competition between different specifications. I believe simple, author-friendly specifications will prevail in this environment.

Microformats are another way of developing new formats. Instead of having to convince browser vendors to support your favorite specification, microformats add semantics to HTML through the CLASS attribute. And style it with CSS.

> New standards
 > by iamsure
 >
 > In your work at Opera, you have clearly paved a path that includes
 > going beyond the W3C standards. Whether it is WhatWG
 > implementations, or new functionality specific to Opera (2dgame),
 > you are pushing into new territory. Can you explain why W3C isn't
 > sufficient, and why efforts at Opera to expand beyond the standards
 > differ from Microsoft's embrace/extend model?

It's a fair question. The WhatWG was set up when it seemed as if W3C didn't care much about browsers anymore. That has definitely changed and work items from WhatWG are now channeled into W3C (e.g., XMLHttpRequest).

At Opera, we sometimes include experimental features before they have been standardized. When this happens they are labeled as such, but we still try to document them. For example, we support some Opera-only CSS properties for XML. If these features gain traction, we are happy to work with other organizations to standardize them. If they don't become popular, the features will most likely disappear.

 > Beyond HTML
 > by pr1000

 > How far can CSS be taken beyond the web page--that is,
 > have generalized or non-web specific features for such things
 > as page formatting or type setting? Do you plan/wish/hope to
 > take it farther than it currently is?

Yes, I think it's possible to take CSS further in several directions. I'm eager to see CSS being used in paper-based publishing and I joined the board of YesLogic — which makes the Prince XML to PDF converter — to make sure they added my favorite features. Bert and I used Prince to generate PDF from HTML and CSS sources for the third edition of our book. W3C just published a new Working Draft which describes features for printing, e.g., footnotes, cross-references, and even generated indexes.

For mobile units, I think Media Queries will be important. For example, they can express that large images should not be sent to mobile devices.

Another great opportunity for CSS is Web Applications. Just like documents, applications need to be styled and CSS is an intrinsic component of AJAX. The "AJAX" name sounds great, but allow me to propose a few alternate spellings that I find more accurate:

• AJACX: Asynchronous JavaScript, CSS and XMLHttpRequest
• ADJACS: Asynchronous DOM, JavaScript and CSS
• ADHJACS: Asynchronous DOM, HTML, JavaScript and CSS
• AJAHCS: Asynchronous JavaScript, HTML and CSS
• AJACS: Asynchronous JavaScript, HTML and CSS

Opera, Mozilla and Safari developers are collaborating in the WHAT WG and in W3C to make sure we have interoperable specifications for AJAX. I mean, ADHJACS.

 > by crush

 > Is the difficulty of producing a layout that consists of
 > three or more columns of equal height justification for
 > adding some new feature to the specification to make this easier?

I don't think so. CSS2 defines a table layout that can be used for this purpose. The problem is, and I'm repeating myself here, that the dominant browser doesn't support it. Adding yet more features to the specification wouldn't help.

 > How come, we um, lie?

Right. My name is, um, a bit troublesome to pronounce in English. But I'm a nice person who generally tells the truth. I often tell non-Norwegians that my first name is pronounced "howcome". That's close, but not quite. It does make for a great email address like howcome@opera.com, though.

So I may be a Lie, but I'm just a little white one :-)

Back in 1994, while working for the World Wide Web Consortium (W3C), Håkon Wium Lie (pronounced more or less "how come") proposed the idea of Cascading Style Sheets (CSS). Got a CSS question? An Ajax question? Want to know why Håkon loves Free Software so much? Or something else, related or not? Go ahead and ask -- after checking some of the links above, so you don't duplicate questions he's answered in other interviews or in articles he's written. (One question per post, please.) We hope to post his answers Friday.

Back in 1994, while working for the World Wide Web Consortium (W3C), Håkon Wium Lie (pronounced more or less "how come") proposed the idea of Cascading Style Sheets (CSS). Got a CSS question? An Ajax question? Want to know why Håkon loves Free Software so much? Or something else, related or not? Go ahead and ask -- after checking some of the links above, so you don't duplicate questions he's answered in other interviews or in articles he's written. (One question per post, please.) We hope to post his answers Friday.

Nurgled writes "After teasing us for months with betas and snapshots, Opera Software have finally released version 9.0 of their web browser. The new version features correct ACID2 rendering, native support for the SVG Basic profile, a built-in BitTorrent client, support for Microsoft's designmode and contenteditable extensions, per-site configuration, Atom support, Web Forms 2.0 support, Canvas support (and some Opera-specific extensions), NTLM authentication, some support of parts of CSS3 and lots more. The full changelog is available." p14nd4 adds "And for you *nix users, it hasn't hit their .deb repository quite yet, but there are regular installers available for the major players, including a fixed Ubuntu installer and an x86 Solaris version."

eldavojohn wonders: " Do W3C standards hold any importance to anyone and if so, why? When you finish a website, do you run it to the validator to laugh and take bets, or do you e-mail the results to the office intern and tell him/her to get to work? Since Opera 9 is the only browser to pass the ACID2 test, is strict compliance really necessary?" We all know that standards are important, but there has always been a distance between what is put forth by the W3C and what we get from our browsers. Microsoft has yet to release a browser that comes close to supporting standards (and it remains to be seen if IE7 will change this). Mozilla, although supportive, is still a ways from ACID2 compliance. Web developers are therefore faced with a difficult decision: do they develop their content to the standards, or to the browsers that will render it? As web developers (or the manager of web developers), what decisions did you made on your projects? Update: 05/20 by C : rgmisra provides a minor correction to the information provided. It is stated above that Opera9 is the only browser to pass the ACID2 test, however "This is not true - Safari was the first released publicly released browser to pass the ACID2 tests." -- Sorry about the mistake.

An anonymous reader writes " Corante's Copyfight has a piece up about this new column in the Financial Times by James Boyle celebrating (a few days on the early side) the 15th anniversary of Berners-Lee's first draft of a web page . The hook is this question: What would happen if the Web were invented today? From the article: 'What would a web designed by the World Intellectual Property Organisation or the Disney Corporation have looked like? It would have looked more like pay-television, or Minitel, the French computer network. Beforehand, the logic of control always makes sense. Allow anyone to connect to the network? Anyone to decide what content to put up? That is a recipe for piracy and pornography. And of course it is. But it is also much, much more...The lawyers have learnt their lesson now...When the next disruptive communications technology - the next worldwide web - is thought up, the lawyers and the logic of control will be much more evident. That is not a happy thought.'"

An anonymous reader writes " Corante's Copyfight has a piece up about this new column in the Financial Times by James Boyle celebrating (a few days on the early side) the 15th anniversary of Berners-Lee's first draft of a web page . The hook is this question: What would happen if the Web were invented today? From the article: 'What would a web designed by the World Intellectual Property Organisation or the Disney Corporation have looked like? It would have looked more like pay-television, or Minitel, the French computer network. Beforehand, the logic of control always makes sense. Allow anyone to connect to the network? Anyone to decide what content to put up? That is a recipe for piracy and pornography. And of course it is. But it is also much, much more...The lawyers have learnt their lesson now...When the next disruptive communications technology - the next worldwide web - is thought up, the lawyers and the logic of control will be much more evident. That is not a happy thought.'"

An anonymous reader writes " Corante's Copyfight has a piece up about this new column in the Financial Times by James Boyle celebrating (a few days on the early side) the 15th anniversary of Berners-Lee's first draft of a web page . The hook is this question: What would happen if the Web were invented today? From the article: 'What would a web designed by the World Intellectual Property Organisation or the Disney Corporation have looked like? It would have looked more like pay-television, or Minitel, the French computer network. Beforehand, the logic of control always makes sense. Allow anyone to connect to the network? Anyone to decide what content to put up? That is a recipe for piracy and pornography. And of course it is. But it is also much, much more...The lawyers have learnt their lesson now...When the next disruptive communications technology - the next worldwide web - is thought up, the lawyers and the logic of control will be much more evident. That is not a happy thought.'"

BarryNorton writes "In a world that increasingly takes the WWW, its pages and the other documents we exchange in the electronic world as given - and knights Tim Berners-Lee without an understanding of the pre-WWW background of stateless client/server document architectures (e.g. Gopher) and hypertext (e.g. Xanadu) on which he built - there still beavers away a forgotten figure, Ted Nelson, eager to more fully achieve the original hypertext vision. In recent communications Nelson says: 'The tekkies have hijacked literature- with the best intentions, of course!-) - but now the humanists have to get it back. Nearly every form of electronic document- Word, Acrobat, HTML, XML- represents some business or ideological agenda. Many believe Word and Acrobat are out to entrap users; HTML and XML enact a very limited kind of hypertext with great internal complexity. All imitate paper and (internally) hierarchy. I propose a different document agenda: I believe we need new electronic documents which are transparent, public, principled, and freed from the traditions of hierarchy and paper. In that case they can be far more powerful, with deep and rich new interconnections and properties- able to quote dynamically from other documents and buckle sideways to other documents, such as comments or successive versions; able to present third-party links; and much more. Most urgently: if we have different document structures we can build a new copyright realm, where everything can be freely and legally quoted and remixed in any amount without negotiation.'"

ikewillis writes "The new beta version of news.com now features an integrated ontology viewer developed in collaboration with LivePlasma who appears to have built a large ontology for music and movies. While they don't appear to provide direct access to the ontological data using semantic web formats like OWL and RDF, it's the first time I've ever seen web ontologies used on such a high profile site. How long until we can expect web ontology viewers (and semantic web integration) for sites like Wikipedia?"

ikewillis writes "The new beta version of news.com now features an integrated ontology viewer developed in collaboration with LivePlasma who appears to have built a large ontology for music and movies. While they don't appear to provide direct access to the ontological data using semantic web formats like OWL and RDF, it's the first time I've ever seen web ontologies used on such a high profile site. How long until we can expect web ontology viewers (and semantic web integration) for sites like Wikipedia?"

ikewillis writes "The new beta version of news.com now features an integrated ontology viewer developed in collaboration with LivePlasma who appears to have built a large ontology for music and movies. While they don't appear to provide direct access to the ontological data using semantic web formats like OWL and RDF, it's the first time I've ever seen web ontologies used on such a high profile site. How long until we can expect web ontology viewers (and semantic web integration) for sites like Wikipedia?"

theodp writes "As predicted earlier on Slashdot, looks like the W3C goofed by shutting out the public and asking the Patent Office to base its reexamination of the Eolas Web Plug-In Patent solely on prior art promoted by Microsoft. The USPTO has reaffirmed the validity of the $521M patent, rejecting the W3C's prior art as deficient for not demonstrating the capability of ongoing real-time manipulation and control by the user. The USPTO also considered but rejected the prior art of the Viola Browser, which formed the basis for Microsoft's appellate argument. Ironically, Eolas' defense was bolstered by the arguments of its expert witness, 2005 EFF Pioneer Award Winner Ed Felten."

conJunk asks: "With Slashdot recently becoming HTML 4.01 compliant, my thoughts now drift to the subject of web accessibility. We all know that the Section 508 requirements are legally binding to those who work for or with the U.S. government, but it's still unclear whether or not U.S. companies are required to have accessible sites (unlike England, where it's very clear). How important are web accessibility and the W3C Accessibility Guidelines to you and/or your company? Where do you see this issue going in the next 10 years?"

Tsar writes "Promethean Personal Software (makers of Sherpa, a code generating tool for db apps) have quietly released ExceptionCollection, a free (as in beer) online service for developers using any SOAP-enabled environment. You sign up on the site, download their component, add three or four lines of code to your app, and any exceptions thrown by your users get logged at ExceptionCollection.com for your later perusal (the last 100 anyway). There are several options, like whether reporting requires user approval. Is this as cool as it looks, or a solution in search of a problem?"

StudMuffin asks: "I teach graduate computer science courses at a Big 10 university to grad students, who have never programmed before and are studying Human-Computer Interaction or other Information Science specialties. These courses are usually their first dip into the programming pool, so we have tons to cover in three months. This fall, I have been asked to take over and redesign our 'Complex Website' course, which is getting a bit long in the tooth. This course has traditionally been about database backed websites with server-side scripting. My only requirements are that there be coverage of PHP and that we have basic instruction about persistence using a database (which must be MySQL). However, I believe that the nature of 'complex' websites has changed, with XHTML, CSS, Javascript, web services, and so on. Sites like Google Maps make the browser feel like a fat client and are making the web browser a true window onto enormous data sets, and take into consideration the MoRAS of small views on large worlds. What do Slashdot readers consider a reasonable curriculum would be for a redesigned course like this?"

ARSDeveloperGuy writes "Fourth generation languages are cool, but there seems to be little to no effort being spent to standardize them. The current state is commercialized pseudo-languages are created to allow vertical apps to be expanded. (ARS Remedy, Siebel, Oracle JDeveloper) The concepts of a form, field, and workflow can be standardized, and when you look at many of these languages they aren't terribly different. Why don't we create a standard and start writing "workflow converters" for these powerful languages? That would allow conversions to happen more readily, maybe even to an open source offering like OpenSourceCRM."

hixie writes " The W3C recently acknowledged a version of the Web Forms 2.0 draft submitted to the W3C by Mozilla and Opera. Meanwhile the WHATWG has updated the Web Forms draft and released a new call for comments. Send them in!"

mOoZik writes "BBC News is reporting that Tim Berners-Lee, the father of the World Wide Web, has been named the Greatest Briton of 2004. Berners-Lee had this to say about the honor: 'I am very proud to be British, it is great fun to be British and this award is just an amazing honour.'"

Spy der Mann writes "Remember the recent discussion on Binary XML? Well, there's news. The W3C just released the specs for XML-binary optimized packaging (XOP). In summary, they take binary data out of the XML, and put it in a separate section using MIME-Multipart. You can read the press release and the testimonials from MS, IBM and BEA."