---

No not Kestrel (had you there), but Opera 9.5 SDK. The SDK was announced at CES in Las Vegas. The Opera SDK is the cornerstone of Opera's offerings for devices. It allows for easy development of a browser for the many platforms that it supports out of the box, using our GOGI abstraction layer technology. As expected it supports some pretty amazing things.

The biggest inclusion for web developers is the inclusion of Core-2. The Internet Channel (on Wii) and Opera Mini 4 included earlier versions of Core-2, but this includes all the advancements made since those releases, to make Presto Core-2 the rendering engine it is today. You can download the latest weekly Kestrel releases to get an approximation of the engine, as they should be very similar. This includes HTML4, partial HTML5 (including Web Forms 2 and Canvas), CSS1, CSS2.1 (very close to full support of the current recommendation), partial CSS3, DOM1, DOM2, partial DOM3, SVG Basic 1.1, partial SVG 1.2, XSLT 1, XPath 1, ECMAScript 2 & 3, Widgets 1.0 etc.

For those of you that like to develop Widgets, the same widgets that work on Opera Desktop and Nintendo Wii will also work here. They should also work on Joost software too.

One advancement that is important on the small screen is Opera Zoom beta. This is basically what is in Opera Mini 4 and will be in Opera Mobile 9, and similar to what debuted in the Wii (which was out before iPhone, so no it is not a copy of that). This allows users to browse the web on a small screen without the need to reformat the page. For eye candy lovers, there are visual effects, to make zooming and such look much better. For those that prefer single column mode, that is still included as an option.

There is no mention of it anywhere, but I assume Opera Link is in there somewhere too. Another important addition is Flash Lite 3, to allow sites like YouTube to be displayed.

One thing that I'm excited about that is included is WebUI. This allows GUIs to be created using regular web technology, instead of normal platform specific APIs. This makes UI development not only more portable, but cheaper, quicker and has a much bigger pool of people that can develop for it. Any web developer can basically start making UIs quickly. As the UI is made for the device, and not the web at large, there is no need to worry about IE rendering bugs or missing standards support. The full arsenal of Opera Core-2's standards support is available. There is no better excuse to learn SVG or CSS3. Things like buttons can be made fully scalable with SVG, and regular HTML text that screen readers can access (providing a screen reader exists for the device in question). As Opera adds further support for CSS3 like border-radius and box-shadow this becomes even more excing and easy. With the advanced standards support available it is not that difficult to make advanced GUIs that can even look like native desktop applications.

The only confusing thing for me is the release date. Opera 9.5 Kestrel is not out yet, and thus when it dos come out, it will have different standards support and bugs to the 9.5 SDK (most likely). This will mke it more difficult for developers as there will be differences in rendering when making use of things that differ. This is quite unfortunate. I also hope the CSS3 nav-* properties have been included, as they make Spatial Navigation (important on devices without a mouse) easier to define by the developer, and in a standards based way.

For more information on the Opera 9.5 SDK, take a look at the product sheet (PDF)

---

Last year, Opera was included in the sequel to one of the most popular mobiles of all time - The MOTORAZR 2. It was quite impressive the the full Opera Mobile was squeezed into a fashion phone that is fairly slim. CES in Las Vegas is in full swing, and it seems that Opera Mobile 8.5 is also included in the blingist phone of them all - the MOTORAZR 2 Luxury Edition. The phone has such esentially as 18k gold plating and snake skin effect on the back. I'm sure the phone stands out. I'm not a gold fan, so I'd never buy this phone, but I'm sure bling fans will love it. I think it'd look much better with silver, or brushed steel, and a regular leather back (maybe brown). Maybe Motorola will be kind enough to make me my own Web Opener special edition ;).

I'm sure there are tons of new phones and gadgets getting announced this week, and I don't have an official list of what includes Opera. I did notice from the UIQ site that the Moto Z10 had been announced though. No confirmation that it is Opera (why do phone manufacturers always make this so difficult?) but Opera is the default browser on UIQ, so its a safe bet. This looks to be an update to the MOTORIZR Z8 banana phone, and looses the green look in favour of a more sleek metal/grey appearance. How come UIQ always gets the good looking smart phones? No word on the resolution yet as far as I can see, but it sports a 2.2" display and very fast connectivity.

Although not Opera related, I also noticed on Engadget that a new Blackberry is coming out. I guess this has been announced at CES too. Blackberrys suppose to be great phones, but every time I went to the States and saw how big all the Blackberrys and Palms looked compared to most of the phones over in Europe, I could never consider carrying one. However Blackberry seem to be getting it together in the style department. The Pearl was much smaller and wasn't pig ugly. After touching one though, the materials and fit and finish seem to let it down. It felt very plasticy. This new phone looks to continue the improvements style wise, and hopefully in the fit and finish department too. The phone still looks fairly large in the picture though - like iPhone dimensions (which is very wide and tall). Opera Mini is probably the best browser by far on the Blackberry, which is why we are so popular in the Blackberry community, so I look forward to see it running on this phone. The screen isn't as nice as the iPhone for surfing, but the physical Qwerty keyboard partly makes up for that. Speaking of screens, the new Mylo 2 has a very impressive screen, that makes even the iPhone screen look poor. Sadly I don't think it has Opera on this time. Opera Zoom would be fantastic on the device.

---

If you are in the Vancouver area, and are thinking about attending the premier web design conference in Canada - Web Directions North, then we've got some good news for you. I had a fantastic time there last year, and so Opera has decided to push the boat out and sponsor this year's event. This means we get to offer you all a $100 CND discount (Isn't that still worth more than $100 USD?). All you have to do is visit this address and enter the magic code WDNOp, and Bobs your uncle, Marys your aunt. You can even heckle in the back during the Air Vs Silverlight talk (Only kidding please don't do that. We know the Open Web wins in that battle ;))

Mr Chris Mills will be attending the event, along with myself. Please come speak to us if you have any questions about Opera or any problems with compatibility. If you have Opera Mini on your phone, we may even buy you a beer.

W3C's MASE search engine got a nice new year present, in the shape of a new server. The additional computing muscle will be well-used to index and search among the hundreds of thousands of messages on the W3C's mailing-list forums.

Taunting two knights with one stone, we also took the opportunity to give the search interface a fresh layer of CSS paint, and, among other updates, a Period search feature which can be used to limit search results to a given Month and/or Year.

All this is possible thanks to the great team developing the Namazu engine as an open source project. Namazu is not supposed to be used on such a massive set of data as the W3C lists, but it works: our hacking was, and is, mostly limited to interfacing the engine with our lists system, and make indexing of individual lists real-time.

Update: for some gritty details on how the mail search works, see this companion entry in the W3C Systems Team blog.

Any bug you'd like to report on the search engine? Features that we really should be adding? The comment form is all yours!

Data portability and open data are hot topics these months. The multiplication of social network sites has increased the aggregation of these data in silos. The Semantic Web activity encourages to open your data with a new series of cute logo. Geographical data such as the Open Street Map initiative, government budget such as USA are the trend. But when it comes to our personal data, we need more granularity.

Danny Ayers on Talis Web site talked about Data Licenses for Social Network Services. He frames the discussion with a basic rule:

I own my data. This would correspond more or less to the default copyright on documents - even if you don't say anything explicit on something you write, you have the copyright.

In the past (before the Web), when I shared my data with a friend or someone else, phone number, specific email address or local postal address, in some cases, I would make a point of saying: « Do not share these with someone else. » The trust relationship I have with the person made it obvious, without relying on a signed contract. The person would put it in her/his paper or computer address book. It was local data, viewed only by one person.

Then the Web arrived with many online services. You sign usually a contract between the online service and the usage of your data. It is your choice to decide what you accept from these services. But there is an additional issue. In your data, there are data which belong to other people. When you send the data to an online service, you might break a trust relationship. This person doesn't necessary want you to share your data with this online service.

The big change is that we all became provider and consumer of data with a responsibility in sharing them. All of us are a social network service with responsibilities.

How do we manage that? Recently Danny Weitzner (W3C) has posted an article on Reciprocal Privacy for the Social Web (a.k.a. FOAF). He mentionned in this article a document is working on: Reciprocal Privacy (ReP) for the Social Web. Read it, share it and comment it.

This is one of the big challenges for the years to come.

RDFa is a way to enrich your Web pages with local data. The clear benefit is that your data are in context and then easier to manage. Yesterday, on the RDFa mailing list, Dan Brickley asked how we could use RDFa to extract the information of an HTML imagemap.

Dan says:

HTML has a somewhat neglected notation for describing regions of images, and associating them with links.

[snip]

BTW I have no idea what the current XHTML 2 and WhatWG/HTML5 folks have planned for these elements. But I think this kind of markup has a lot of potential for making images on the Web more automation friendly.

For now, HTML 5 map element doesn't do better than HTML 4.01 or maybe I have missed something.

Max Froumentin had design an XSLT which transforms the imagemap code and then convert it to an SVG ouput with the background tone down to make the imagemap zone more visible.

Dan continue:

I'd like a way to say, "this area of the image depicts the person who is the primaryTopic of http://danbri.org/".

A lot of work had been done already in the past on image descriptions with some practical examples, but Niklas Lindström started to give it a stab.

<map name="da8bb51_b" id="da8bb51_b"
    about="[_:the_area]" 
    property="ex:imageMapAreaElement">
    <area  shape="POLY"
        coords="..."
        href="http://danbri.org/" />
</map>

<img  about="[_:the_area]" 
    rel="ex:sourceImage"
    src="2169955372_503da8bb51_b.jpg"  
    width="1024" height="770"
    usemap="#da8bb51_b" />
<div about="[_:danbri]" instanceof="foaf:Person">
    <span property="foaf:name">Dan Brickley</span>
    <span rev="foaf:depicts" resource="[_:the_area]"></span>
    <a rev="foaf:primaryTopic" href="http://danbri.org/">(website)</a>
</div>

• Someone has a better suggestion in RDFa?
• Would it be better done in HTML only without breaking previous implementations of HTML 4 imagemap?

I see a lot of possibilities in games, identification, education, cartography. fun. fun.

---

The new year is upon us, and what better way to start it than to create a wish list for the upcoming year. These will be mostly related to Opera, but also some in regards to web standards in general. These don't relate to any inside knowledge at all, and are just personal wishes.

Change the toilet seat

I'm running Opera here on my brother's PC (My Mac laptop died a sorry death on new years eve), on XP and the logo isn't so bad due to the icons on XP being so tiny and low resolution. It is a different matter entirely on OS X though, which is magnified more on Leopard, with the new dock that gives a shadow of the shadow, and a reflection of the reflection. Not to mention a reflection of the shadow and a shadow of the reflection. A icon probably needs to be more detailed, but as a logo mark how about a perfect circle, a red ring? Rings and circles have a lot of positive symbolism, are very recognisable, and are geometrically pure and minimal. A ring is also used in Japanese (a strong market for Opera) as the symbol for yes or correct, just as a tick is fin the West (while a tick means incorrect in Japan).

Promote our roots and heritage

Opera is both Scandinavian, and European. Being Scandinavian has one big disadvantage; the cost of doing business and the wages are high due to the cost of living, taxes etc. It does have big benefits though. Scandinavia is known for its technical inovation (as is Opera), with the likes of SonyEricsson, Nokia (ignoring the fact that Scandinavians would term Finland as Nordic and not Scandianvian), Saab and Volvo. That means there are many people with great technical ability here, and just as many close by in the rest of Europe. Arguably though Scandinavia is more famous for its design. Bang & Olufsen is the stand out name in terms of electronics, but there are many more from the worlds of fashion, art, architecture, home furnishings, music and so on. Names such as Ikea, H & M, and Absolut (whose bottle is a design icon) are probably house hold names around the world. And who didn't play with Lego when they were a kid? Of course, Europe as a whole is famous for its design or high quality goods. From Germany with its cars, to Italy with Fashion, Switzerland with watches an France with its wine and cheese. Did I also mention the Scandinavian women?

In some ways we are already moving in this direction. If you look at our feature list, it can often be described as maximilism instead, of the Scandinavian minimilism of its most famous design movement. But we've got some great new designers, that are doing some fantastic work, and we've recently worked with the photographer of Moods of Norway for the images on our new B2B section of the Opera web site. You'll even notice one of their founders in some of the photos. They're a small but up and coming fashion label that are very popular here in Norway, and stars like Gwen Stefani are fans.

I'd love to see us work closer with these kind of companies and creative people, and also come up with a design aesthetic of our own, which is both uniquly ours, but pays homage to our heritage, and design excellence of the region.

Deliver to top quality partners

In 2007 Opera delivered products to some of the biggest names. Nintendo, Vodafone, T-Mobile and Sony are just a small example. One partner I'd love Opera to have is the aformentioned B&O. It wouldn't do anythnig for our market share, as they ship low quantity, high cost items, but the combined innovation potential of both companies combined would be quite exciting. I can think of some great control methods we could do with their new programable, touch screen remote, and I can imagine they'd create a great minimalist interface. We also have the technology so that we could be included in their entire range, from TVs, to mobiles, landlines, music systems and even their car projects.

I'd also love to do something more experimental. Car manufacturers often create prototypes for the big car shows. I'd love to see Opera create a prototype browser for a company such as Saab, that shows how a browser could be integrated into a car, and even control the entertainment system and other systems. Being a prototype, it wouldn't have to be even functional, just design ideas. Opera has already shipped in aircraft seats, so there is no reason why it couldn't be included in cars too, especially with our voice control technology.

Opera Labs

Speaking of prototypes, we have a fairly new labs site. During the year we released a number of experimental builds, such as advanced SVG, canvas and video builds. It would be great to use this site more to show some of the crazy technology we are working on, and realease things like prototypes and experiemnts that perhaps couldn't be included in our flagship products. Experimenting with different interface styles for instance.

Faster, Safer, more Standards

We are probably industry leading in all these areas, but there is no reason why we can't improve even further. There is certain CSS3 properties that I'd love to see, and HTML5 has some interesting features. It would be nice to see core pieces of each spec ready, and implemented by the major browsers, by the the end of the year. It isn't possible for all of the spec, but in CSS3's case, it could include a couple of modules such as Backgrounds & Borders and Media Queries for example.

Developer tools

It is no secret we are building real developer tools. It will be difficult to rival the likes of Firebug instantly, as they've had years of development. We are commited to making good quality tools however and to improve them as they mature. I hope they ease issues with developing for Opera, and help improve our compatibility rate. Hopefully we can deliver some of that Opera innovation to the developer tool space.

The one true web to rule them all

There is a feeling in the air that we are in the mist of the beginning of another great browser war. Lets hope the Web wins this time, instead developers moving from the Web to alternative one vendor controlled technologies such as Air and Silverlight. It certainly looks that way with all the Silverlight sponsorship and booths they've been doing at Web conferences recently. Far more than promoting IE IMHO. I'd love MS to commit to adding to IE any feature that exists in Silverlight, or is planned to be, and is included in a Web standards, in a reasonably similar time frame. If Silverlight gets much more features for developers to use than IE, then it is natural developers will start looking at the shiny new toy. Silverlight is a nice rival to Flash, in a one vendor solution rival to another in the plug-in space, but if it becomes a rival to the web, then that is scary for everyone, except Microsoft. Ditto with Air.

I want the Web to win in '08 and not any commercial interest from either player.

C. M. Sperberg-McQueen has opened a blog recently, Message in a bottle. It is really cool. When I had questions about XML, I sometimes asked him on the W3C internal mailing-lists. Very often, I thought that it would be great if his answers were public. Not only, he knows XML, but his replies are very clear.

Two days ago in a message, Sandboxes and test cases about XML Schemas tests, he's telling about the process of creating test cases and trying in some implementations.

It's always interesting to construct test cases to illustrate some question or other that arises, whether from a comment on the spec or an inquiry by email. And I have directories with scores of small test cases I have constructed over the last few years. But until I started this more systematic construction of a schema validation sandbox, I contented myself with checking those test cases with one or two processors.

But also explains that playing with more tools is more fun.

But it turns out that having more processors to test is just a lot more fun. Here is a test case. OK, what does libxml say about it? MSV? Saxon? Xerces C? Xerces J?

Identifying issues in software helps people to improve implementations and specifications. But if you do so, please be kind. It is always better and more encouraging to receive an email saying "I may have identified an issue" more than "Dude. I broke your implementation. Take that!". It might sound silly but courtesy helps a lot to get things fixed.

Back to the article of Michael, he has been publishing a tiny collection of XML Schema test cases. And as he said:

I plan to put every schema example I generate this year there, instead of hiding it on my hard disk. At least the interesting ones.

Well done Michael and happy new year too.

---

Happy new year everyone. May 2008 be a year when there is great progress with web standards such as CSS3 and HTML5, where we make great strides with cross browser compatibility and getting authors to use accepted standards, and maybe even Opera upgrading to a new bug tracking system (ok, world peace may come before the last one ;)).

It's my aim to eradicate the best viewed in… message. A relic of the last browser wars, which lingers in ever some of the most high profile places. Google Docs was the latest high profile site to remove theirs. Hopefully Spreadsheets and Presently will give us a late Christmas gift, along with the full version of Microsoft Windows Live Hotmail (or whatever it is called these days).

2008 should be a great year for Opera. Mini is going from strength to strength as the most popular Mobile browser, even after all the competitors hype. Opera Mobile is looking exciting and should move over to Core 2 in '08. Kestrel (9.5) is coming along nicely and will no doubt be out some time in the not too distant future.

The advancement and maturation of Core 2 is looking very promising. It is only getting faster, leaner, more secure and more standards compliant. I truly believe it is industry leading in all those areas. I often think of it like a hand tuned sports engine, and the jewel in Opera's crown. I'm personally following the progress of CSS3 closely, and as these specs improve, I expect to see our support improve even further than it is now. Web Fonts is one such are that clearly interests our CTO. Our HTML5 support is also very good, and something that isn't noticed too much. I'd advise anyone that is interested in the future of the web to take some of our HTML5 features for a spin. Web Forms and Server-Sent Events are a couple of things I've mentioned before that don't need too much explanation before realising how useful they can be. I'm also looking forward to our Mac build of our labs release of Opera with Video and Audio support in both HTML and SVG.

It is no end of year message without a bold prediction. I predicted this year would be the year mobile took off, and that has been true to some extent. Opera mini has improved greatly, and its market take up, with very little promotion or advertising, has been remarkable. The was also a little Apple device that took the world (USA) by storm. I'll go out on a limb and say this year could be the one where SVG gets the push it needs and starts making inroads. Now for this to happen it needs industry wide implementation. Again, opera has industry leading support. Unfortunately we don't have the market share to push these things. Mozilla have support in their Firefox browser, but I'm nt sure how far they've advanced recently. Apple has support in Safari 3, and I don't think it will be too long before they follow Opera and have it working within CSS. The cog that is missing, is of course IE. I've no idea if they have added any sort of support in IE8, and this is one of the required pieces, especially with Adobe killing their plug-in once it wasn't strategically beneficial to them. One can probably implement SVG through Silverlight, although this wont help in the area which I find SVG the most useful; as a CSS background image. There is always ways to do rasterisation on the server though.

I don't think '08 will be a time when SVG rivals flash. The tools to create complex animated interfaces in SVG are just not there. And lets face it, most people won't want to do that by hand. But for vector style still images it is ideal. For simple shapes, symbols, gradients, translations and reflections it is ideal. Most of the aforementioned simple things, it is easy to do it by hand. I learnt those basics in a few hours hard study. For more complex images, the typical tool of graphic artists can be used, Adobe Illustrator. It doesn't produce the best output in the world, but at least it does export to SVG. From there the image can be kept as a vector for browsers that support it, and changed to a PNG for those that don't. There are great benefits, such as scriptibility via the DOM, scaleability (especially now we are slowly moving to resolution independence and browsers are catching up to Opera with the introduction of full page zooming instead of just text zoom), and page weight (Don't forget that SVG can be zipped and served as SVGZ for even further size reductions). page weight is getting less important due to the proliferation of broadband, but there are still many areas where dial up is relied on, saving server bandwidth is also still a great plus on your pocket. The mobilisation of the web also means we have to think about those on a slow connection, as anyone that has used AT&T Edge will testify.

I hope you all have a great new year, and have great celebrations over the next hour, or whenever it is your new year. The life of a web opener is never done, so I'm off to get some work done. I'll speak to you next year.

(original lyrics by Ed McCurdy and known to most because of Paul Simon, thx guys)

Strangest Dream (Web version)

Last night I had the strangest dream
I’ve ever dreamt before
I dreamed we had all agreed
To put an end to browser war

I dreamed I saw a mighty room
Filled with women (but mostly men)
And the papers they were signing said
They’d not do specs wrong again

And when the specs all were signed
And a million copies made
Some joined hands and thought they’d have a prayer
About the specifications, made

And the people on the Web below
Were running up and down
While markup and scripting and browser wars
Were scattered all around

Last night I had the strangest dream
I’ve ever dreamt before
I dreamed that we had all agreed
To put an end to browser wars.

Not so long ago, I said farewell to my father for the final time but because of various historical reasons, it was not exactly a fond farewell. I wished at the time that it could have been different. Now, here I am thinking of what to write about the passing of Netscape, and finding myself with similar feelings. Sure, many years ago, you meant something to me, Netscape, but in recent years news of updates has left me thinking ‘meh’, and as we learn today that Netscape is to be killed off for good by AOL, once again I’m thinking "wow, it took this long?"  and wishing I actually cared more about it. Because there was a time that I would have been damn upset about this.

I mean, seriously, who installed Netscape 9 - and then actually used it? (Installing it, firing it up once to what the UI was like and never opening it again doesn’t count, by the way).

And just as I had done when my father shuffled off this mortal coil, I wanted to cast my mind back beyond the more recent years, during which good news stories were hard to find, and to once again remember some of the shining moments from further back. Like when Netscape was the dominant browser with over 90% of people using it to surf the web. I remember showing people how they could create their own web pages using Netscape Composer – for free! And let’s not forget that Netscape took an incredibly brave decision after the first browser wars to completely scrap its codebase that would have formed the basis of Netscape 5 (the browser that never was), instead coming out with a much more standards-compliant Netscape 6. This was the moment that the fork in the road that started diverging with Netscape 3 and IE 3, and widened even further in the version 4 browsers, started to converge back again. Had this not happened, who knows what divergence we might have in web browsers today? Sadly, though, this might also have been the moment that Netscape started to fall on its own sword.

While new skirmishes have recently cropped up in the browser world, proving that the war may not truly be over, for this weary old fighter it’s one battle too many to fight, and will be on mere ‘clerical duties’ until February of next year, upon which time it can hang up its combat fatigues for good.

Farewell, Netscape. We may not necessarily notice you’ve gone, and you may have taken a kicking or two along the way for some of your misadventures, but you weren’t all bad.

This post also available in Polish

One of the most frustrating, time consuming and challenging aspects of managing cross-browser rendering of CSS is dealing with bugs along with incomplete implementations. Examining helpful resources such as position is everything and QuirksMode, it becomes profoundly clear that today’s front end web designer and developer must be pretty adept at dealing with this core problem.

I call it a core problem because of course, interoperability is a problem the Web was meant to solve! Yet, the disparities in Web browsers have in fact caused the greatest accessibility challenge to the Web we as its authors must face, and conquer.

Fortunately, there are some proven ways to deal with cross-browser challenges. We can use hacks, which of course are controversial in their own right due in large part to how difficult they are to maintain and how often they are based on invalid markup or parsing errors (* html anyone?).

We can use conditional comments for managing IE versions. CC’s are in my opinion the cleanest way to manage IE issues on a case by case basis, but they too are controversial. An HTML comment was never intended to contain a conditional statement, so a CC is essentially a hack. Furthermore, it’s an IE-specific solution, so that in and of itself smells a little funny to the purist nose.

Another approach involves using JavaScript to “correct” browser behaviors, such as we find with Dean Edwards’ IE7 Scripts.

What ends up happening, as we all know, is that we use a combination of these techniques where necessary to address our browser base.

So we have the techniques: Three primary ways we approach bug bashing and implementation problems. What’s missing isn’t our knowledge, but a conventional method. If we had a step-by-step procedural to walk ourselves through, that could be very helpful. Clearly, what works for one site isn’t necessarily going to apply to another, but some guidelines to help each other manage this very murky, very challenging problem would certainly be of benefit.

My intuition and experience suggest that the most effective way to manage bugs is to kill them where they live. That means having a clear workflow from the earliest stages of authoring to manage browser issues regarding CSS. Surely many folks will have created such workflows, perhaps even unaware that you’ve done so, as it’s just become part of your process.

Think about how you work and if you could take a moment to share your best bets for managing cross-browser CSS design, we can together examine the least time-consuming, most efficient and most solid method by which to bash those bad, bad bugs.

The Video On The Web Workshop is finished. A report is being prepared with the outcomes of the workshop. In the meantime, three video interviews have been published by videolectures.net:

• Interview with Adobe Chief Software Architect
• Interview with the W3C Chief Executive Officer
• Interview with W3C Compound Document Specialist

Update: Another video this time explaining relationships between videos, metadata and Semantic Web technologies by Philippe Le Hégaret.

To make the distance to home when I travel a little shorter, for my birthday I got one of these digital picture frames. With a little fiddling, I got the picture and music features working, but I'm stumped on video. When I searched for support, I found I wasn't the only one:

I converted my file to various formats but unfortunately none of them would play on my frame.

Hindry 2007-07-31

When I picked up co-chairing the HTML Working group with Chris Wilson in March this year, little did I know how much video codecs would impact that part of my life too.

The scope of the HTML 5 draft is considerably larger than the scope of the HTML 4 Recommendation, and the Working Group is looking at the major differences in a couple ways:

• a HTML 5 differences from HTML 4 draft
• a list of requirements issues

Among those requirements issues is ISSUE-6, videoaudio. It has been discussed informally as far back as March/April (Opera, Apple and Microsoft, etc.) and it was added to the issue tracker during a discussion of media elements on the first day of our our November meeting in Cambridge.

A few minutes later, we added a design issue, ISSUE-7 video-codecs, regarding which codecs, should/must/may implementations of HTML 5 support. David Singer of Apple wrote an excellent summary on 9 November:

... interoperability at the markup level does not ensure interoperability for the user, unless there are commonly supported formats for the video and audio encodings, and the file format wrapper. For images there is no mandated format, but the widely deployed solutions (PNG, JPEG/JFIF, GIF) mean that interoperability is, in fact, achieved.

Licensing:

The problem is complicated by the IPR situation around audio and video coding, combined with the W3C patent policy. "W3C seeks to issue Recommendations that can be implemented on a Royalty-Free (RF) basis." Note that much of the rest of the policy may not apply (as it concerns the specifications developed at the W3C, not those that are normatively referenced). However, it's clear that at least RF-decode is needed.

So when Rudd-O's article says, "Nokia and Apple have privately pushed to give Ogg the noose treatment," that's just sensationalism. The truth is that Apple and Nokia are participating in an open discussion of the issue.

Many of us share the goal of an open, interoperable video codec for the web. But the state-of-the-art as of Nov 2007 is that there is no video codec that meets the community requirements. In that context, the 30 Nov message from Mikko Honkala of Nokia that said, "we support publication of HTML5 WD, including the canvas, audio, and video elements, but not the SHOULD clause for the baseline codec until proper patent assessment has been made" is not a "noose treatment"; it's just working group members trying to prevent the disappointment of authors coding to the spec and then finding out that it doesn't work.

The 11 December response from the editor, Ian Hickson, was to acknowledge the issue in the draft:

It would be helpful for interoperability if all browsers could support the same codecs. However, there are no known codecs that satisfy all the current players: we need a codec

• that is known to not require per-unit or per-distributor licensing,
• that is compatible with the open source development model,
• that is of sufficient quality as to be usable, and
• that is not an additional submarine patent risk for large companies.

This is an ongoing issue and this section will be updated once more information is available.

3.14.7.1. Video and audio codecs for video elements the HTML 5 draft, formatted for emphasis/clarity

Worse than not acknowledging the openness of the discussion, Rudd-O continues, "This destroyed all hope of having free (as in freedom) media embedded in HTML5 in an interoperable way." To give up hope at this point is the most counter-productive thing to do.

The response to the W3C Video on the Web Workshop Call for Participation was an outpouring of resources to tackle this issue. The presentations were inspiring.

I was also inspired by Håkon's demo in the video panel in the W3C Technical Plenary; he took the wikipedia octopus article and replace the photo with a video. It was easy to think back to when I was in third grade and imagine how much more of an impact it would have on me; then I remembered I have a third-grader at home; see One laptop per Kyle for more of that story, including a little video production of my own.

Putting that video of Kyle together was pretty easy with current consumer technology: I shot it with a digital video camera that we bought years ago, edited it with Apple iMovie, and an online service took the iMovie output and converted it to whatever everybody is using these days. But as Eric Hyche of RealNetworks pointed out last week, somewhere in the process I had to execute some terms and conditions with that online service; it's my video; what business is it of theirs? When I take a picture and put it up on the Web, I can use flickr if I want their value-add services, but I can also just stick the JPG file on an HTTP server of my own; the corresponding option for video is beyond the reach of the typical Web user.

Though I'd rather somebody more qualified chaired the W3C standardization effort to choose between video codecs, I have been studying digital media enough to be confident I could produce Ogg/Theora or Dirac; but I'm not sure my audience can consume it. After the workshop discussions, I'm particularly sympathetic to comments such as this one about the rich network of support for H.264:

... pushing Ogg/Theora might make you proud to have voted, but it will only distract from the industry's coalition to unitedly back H.264 from mobile devices to HD. There's far more FOSS support for MPEG-4 and H.264 than for Ogg/Theora ... Having wide support behind one good, open portfolio of standards will make it easier for FOSS to compete with and participate in the desktop computing world.

DECS (891519) on Sunday December 09, @05:33PM

H.264 has a lot going for it; the two main issues I see are:

1. the H.264 patent licensing situation
2. competition with VC-1 in Windows Media

Microsoft didn't send anyone to the workshop last week, so I'll leave the second issue for another day.

I heard a lot of creative ideas about the patent licensing situation and support for free software, though. Everything from stop-gap measures involving binary blobs to using the full force of W3C to address the patent situation head-on as we did in the P3P and Eolas cases. If you want to join the W3C members who have expressed an interest to help, please contact me and Philippe Le Hégaret and Chris Lilley, preferably with a copy in a public archive.

Today (21 December 2007) I am attending the Tokyo 10th XML Developers day. This is an annual event, held in Japanese, with latest news from the Japanese XML developers community. The event is organized by Murata-san. The presentations are of a great variety, providing both technical and rather "political" aspects of XML trends. Below is a summary of the talks, focusing on the technical aspects.

The World of Genji Monogatari - a new Edition

(slides) Miyawaki-san presents a project with the aim to relate additional information to the main text of Genji Monogatari: notes from himself or others, images, sound of a reading of the novel etc. In a previous version he used an approach of enriching an HTML file (the main text) with that additional information. Later he switched to an XML-based format. That allows a user to easily add new information, and multiple users to add content without conflicts. Miyawaki-san encounters some problems like XSLT-debugging, the need to process JavaScript (necessary for the HTML output) in XSLT, or error handling in XSLT. The latter even motivated him to rewrite some XSLT code in JavaScript ...

An interesting aspect of a generated HTML output is that it is presented in Internet Explorer in vertical layout (see this screenshot). For the Japanese audience who is used to read novels vertically, this is an important feature, though the layout still needs some improvement.

Parallel Narratology

Kobayashi-san from Justsystems presents so-called parallel narratology, realized with XML. He mainly uses the famous Japanese murderer story of Rashomon as an example. In that story, the same event is narrated several times from different perspectives. In an XML representation of the text, users can create links between the different narrations of the same scene (e.g. a murderer scene). Yamaguchi-san from Justsystems demonstrates the XFY editing and development tool which has been used for the creation of the links, and the presentation of the parallel texts.

The linkage allows readers to take a new perspective on the relations between narrations. Not only the author, but everybody can add such links: the ordinary "story readers" become "story writers". A problem mentioned during Q/A is: how to express overlap, i.e. non-hierarchical structures of markup. Such structures may be necessary e.g. to enable different users to mark up overlapping passages of the same text.

Character Encoding (again)

Kobayashi-san presents again, mainly about the "gaiji" problem. There are many ideographic characters which are so-called glyph variants of characters from the Unicode character set. However, these variants are not represented as distinct characters in the character set. Kobayashi-san introduces two solutions to this issue: shortly the Japanese standard JIS X 4166, and mainly Unicode variation selectors. The latter are used for the registration of such variations in the Unicode Ideographic Variation Database.

Yamamoto-san demonstrates how Adobe is using the variation selector approach. In Adobe fonts, there are glyphs available for much more characters than the Unicode character set encompasses. Adobe uses the variation selectors approach to create stable identifiers for these characters. The Unicode Ideographic Variation Database then serves as a registry for these identifiers.

Input Methods in the Age of XML

Masu-san from Justsystems presents on input methods. These are tools for making the input of scripts with a large set of characters (like in Japanese) easier. Masu-san then demonstrates enhanced input methods. They provide functionality which is not only useful for large character set input. For example, while entering a date, the input method recognizes the date and creates appropriate markup, hyperlinks to a calendar etc. Using such enhanced input methods, users not knowledgeable of XML are producing XML-code (e.g. a marked-up date) without noticing.

Kumaya-san from Tokyo University presents on how an enhanced Input method framework can be used. In the presented implementation, currently, schedule data is represented via Microformats, and location information is taken from Google maps. A question is how to describe the meaning of related, similar information, e.g. HCalender versus Google calendar. The answer is: humans have to make the relation explicit, there is no automatic way to achieve this.

A Prediction of the OOXML Vote Result and the Ballot Resolution Meeting

Murata-san provides insights in the rather political aspects of the development of the OOXML and the ODF office formats. The Ecma TC 46 committee has already approved OOXML. On 25 February 2008, there will be a Ballot Resolution Meeting (BRM) by JTC1 about OOXML. Murata-san predicts that at the BRM, there will be no discussion of real criticism on the format, but only discussion of minor technical changes. The reason is that contentious issues are outside the scope of the BRM.

He presents also work on ODF undertaken in ISO SC34 and a proposal for standardization of a round-trip conversion between ODF and OOXML. The discussion about the round trip conversion happens in DIN (Germany,) not in SC34 (yet). The DIN committee might want to submit the result to JTC1 using the fast-track procedure.

Murata-san admits that in the past, he thought the standardization of an office format would be impossible. Nowadays there are two on their way, which seems to be better than zero ...

Outline of AtomPub and Interoperability Testing Results

Asakura-san from NTT Communications presents the AtomPub format (RFC 5023). This is a protocol for publishing and editing Web Resources like Atom feeds via HTTP and XML 1.0. AtomPub defines the notions of collections (like Atom "feeds") and members (like Atom "entries"). Using the HTTP methods GET, POST, PUT and DELETE, collections and members can be retrieved, created, changed or deleted.

Asakura-san also provides insights into the experiences he had during the IETF standardization process, and reports from the the AtomPub interoperability event in Tokyo. Six companies participated successfully in that event.

Schemas for validating Atom and its Extensions

Murata-san again talks about Atom. Atom uses extensions from many namespaces, e.g. Gdata, Google Calendar, Atom Bidi, GeoRSS, Dublin Core etc. Murata-san gives mainly examples from Google calendar, which has a basic set of extensions. Others can be added.

Unfortunately, there are often no schemas for the validation of the extended Atom data available. To solve this issue, first Murata-san created an RELAX NG schema. Unfortunately, with more than 3-4 extension schemas, the task became really hard even for RELAX NG experts. He then switched to a different approach: NVDL, which is used for namespace-based validation of compound documents. This makes it easier to create schemas for Atom+extension validation. A remaining issue is that NVDL does not support validation of ID/IDREF-based types.

Using NVDL for Document Analysis and Synthesis

Miyashita-san from IBM also talks about NVDL. NVDL relies on analyzing, i.e. separating parts of a document for the purpose of validation. Miyashita-san's aim is to provide a mechanism for applying various other processing (e.g. editing) to the separated document parts, and put them then together again. He gives an example of Atom which contains XHTML. First the input document is separated in the Atom and the XHTML parts. Then format specific processing is applied, and the parts are put together again.

Miyashita-san demonstrates some testing with the Google Calendar data provided by Murata-san. One of his next goals for this framework is to use the XProc XML Pipeline Language as a means to define processing pipelines for the separated document parts.

On the HTML WG mailing list, Ben Boyle:

An interesting point, but I think this is highly dependent on whether you are publishing information primarily for browsers. Personally I like a combination of atom and html, both generated from a single source of data (for which I prefer XML). HTML is for the browsers, atom for feed readers and other (potential) consumers/aggregators. I use XHTML within Atom (personal preference to avoid CDATA where I can).

The browsers offer one rendered view of information on the Web among many possibilities. JSON, RDF, Atom, plain text, xhtml, html are parts of the choices to represent an information resource.

The Web exists because people wanted to connect to each others and share. They got involved. The first Web site was a kind of blog written by Tim Berners-Lee. People were experimenting, implementing, writing manual and tutorials. Tim was announcing the new servers that you could count each month on your fingers. You too can be part of it.

Just One Story Among Others

I have always known the W3C as a place to create and share. My academic background is not computer engineering. In 1991, I discovered the Web by chance on the computers of Physics Department of Montreal University and created my first two Web pages locally, page A and page B with just two links going from one to the other and back. I was really excited. In 1995, I was working in a Web agency in the Web design team: a biologist, a salesman, an english teacher, a lawyer, a journalist, a computer science student. We had the specifications such as Wilbur, HTML 3.2 codename, on our tables. Nobody was a specialist but everyone was helping each other. Some of us were translating in French the W3C specifications, others participating in forums, sharing quick tips.

On Going Discussions

Pointing fingers is sometimes necessary, but doesn't necessary achieve what we wanted. It often creates walls when we wanted to open fields. There are a lot of discussions about W3C, HTML and CSS these days, negative and positive comments. Jeremy Keith and Jeffrey Zeldman framed the discussions

If designers and developers are more aware of the problems than of the fact that the W3C is working to solve them, it's because the W3C is not great at outreach.

[...]

You want instant gratification, buy an iPod. You want standards that work, help. Or at least stop shouting.

Let me hear your standards body talk, Jeffrey Zeldman

In the comment Josh Stodola said What can I do to help , Jeffrey?

Get Involved!

I have written a few posts on this topic already and I will continue. Two days ago, I gave a link to the source code of an open source testing harness platform in PHP

• How to to contribute to W3C work? Tutorials
• How to to contribute to W3C work? Quick Tips

fantasai will publish on the CSS Working Group blog, in the next few weeks, a series of articles on how you can help W3C on the CSS front. In the mean time, a short list of tips to define your actions.

• Pick up one thing you can do for W3C. You have a job, a life, etc. Do not do too much but select one item that you have time to finish.
• Help with your own competences. If you are not a programmer, do not try to implement a specification. If you are a graphic designer, help with drawings.
• Listen and share. It is a community, a team work, it means a lot of patience, accepting to not have everything you want, but collectively to move forward.

You can be part of it too.

When I'm curious about tomorrow's weather (or need a quick look at a calendar), then I'll often invoke my laptop's Dashboard: It's a platform for Widgets, small applications written in HTML, CSS, and JavaScript -- Web technology, moved to the local host. These widgets provide front-ends to all kinds of information sources on the Web; several thousand are available for download. Obviously, the use of Web technologies has been a huge success here, enabling people to adapt their programming experience from the Web to their local platform. Apple's Dashboard is, of course, not the only platform: Google, Yahoo, Microsoft, and Opera have widget (or gadget) engines of their own; W3C's Web Application Formats Working Group has catalogued the properties of the various platforms in its widgets requirements document, and is working on a standard packaging format for widgets.

With the Web programming platform, though, come the Web's programming practices and security issues, sometimes with more serious consequences than before.

Let's begin with a classical piece of bad programming: Parsing data by evaluating it as code. JSON stands for JavaScript Object Notation; it means using JavaScript constant expressions as a way to transport structured data over the network. The easiest way to parse that data format consists in evaluating it as code. JavaScript has an eval() primitive that comes in usefully: It takes a string and interprets it. Now, one can argue that that's just the same thing as including another script, so it's not really a big deal when done in the client-side part of a Web Application. The effect is, after all, limited to one application, and that application's server-side code will have to deal with hostlie clients anyway.

However, while Widgets might feel a lot like the usual Web environment to the programmer, they really aren't: The limitations on what JavaScript code in a Widget can do are (sometimes vastly) different. For instance, the Dashboard has a widget.system method available; that method takes a string and executes it as a Unix shell script. Effectively, JavaScript has acquired an interface to the operating system. The question what scripts (or widgets) one executes has become the same question as the one what programs one installs. A widget that evaluates JSON data is now a way for an attacker to turn an attack against, say, a service like Twitter, or against your local network, into an attack that takes over an entire machine. That problem isn't just academic: Unsafe JSON parsing is a regrettably common programming practice among widget authors. And your web browsing behavior is intercepted whenever you're asked to pay at a commercial wireless hotspot. Exploiting these attacks is easy.

eval() isn't the only way to create this kind of attack surface: Using callback based JSON programming techniques by inserting <script> tags into a widget's document object model creates exactly the same kind of vulnerability.

But there's more: You might have heard of cross-site-scripting vulnerabilities as, for instance, the source of the recent Orkut worm. The problem here is that a Web application takes input from some untrusted source and writes it into the HTML that it generates, without paying proper attention to escaping tags that an attacker might have placed in that input. The attacker can then inject scripts into the Web application's output, and these scripts can confuse clients' behavior. Now, what has that to do with widgets? Consider that widgets use an HTML document as their user interface. Any data that are presented to the user are written to the that document by JavaScript code.

That JavaScript code might quite well use techniques like the non-standard innerHTML DOM property to add a large fragment of HTML to the user interface. If the data that are written to that property come from an untrusted source (e.g., the network), and aren't properly sanitized, then an attacker can once again get scripts executed.

The Google Gmail widget was an example for that kind of code, until quite recently. Here, HTML tags in an e-mail's subject header were written into the widget's UI without checking. The effect was stunning: One e-mail with the right JavaScript in the subject header was enough to take over the recipient's computer, if that recipient was running the Gmail widget. Google has now fixed the problem in this widget.

But Google isn't alone: There are more widgets out there with this kind of vulnerability. Triggering the vulnerability might not take an e-mail, but involve a network attack, or, maybe, a malicious blog post, a photo description, or some interaction on a social networking site. Or the widget itself might come from a malicious source. The point here is that we're dealing with a shift in what Web-style programming can achieve -- and that that shift does not come without risk, and responsibility. A shift, incidentally, that extends beyond just Widgets, as Web technology is also becoming the programming platform of choice for mobile devices, and as the capabilities of Web applications that run in the classical browser are extended.

Addressing this risk and responsibility will require work both inside the "Web industry" proper (and in the W3C Working Groups where it meets, including the Web Application Formats and Web API WGs), and with the broader community: This is a problem that extends beyond just the platform.

PS: I hope explore this space more at this year's Chaos Communication Congress in Berlin, and maybe at next year's Web Conference.

---

Disclaimer: The following post is my personal opinion, and not necessarily those of my employers. My colleague, Chris Mills provided feedback and suggestions for this post.

Since Opera’s antitrust complaint to the EC, some people have used the complaint as a catalyst to promote their agenda against the W3C and the CSS Working Group, with arguments flying on either side. There is no doubt that there are issues there, and action is needed. Transparency is one such issue, with many CSS3 modules not having been publicly updated since 2002. This gives the impression that it is moving at an unacceptably slow pace. There are also accusations that in fighting is delaying progress to suit various parties' own agendas. I’m not a member of the W3C CSS Working Group, so I can’t comment on how true this is, as I don’t know. I do know however that something has to be done, and the W3C has starting to make progress on remedying this issue. In this post I state where I feel the working group is right now, and propose some changes that I feel will help move things forward.

The current state of proceedings

Lets start with what they have done. They recently started a blog, in which they report on progress and issues. They’ve also created an aggregated feed of blogs and sites to report on CSS3 so that they can hear the voice of people that are discussing CSS3 outside the W3C, ie real world developers. They’ve also started working closely with css3.info. We have a CSS Soap box to let everyone get their issues off their chest, and they have written posts requesting feedback from designers saying what they want from certain properties. Is that far enough? Maybe not, but it is a beginning and I commend the work that Fantasai has done on this outreach.

Transparency of the Working Group

If this is where we are, where do we want to go? Firstly, transparency and accountability have to be greatly improved, so that if anyone is trying to hold up the process or are playing politics this is exposed, whether it is Opera, Microsoft, Mozilla or anyone else. I propose that minutes to meetings and any important documents or drafts are published on the working group blog.

Who should be represented on the Working Group?

Next, there are calls for browser vendors to be removed from the group. This is unworkable (disclaimer: I work for a browser vendor), for many reasons already exposed. I do strongly believe however that a better balance between designers, browser vendors and other parties has to be reached. Gibson or Fender don’t get guitar players to design their guitars - that would be ridiculous, as guitar players can play guitar, but the vast majority of them have very little knowledge of the processes involved in actually building a guitar. They design them themselves, with input from guitar players on what they want. Writing specifications is very difficult, especially when making sure they are implementable in not only a cross platform, device and browser independent way, but also cross culture and language. Test cases are difficult to write. Browser vendors have many of the best people in the business for writing these specs, as they are the kind of people we hire. Ian Hickson is widely regarded as one of the best specification writers of our generation, and he used to work for a browser vendor.

Keeping browser vendors out of the Working Group would also be difficult to police. For example Fantasai works for HP (I believe), but has close ties to Mozilla. Would she be counted as a representative of a browser vendor? Also, would designers be willing to give up what they are passionate about (designing web pages and other media) in order to work full time writing technical specifications? Why also should browser vendors be reduced to an advisory role, for technologies they have to do the hard work in implementing? If this were to happen, we would probably end up with a break away group similar to the WHAT-WG, of browser vendors that don't want to be told what to do by designers.

A power struggle isn’t what is needed - instead, we need a balance between vendors and designers. The specs should be left to the people that are good at writing specs, and enjoy it, the designers should be there to comment on if the proposals are useful in the real world, and the browser vendors should be there to comment on their side of things - whether the proposals are realistic to implement in their rendering engines.

The designers included could be part of an advisory panel of respected designers (CSS11 for example), adding more invited experts that are willing to spend their time on this and/or having a place where designers can post and discuss mock ups of what they want to be able to do with CSS3. CSS3.info for example could create a wiki where screenshots of desired effects for CSS3 properties could be added by designers, and the merits debated. New proposals could also be added. The WG could then refer to that site for ideas and to solicit feedback. I personally think that the HTML5 working group has far too many invited experts, so limiting the group to a select number, but allowing anyone to leave feedback would be more ideal. It is important that feedback is gained from multiple sources however - the needs of a Japanese designer is probably very different to the needs of a British designer, for example.

Speed of CSS3 development and relevancy of proposals

Furthermore, the speed of development of CSS3 must improve. Making the process more open to inspection will help this by making it harder to use stalling tactics. Action needs to be taken here - I’ve tried to get designers to send me feedback on what standards features they’d like to see in Opera first, but this is difficult, and I received little response. What we need to do is set clear priorities of CSS3. First we need to get the ’07 snapshot finalised (it is currently in Working Draft) and get browser vendors to implement those modules. This is going fairly well at present in three out of the four major browsers. It could also be going well in IE8, but we’ll have to wait to find this out.

In parallel we need to get a list of what properties designers most want to be able to use. Gather the most talented spec writers in the group to work full time, or as much as their employers allow, to mature those specs. It can be finer grained than a whole module, if other parts of that module have issues and are not related to the core properties that are needed. At each iteration, designers should review the progress to see if is moving in the right direction, and the feedback solicited from the working group if there are questions. Properties that have reached proposed final form should be marked as such, even if the rest of the module isn’t ready. These should then be given to the vendors to implement with the dash vendor prefix. Test cases should be built in parallel. Vendors should submit all that they have, while designers should help with this process if possible. The more test cases, the more likely it will be interoperable and the standard will be finalised sooner. These properties or modules should then be added to the CSS snapshot for the current or next year.

One question will be definitely be asked - which modules should be made a priority? Vendors will have an opinion on this, as it depends on the aim of the browser. Apple and Opera will care more about Media Queries than a vendor without a mobile browser, for example, but largely I think this should be down to the design community. If we had a public wiki to discuss this on, I’d suggest the modules or properties with the most active suggestions would be up there, while ones with no activity would be pushed to the bottom. Through the feedback I have collated, designers preferences seem to be borders & backgrounds, selectors, multi-column layout and web fonts, and there has also been interest in the grid layout (although this seems to be the furthest back in terms of both spec and implementations).

Another issue is who will work on these. That isn’t a question I can answer, but if we can somehow get the existing working group to be able to spend more time on it that will help. I’m willing to help out if desired. It should be easier for big companies such as Yahoo! to supply people to represent designers as they have the resources. The problem is that many of the most highly regarded and vocal designers are freelancers that can’t afford to give their time for free. We need to find a solution for this, be it through sponsorship or other means.

Can browser vendors work together?

The other concern that has been raised is that, in light of Opera’s complaint against Microsoft, the browser vendors wont be able to work together. I don’t believe this to be the case. Håkon has stated he has no problems with Microsoft employees, and I’ve personally heard him say he has great respect for the likes of Chris Wilson. I’ve also heard the same coming from Chris. I know or have worked with the likes of Chris, Markus Mielke and Joshua Allen for a while now, and I very much hope that continues. I’m sure they’ll also agree.

Conclusions and the way forward

What we need most of all is action and not talk. I propose the following:

• Get a priority list of CSS3 modules or properties hammered out for both the W3C and the browser vendors
• Get the modules included in the ’07 CSS snapshot to recommendation stage, and push browser vendors to implement them
• Aim to get these priority modules ready for the next CSS3 snapshot ('08)
• Put a mechanism (such as a Wiki mentioned above) in place to give feedback on the issues the WG come up with
• Promote the said mechanism to developers in multiple countries, such as those that use none-latin scripts, and right to left text
• Re-engage the Web Standards Project (WaSP) to take an active role in the activities
• Get the W3C to open up the private communications of the WG, so there is transparency for all to see. Post communication on the Working Group blog or another suitable medium
• Get an official statement from each of the browser vendors on the working group that they are willing to work together in a co-operative and unhindered manor
• To ensure a fair balance between designers and browser vendors on the working group, build a short list of respected designers or developers who should represent designers on the working group. We can get a respected designer like Molly or Zeldman to propose people, again making sure there is diversity of opinion.

Find a way to fund these designers, either through W3C funds or corporate sponsorship

Ensure the chosen designers can commit the required time to the project

Ensure there is at least one designer assigned to each of the modules that are deemed a priority

This post was also cross posted on CSS3.info.

---

I've been silent on the whole Opera complaint (note: not a lawsuit, so please stop calling it that) against Microsoft so far. I was as surprised as everyone when it happened. However, I want to take a quick break from the silence to congratulate the IE team on the fantastic work they've done on passing the ACID 2 test. This must have taken a lot of work and Microsoft have some very talented people in Chris Wilson, Markus Mielke and the rest of the team. My main question is if this is regular standards mode, or a special IE flag that puts IE8 into a stricter standards mode?

Does this mean the end of Opera's complaint about Microsoft's commitment to standards? I'd hazard a guess at no, as ACID2 isn't a full test of standards, and it is only one step on the way. There are many things that are important that it doesn't test, and doesn't even touch on DOM, JavaScript, SVG, CSS3 and the like. It is certainly a huge step in the right direction however. I personally hope they are fixing issues in their regular standards mode, as even if it breaks sites in IE (and I more than anyone would understand why that is bad, and how hard it is to get sites to fix issues), leaving the bugs as they are means many sites, built by people that don't care about standards, design for the broken IE behaviour and break in Opera (and other standards based browsers) without any way for us to fix the sites ,except for to beg and prey to the sites for them to fix it. This is obviously even harder for us to convince them than MS as we have less market share. Korea is a perfect example of a country that almost solely designs for IE bugs and Active-X.

Speaking of Active-X, it would make my day even more if IE8 drops support for this technology. That is a perfect example of why the browser wars that some designers are calling for is a bad thing. That would truly be something to smile about :). With all Microsoft's know how in building Silverlight, I'm also looking forward to see if there will be announcement about SVG support. more transparency is always a good thing.

Lets raise our glasses to the IE team, and hope they continue on this promise. I'm looking forward to the next ACID test :)

During the past week’s drama related to Microsoft’s lack of transparency and problems with working groups and browser vendors, it literally pained me so to have to keep my mouth shut when I knew there were some very good things happening.

I’m glad Bill Gates truly took the time to look into the communication issues, because to quote the man himself from our conversation last week: “There’s not like some deep secret about what we’re doing with IE.”

From the IEblog today, Dean Hachamovich writes:

“Now, with all that context, I’m delighted to tell you that on Wednesday, December 12, Internet Explorer correctly rendered the Acid2 page in IE8 standards mode. While supporting the features tested in Acid2 is important for many reasons, it is just one of several milestones for the interoperability, standards compliance, and backwards compatibility that we’re committed to for this release. We will blog more on these topics . . .

For IE8, we want to communicate facts, not aspirations. We’re posting this information now because we have real working code checked in and we’re confident about delivering it in the final product. We’re listening to the feedback about IE, and at the same time, we are committed to responsible disclosure and setting expectations properly. Now that we’ve run the test on multiple machines and seen it work, we’re excited to be able to share definitive information.

Would jumping up and down and saying “I told you so” be in order? No, because I couldn’t tell you so. However, I have long been saying that some good things are happening up in Redmond. I applaud the developers who had to keep their mouths closed due to NDA’s and did so under heavy scrutiny, and I applaud all those at Microsoft working hard and proving that they not only hear developer’s needs but understand them and are truly working to make a difference.

Bravo, IE Team, for the hard work and most especially for finally getting the go-ahead to restart this much needed conversation.