Slashdot Mirror

It's a browser feature few users will have heard of, but forthcoming versions of Chrome, Safari and Opera are in the process of removing the ability to disable a long-ignored tracking feature called hyperlink auditing pings. From a report: This is a long-established HTML feature that's set as an attribute -- the ping variable -- which turns a link into a URL that can be tracked by website owners or advertisers to monitor what users are clicking on. When a user follows a link set up to work like this, an HTTP POST ping is sent to a second URL which records this interaction without revealing to the user that this has happened. It's only one of several ways users can be tracked, of course, but it's long bothered privacy experts, which is why third-party adblockers often include it on their block list by default.

Until now, an even simpler way to block these pings has been through the browser itself, which in the case of Chrome, Safari and Opera is done by setting a flag (in Chrome you type chrome://flags and set hyperlink auditing to 'disabled'). Notice, however, that these browsers still allow hyperlink auditing by default, which means users would need to know about this setting to change that. It seems that very few do.

x_t0ken_407 quotes BleepingComputer: A HTML standard called hyperlink auditing that allows sites to track link clicks is enabled by default on Safari, Chrome, Opera, and Microsoft Edge, but will soon have no way to disable it. As it is considered a privacy risk, browsers previously allowed you to disable this feature. Now they are going in the opposite direction.

Hyperlink auditing is an HTML standard that allows the creation of special links that ping back to a specified URL when they are clicked on. These pings are done in the form of a POST request to the specified web page that can then examine the request headers to see what page the link was clicked on.
The article concludes that "Firefox and Brave win the award" for people who want this click-tracking capability disabled -- since "only Brave and Firefox currently disable it by default, and do not appear to have any plans on enabling it in the future."

Last week, Ethan Marcotte, an independent web designer, shared how Google describes AMP (Accelerated Mobile Pages). People at Google says AMP "isn't a 'proprietary format'; it's an open standard that anyone can contribute to." But that definition, Marcotte argues, isn't necessarily an honest one. He writes: On the face of it, this statement's true. AMP's markup isn't proprietary as such: rather, all those odd-looking amp- tags are custom elements, part of the HTML standard. And the specification's published, edited, and distributed on GitHub, under one of the more permissive licenses available. So, yes. The HTML standard does allow for the creation of custom elements, it's true, and AMP's license is quite liberal. But spend a bit of time with the rules that outline AMP's governance. Significant features and changes require the approval of AMP's Technical Lead and one Core Committer -- and if you peruse the list of AMP's Core Committers, that list seems exclusively staffed and led by Google employees. Now, there's nothing wrong with this. After all, AMP is a Google-backed project, and they're free to establish any governance model they deem appropriate. But when I hear AMP described as an open, community-led project, it strikes me as incredibly problematic, and more than a little troubling. AMP is, I think, best described as nominally open-source. It's a corporate-led product initiative built with, and distributed on, open web technologies. Jeremy Keith, a web developer, further adds: If AMP were actually the product of working web developers, this justification would make sense. As it is, we've got one team at Google citing the preference of another team at Google but representing it as the will of the people. This is just one example of AMP's sneaky marketing where some finely-shaved semantics allows them to appear far more reasonable than they actually are. At AMP Conf, the Google Search team were at pains to repeat over and over that AMP pages wouldn't get any preferential treatment in search results ... but they appear in a carousel above the search results. Now, if you were to ask any right-thinking person whether they think having their page appear right at the top of a list of search results would be considered preferential treatment, I think they would say hell, yes! This is the only reason why The Guardian, for instance, even have AMP versions of their content -- it's not for the performance benefits (their non-AMP pages are faster); it's for that prime real estate in the carousel. The same semantic nit-picking can be found in their defence of caching. See, they've even got me calling it caching! It's hosting. If I click on a search result, and I am taken to page that has a URL beginning with https://www.google.com/amp/s/... then that page is being hosted on the domain google.com. That is literally what hosting means. Now, you might argue that the original version was hosted on a different domain, but the version that the user gets sent to is the Google copy. You can call it caching if you like, but you can't tell me that Google aren't hosting AMP pages. That's a particularly low blow, because it's such a bait'n'switch.

Krystalo quotes a report from VentureBeat: Google today launched Chrome 54 for Windows, Mac, and Linux. This release is mainly focused on developers, but the improvements to how the browser handles YouTube embeds is also noteworthy. You can update to the latest version now using the browser's built-in silent updater, or download it directly from google.com/chrome. Chrome 54 rewrites YouTube Flash players to use the YouTube HTML5 embed style. YouTube ditched Flash for HTML5 by default in January 2015, but the old embeds still exist all over the web. Google says the change improves both performance and security for its desktop browser. The report adds that "Chrome also now provides support for the custom elements V1 spec," which allows "developers to create custom HTML tags as well as define their API and behavior in JavaScript." BroadcastChannel API will also be implemented "to allow one-to-many messaging between windows, tabs, iframes, web workers, and service workers." You can read more about Chrome 54 on Google's blog post.

An anonymous reader writes: Google today launched Chrome 42 for Windows, Mac, and Linux with new developer tools. Chrome 42 offers two new APIs (Push API and Notifications API) that together allow sites to send notifications to their users even after the given page is closed. While this can be quite an intrusive feature for a browser, Google promises the users have to first grant explicit permission before they receive such a message.

mikejuk writes "Until now the two standards bodies working on HTML5 (WHATWG and W3C) have cooperated. An announcement by WHATWG makes it clear that this is no longer true. WHATWG is going to work on a living standard for HTML which will continue to evolve as more technologies are added. W3C is going the traditional and much more time consuming route of creating a traditional standard which WHATWG refers to as a 'snapshot' of their living standard. Of course now being free of W3C's slower methods WHATWG can accelerate the pace of introducing new technologies to HTML5. Whatever happens, the future has just become more complicated — now you have to ask yourself 'Which HTML5?'"

Esther Schindler writes "Feeling a little overwhelmed by changing web standards and new browser choices? You aren't the only one. Mozilla is launching development tracks for the next two editions of its Firefox Web browser immediately, with hopes to push both into general release before the end of the year. This while Microsoft previews Internet Explorer 10 on the heels of its IE9 release, and Google projects Chrome 13 just one year after Chrome 7. Meanwhile, HTML5, the next version of the Web's primary language, appears to have entered a permanent gestation phase. Writes Scott Fulton: All the confusion has prompted Web developers to ask this question: What do we develop our sites against now?"

Sir Homer writes "The MPEG LA has extended their royalty-free license (PDF) for 'Internet Video that is free to end users' until the end of 2016. This means webmasters who are registered MPEG LA licensees will not have to pay a royalty to stream H.264 video for the next six years. However the last patent in the H.264 portfolio expires in 2028, and the MPEG LA has not released what fees, if any, it will charge webmasters after this 'free trial' period is over."

snydeq writes "Major browser vendors have been unable to agree on an encoding format they will support in their products, forcing the W3C to drop audio and video codecs from HTML 5, the forthcoming W3C spec that has been viewed as a threat to Flash, Silverlight, and similar technologies. 'After an inordinate amount of discussions on the situation, I have reluctantly come to the conclusion that there is no suitable codec that all vendors are willing to implement and ship,' HTML 5 editor Ian Hickson wrote to the whatwg mailing list. Apple, for its part, won't support Ogg Theora in QuickTime, expressing concerns over patents despite the fact that the codec can be used royalty-free. Opera and Mozilla oppose using H.264 due to licensing and distribution issues. Google has similar reservations, despite already using H.264 and Ogg Theora in Chrome. Microsoft has made no commitment to support <video>."

David Gerard writes "Google Chrome includes Ogg support for the <video> element. It also includes support for the hideously encumbered H.264 format. Nice as an extra, but ... they're also testing HTML5 YouTube only for H.264 — meaning the largest video provider on the Net will make H.264 the primary codec and relegate the equally good open format Ogg/Theora firmly to the sidelines. Mike Shaver from Mozilla has fairly unambiguously asked Chris DiBona from Google what the heck Google thinks it's doing." DiBona responded with concerns that switching to Theora while maintaining quality would take up an incredible amount of bandwidth for a site like YouTube, though he made clear his support for the continued improvement of the project. Greg Maxwell jumped into the debate by comparing the quality of Ogg/Theora+Vorbis with the current YouTube implementations using H.263+MP3 and H.264+AAC. At the lower bitrate, Theora seems to have the clear edge, while the higher bitrate may slightly favor H.264. He concludes that YouTube's adoption of "an open unencumbered format in addition to or instead of their current offerings would not cause problems on the basis of quality or bitrate."

An anonymous reader writes "Google has recently added FFMpeg to Chrome to better support HTML5's video element. FFMpeg is licensed under LGPL 2.1, which states that 'if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library.' Google admits to having obtained a patent license for their use, but still claims they are not violating LGPL. Among the confused we find Håkon Wium Lie and Miguel de Icaza, who wonders what FSF might say. Google doesn't feel like asking FSF for clarification."

An anonymous reader writes "Google has recently added FFMpeg to Chrome to better support HTML5's video element. FFMpeg is licensed under LGPL 2.1, which states that 'if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library.' Google admits to having obtained a patent license for their use, but still claims they are not violating LGPL. Among the confused we find Håkon Wium Lie and Miguel de Icaza, who wonders what FSF might say. Google doesn't feel like asking FSF for clarification."

An anonymous reader writes "Google has recently added FFMpeg to Chrome to better support HTML5's video element. FFMpeg is licensed under LGPL 2.1, which states that 'if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library.' Google admits to having obtained a patent license for their use, but still claims they are not violating LGPL. Among the confused we find Håkon Wium Lie and Miguel de Icaza, who wonders what FSF might say. Google doesn't feel like asking FSF for clarification."

An anonymous reader writes "Google has recently added FFMpeg to Chrome to better support HTML5's video element. FFMpeg is licensed under LGPL 2.1, which states that 'if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library.' Google admits to having obtained a patent license for their use, but still claims they are not violating LGPL. Among the confused we find Håkon Wium Lie and Miguel de Icaza, who wonders what FSF might say. Google doesn't feel like asking FSF for clarification."

An anonymous reader writes "Google has recently added FFMpeg to Chrome to better support HTML5's video element. FFMpeg is licensed under LGPL 2.1, which states that 'if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library.' Google admits to having obtained a patent license for their use, but still claims they are not violating LGPL. Among the confused we find Håkon Wium Lie and Miguel de Icaza, who wonders what FSF might say. Google doesn't feel like asking FSF for clarification."

An anonymous reader writes "Google has recently added FFMpeg to Chrome to better support HTML5's video element. FFMpeg is licensed under LGPL 2.1, which states that 'if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library.' Google admits to having obtained a patent license for their use, but still claims they are not violating LGPL. Among the confused we find Håkon Wium Lie and Miguel de Icaza, who wonders what FSF might say. Google doesn't feel like asking FSF for clarification."

CWmike was one of several readers to point out the release of Firefox 3.1 Beta 2, the first version of its flagship browser to switch on the much faster TraceMonkey JavaScript engine and sport a working privacy mode dubbed "Private Browsing." An ancillary addition to Private Browsing is a new addition to the "Clear Recent History" dialog box allowing users selectively to erase the last hour, the last two hours, the last four hours, today's, or all browsing history — previously, the wipe was all or nothing. This beta includes support for "web worker threads," a developing specification that will let Web-based application developers run background processes to speed up their apps. One feature present in Beta 1 is gone in the new beta: Ctrl-Tab switching. According to the developer, the UI needs more work; the feature probably won't be in the final 3.1.

daria42 writes with news that Mozilla has released the second alpha build for Firefox 3.1, codenamed "Shiretoko." The new build includes "support for the HTML 5 <video> element" and the ability to "drag and drop tabs between browser windows." ComputerWorld is running a related story about benchmarks shown by Mozilla's Brendan Eich which indicate that Firefox 3.1 will run Javascript faster than Chrome.

An anonymous reader writes "Ogg Theora support for the HTML5 <video> tag is in the Firefox 3.1 nightlies. Theora is the only video format allowed on Wikimedia Commons, so Wikimedia people are pushing Wikipedia readers to download a nightly and try it out. Break it, crash it, report bugs, get it into good shape and nullify Apple and Nokia's FUD the best way possible. They may have gotten the words 'Vorbis' and 'Theora' removed from the HTML5 spec, but the market will tell them when their browsers are sucking."

An anonymous reader writes "When the decision was initially made to move in the direction of XHTML, instead of a new version of HTML proper, it seemed like a good idea. Years later and the widespread adoption of CSS (among other things) has proven that things don't always develop the way we expect. As a result, HTML 5 has been revived by the W3C. After some lobbying and continued work by the Web Hypertext Application Technology Working Group, the old web markup language is getting an official face-lift. A post to the Webforefront blog explains the history behind the initial decision to move to XHTML, and why things are so different in the here and now."

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."

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 :-)

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."

An anonymous reader writes "The Mozilla Team has quietly enabled a new feature in Firefox that parses 'ping' attributes to anchor tags in HTML. Now links can have a 'ping' attribute that contains a list of servers to notify when you click on a link. Although link tracking has been done using redirects and Javascript, this new "feature" allows notification of an unlimited and uncontrollable number of servers for every click, and it is not noticeable without examining the source code for a link before clicking it."

axonis writes "Benjamin Joffe has developed Canvascape - "3D Walker", a simple javascript browser based 3D first person game engine that shows off the capabilities of the Canvas tag found in Firefox, Safari and Opera. " Don't expect much except a proof of concept ;)

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!"

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!"

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!"

An anonymous reader writes "A breakaway faction of the World Wide Web consortium (W3C) called WHAT-WG, or the Web Hypertext Application Technology Working Group--which includes Apple, the Mozilla Foundation and Opera--is threatening to revolt over electronic forms standards. WHAT-WG has announced its intention to submit the draft to the W3C, posing the potentially awkward possibility of the consortium advocating two conflicting avenues for Web forms. The fate of a standard could also determine whether the order form could be accessed in any standards-compliant Web browser, or if it would be available only to users of a particular operating system--an outcome that has browser makers and others worried about the role of Microsoft."

J. Hobbs writes "Recent posts on David Hyatt's site describing the new technology he's working on for Dashboard, coupled with recent announcements from the newly formed WHAT-WG alliance (Apple, Mozilla, and Opera) could add up to a potentially new kind of application development and deployment that I explore in this highly speculative essay. See if you don't agree..."

An anonymous reader writes "MozillaZine is reporting that the Mozilla Foundation and Opera Software have formed a working group to develop specifications for Web applications. The new Web Hypertext Application Technology Working Group is working on specs for Web Forms 2.0, Web Apps 1.0 and Web Controls 1.0, among others. This is being done outside of the W3C, with the hope of getting a viable alternative to Longhorn's XAML available soon. Another reason for working outside the W3C could be the rift between Mozilla/Opera and other W3C members over what technologies Web applications solutions such be based on: Mozilla/Opera favour a backwards-compatible HTML-based standard, others are looking towards to XForms and SVG. It will be interesting to see if any other browser developers jump on board WHATWG." This story builds on our recent story concerning the group.

An anonymous reader writes "MozillaZine is reporting that the Mozilla Foundation and Opera Software have formed a working group to develop specifications for Web applications. The new Web Hypertext Application Technology Working Group is working on specs for Web Forms 2.0, Web Apps 1.0 and Web Controls 1.0, among others. This is being done outside of the W3C, with the hope of getting a viable alternative to Longhorn's XAML available soon. Another reason for working outside the W3C could be the rift between Mozilla/Opera and other W3C members over what technologies Web applications solutions such be based on: Mozilla/Opera favour a backwards-compatible HTML-based standard, others are looking towards to XForms and SVG. It will be interesting to see if any other browser developers jump on board WHATWG." This story builds on our recent story concerning the group.

An anonymous reader writes "MozillaZine is reporting that the Mozilla Foundation and Opera Software have formed a working group to develop specifications for Web applications. The new Web Hypertext Application Technology Working Group is working on specs for Web Forms 2.0, Web Apps 1.0 and Web Controls 1.0, among others. This is being done outside of the W3C, with the hope of getting a viable alternative to Longhorn's XAML available soon. Another reason for working outside the W3C could be the rift between Mozilla/Opera and other W3C members over what technologies Web applications solutions such be based on: Mozilla/Opera favour a backwards-compatible HTML-based standard, others are looking towards to XForms and SVG. It will be interesting to see if any other browser developers jump on board WHATWG." This story builds on our recent story concerning the group.

An anonymous reader writes "MozillaZine is reporting that the Mozilla Foundation and Opera Software have formed a working group to develop specifications for Web applications. The new Web Hypertext Application Technology Working Group is working on specs for Web Forms 2.0, Web Apps 1.0 and Web Controls 1.0, among others. This is being done outside of the W3C, with the hope of getting a viable alternative to Longhorn's XAML available soon. Another reason for working outside the W3C could be the rift between Mozilla/Opera and other W3C members over what technologies Web applications solutions such be based on: Mozilla/Opera favour a backwards-compatible HTML-based standard, others are looking towards to XForms and SVG. It will be interesting to see if any other browser developers jump on board WHATWG." This story builds on our recent story concerning the group.