We have just announced that the deadline to send (1 to 5 pages long )position papers for the W3C Workshop on the Future of Social Networking has been extended to 3 December 2008 - the initial deadline ended today.

This is a great opportunity to take some time and put your ideas on even just one page. Be part of this exciting workshop! We got a flow of excellent submissions so far, so do participate and we guarantee that you'll spend two days in excellent company with your peers and future partners!

If you really can't send us a position paper, there is another way to participate in this highly visible workshop: sponsor it! We offer a wide range of benefits and one of them is a great visibility of your what your business is. Choose your level of participation and have your organization logo displayed on the W3C home page (300 000 page views per day!) and/or the W3C Mobile Web Initiative Web page, and many more.

Do not miss it! and looking forward to meeting you in Barcelona.

TPs (expanded as Technical Plenary and Working Groups Meeting Week) are the biggest W3C yearly events. They attract between 300 and 400 individual participants.

I have had the chance and pleasure, since 2002, to organize the four ones that took place in Mandelieu (France) every two years. The other four took place on the East Coast, every two years, since 2001.

Organizing TPAC2008 took about 2 years. The closest to the event, the busiest I was, of course.

In my TPAC2008 e-mail folder, I have accumulated 3132 messages, starting early November 2006. That is twice as many as the previous TPs I had planned. I could say it is because I have organized the TPAC2008 twice :) We had almost signed the contract with a hotel in the centre of Paris when we resolved in September 2007 to withdraw from a deal that was too expensive for us. I was glad I had started so early. I now had about a year to organize TPAC2008.

In order to experience the joys of TP planning, there are a number of challenges to face.

Including the Advisory Committee Meeting (the "AC" part of "TPAC") was not a challenge, really.

The biggest challenge is to find the venue that is accessible and can accommodate our meeting needs, and we need to have about twenty meetings taking place at the same moment, and preferably at the same venue :)

Back in 2001, I visited a lot of hotels and conference venues on the Riviera before finding the one hotel that had a sufficient number of meeting rooms. We were lucky it was a hotel since it is so much more convenient for participants to stay where their meetings take place. This time, the hotel was more expensive than previously (although still quite cheaper than Paris), due to a complete refurbishing of the place.

The next big challenge is a jigsaw puzzle. That is, to compile the data after asking which groups want to hold a meeting, what pair of days (Monday-Tuesday or Thursday-Friday) they prefer, whether they are flexible or not, what other group(s) they need to meet with for joint work, and what other group(s) they can't meet with because they have a significant overlap.

The best tools I found for that exercise are a pencil, a big sheet of paper, a rubber and sometimes post-it notes to move groups from one side of the sheet to the other. The best aid was coffee :)

Another challenge is to determine the number of hotel rooms to reserve. If I reserve too little, the discount rate is not optimal and participants may end up needing to reserve somewhere else. If I reserve too many, we face the payment of penalties.

Because meeting rooms and working groups have different sizes, the challenge is to make sure each group has enough room for the participants. We need to take accessibility into account at this stage too.

Last, but not least, the registration is quite a challenge. On two fronts, at least. From the participants' point of view and from the admin's.

You can trust a registration form for such an event to be somewhat complicated, or a combination of long and complicated. While we try to make it as intuitive as possible, there are quite a number of people who are confused, or in a hurry, and submit ambiguous registrations. And there are people who just don't register in time, or don't bother to register at all, no matter the amount of reminders I send... I think it is a shame.

And then there are the joys.

The week prior to the event is most intense. We stop registration and go over most of the registrations till our data is flawless. We tally people and confirm the number of meals with the hotel. We make final changes to the room allocation. We print badges. We print documents. We pack boxes. We carry boxes to the venue and then the meeting is ready to start.

There are the joys of people who have been happily assisted and show appreciation and gratitude. There are the joys of being helped by other colleagues. There are the joys of seeing again people. There are the joys of fruitful live discussions. There are the joys of quick efficient solutions to problems that arose. At the end of the day there is the joy of a day that went as planned, and at the end of the week, the joy that the meeting is now history and that it went as planned. More or less. More than less, usually.

Discovered through twitter, there is an interesting blog post from Kroc Camen on how to learn HTML 5. The author is giving good essential guidelines on semantics and elements. The conclusion of his blog post is spot on and shows one of the painful points of HTML 5 specification:

Once you have made a decent HTML4 site, then you will look at the HTML5 specification, and it will make sense—you will know what to do with it.

A document is being written for filling this hole: The Web Developer’s Guide to HTML 5

HTML 5 is a giant specification. It contains things related to the content model, the APIs, the DOM, the parsing algorithm, etc. We received many comments that it was very hard to read for simple implementers and documentation writers who would like to better understand how html 5 documents are written.

Discover the editor's draft of HTML 5: The Markup Language! Mike Smith has extracted the parts of HTML 5 related to the content model. This document is aimed at people who would like to focus on the content model, be reviewers, authoring tools implementers, documentation writers.

We hope that it will help everyone to have a better understanding of html 5 content model. An additional document should be provided in the future for learning about html 5 with the name Web Authoring Guidelines.

Very often, when you are negociating a new Web site for your organization or company, the Web designer will hand over a photoshop mockup of your Web site. Personally, I have a tendency to ban this practice. I prefer to receive a solid xhtml/css mockup and sees how it is handled in different devices.

The community around SVG is building up a new Web site. They decided to use SVG for the wireframe mockup of their Web site.

A few weeks ago, for designing the W3C Chairs tee, I have used a vector authoring tool, OmniGraffle.

We asked me for an SVG version of the bots. Omnigraffle has an "export as SVG" feature, like many modern vector tools. I had the curiosity of looking at the source code… All my beautiful squares and circles were gone. All shapes were only defined by paths. Some shapes are rightfully defined by paths, but it should not be the case for all of them. I became curious about this issue.

When using a vector authoring tool, be omnigraffle, inkscape, illustrator, etc., for drawing simple shapes such as circle and rectangle, I use the menu.

These menus have a graphical semantics. There is actually a square or a circle to represent the shape. For a square, I'm not drawing 4 paths but a real square. I want the authoring tool to retain my semantics choices when possible. Imagine an HTML editor which would convert all your paragraphs in series of <br/> instead of <p>…</p> (yes those exist too). For a square in the authoring tool, I would like to have a rect inside the SVG file. For example, a 50 pixels by 50 pixels square should give:

<rect x="1" y="1" width="50" height="50"
      fill="none" stroke="black" stroke-width="1"/>

We can even go further. Many vector authoring tools have the capabilities of groups and layers. These information could be used for creating groups of shapes and/or labeling shapes with unique identifiers id or defs.

I discussed about it with Doug Scheppers, SVG Working Group Staff Contact, who is in the office in Japan these days. We don't know any SVG authoring tools which preserve the semantics. If you know one, please leave a comment. And I said that would be part of optional or mandatory requirements of a future version of SVG for the authoring tools class of products. Doug has created issue 2178 in the SVG Working Group tracker. In the mean time, I will have to redo my bots by hands ;)

A couple of weeks ago I attended, along with a few hundred other W3C participants, the yearly Technical Plenary meeting: a week's worth of meetings, encounters, ideas and exchanges. For many of us, this is the most exciting and exhausting time of the year: it takes quite a lot of stamina to survive through a week intellectual and geeky stimulation from breakfast to bedtime.

Discussions at the TPAC week have born some wonderful fruits we will soon talk about, but today I wanted to share a thought experiment started over lunch on the technical plenary day. Daniel, the co-chair of the CSS Working Group, was waxing lyrical about the power and simplicity of a CSS engine entirely built in javascript: simple, fast, portable across platform, distributed computing needs… What about rewriting the CSS validator that way?

I don't yet have a clear opinion on Daniel's idea, but I like his approach. The CSS Validator is now a 6-years-old piece of software with a level of complexity deriving from years of following the CSS specifications and their evolutions, a reasonably low amount of known bugs, a test suite, and only few souls brave enough to dive into its massive collection of java code.

What if we started again from scratch today? What if today we build a brand new CSS validator? Or, better, what if today we build a brand new tool to help bring better CSS style sheets to the web? What would you build? What would you want to use?

1. What would the basic features of that tool be? How would they be different from the existing CSS validator?
2. What would the cool extra features of that tool be?
3. What engine, what language would you build this tool with?
4. Would you sacrifice some flexibility for performance and simplicity? For example, one of the very costly features of the current validator is to have different tokenizers, parsers and grammars for CSS1 CSS2 and CSS2.1. Would it be a big loss if the tokenizer and parser were only defined by the latest stable CSS, while keeping the ability to check against each "profiles" (properties and values)?

• Update 2008-11-12: clarified the last question about “obsolete” CSS 1 and 2.
• Update 2008-11-12: there is an entry on a public w3c wiki with a section on the vision and roadmap for the CSS validator. Let's record the ideas of this blog conversation on the wiki?

Last week in Tokyo, there was the wonderful Web Directions East 2008. It was yet another opportunity to hear and discuss how people feel about W3C open Web standards. Two patterns often arise in these discussions: implementation first and specification first. Both lead to reproaches.

Implementations first

Most of the software companies deploy all kind of technologies in theirs products. They do it to get more market shares. Sometimes the technology is getting traction in the development world. Other companies have a few choices:

• Implement a competitive technology based on the same principles.
• Implement the original vendor specification (against fees or freely depending of the license).
• Implement the same set of features by reverse engineering when the vendor specification is not available.

All of these solutions have issues ranging to patents, licenses, implementations bugs, interoperability, collective consensus. But fortunately some of them after a while will reach the W3C and get into a Working Draft at least, and hopefully a Recommendation. Canvas (Apple) and XMLHttpRequest (Microsoft) are following this pattern.

In this case, W3C is often perceived (mostly by software implementers) as a slow organization, not being on the edge and not creating innovation. Another part of the community thinks that it is good that W3C has his head on his shoulders and standardized only market proof technologies. Standards mean here stability of the market.

Specifications first

A group of companies have an interest in technology. They feel there is a need to develop a market or they have an issue which needs an interoperable technology to bring stability in the market. The W3C Activity and related Working Groups are created. Sometimes they will use the deliverables of an incubator group, of a workshop or even from W3C Member submissions. In the best case, the Working Draft documents are published at a regular pace with the relevant implementers in the Working Group.

It is a long process to reach agreement, to solve the issues. Each working draft is published openly under the patent policy. The public sees all the evolution of the technology, phase that they could not see in the first case. They often draw high expectations, followed by sometimes disappointement to see things being stalled, not going fast enough or not evenly implemented. CSS, XML, SVG are examples of this pattern.

W3C is often perceived not realistic by some Web communities which can't use the technology right away. Somme communities feel that W3C is a leading organization exploring markets and creating the base of a new architecture. Standards mean here innovation for the market.

An Open Web Social Platform

Both cases will bring bad and good karma to W3C. There are more than one community, sometimes they are quite disjoint or with a very different culture, approach with regards to the technology. And honestly, I'm not sure there is one solution that would satisfy everyone. But at least, I know that until now, the W3C Process has been flexible enough to accomodate a lot of different cases and needs. Under the market and the communities needs, the W3C Process has evolved. Remember the patent policy debates for example.

In my 8 years of working here, I come to think that W3C is a social platform for developing Open Web Standards.

Sometimes, we often forget that the value of the technology is in human. We had recently the Technical Plenary where all W3C participants usually meet once a year. Many people from W3C staff (the W3C Team) are traveling to attend this event. We use this opportunity to meet during one day and discuss issues across the Team, the Web standards, to redefine what we believe in, to chat about our local lives, some people leaving, some babies to born, just life. Each year we take a W3C Team group photo. This year photo has been taken by Richard Ishida.

I'm always amazed by how good and dedicated all these individuals are to the W3C mission. This is true for those you know, the front line Working Group Technical staff contact, but W3C is working because of all administrative and system people.

Today W3C WAI published WCAG 2.0 as a "W3C Proposed Recommendation". This means that the technical material of WCAG 2.0 is complete and it has been used successfully in real websites. Up next: final publication as a Web standard "W3C Recommendation", which we expect in December!

Over the last few months, the Web Content Accessibility Guidelines (WCAG) Working Group has been going through a process to ensure that WCAG 2.0 can be implemented. Developers and dsigners from around the world gave WCAG 2.0 a "test drive" in their own Web content.

The result: Successful implementations in a wide range of sites including education, commerce, government, and a blog; in languages including Japanese, German, English, and French; and using a wide range of technologies including scripting, multimedia, Flash, and WAI-ARIA. You can get the nitty-gritty details from the Implementation Report.

We learned more about how people use WCAG 2.0 and got additional feedback that resulted in a few changes from the previous publication.

Now that WCAG 2.0 technical material is stable and is proven implementable, there's one more step: submit WCAG 2.0 Proposed Recommendation to W3C Members for final review and endorsement. That takes us into December.

Over the next few weeks we'll also be updating existing WCAG materials and providing new materials to help transitioning to WCAG 2.0; for example, a printable version of WCAG 2.0 at a Glance and more WCAG 2.0 presentations.

But you don't need to wait for any of that. There are a lot of reasons to start implementing WCAG 2.0 right away. See "What are the benefits of using WCAG 2.0?" in the WCAG 2 FAQ.

Note that the best place to start with WCAG 2.0 is not necessarily the technical standard itself. Instead start with:

• Overview of WCAG 2.0 Documents
  
• How to Meet WCAG 2.0: A customizable quick reference to WCAG 2.0 requirements...
  

As always, we welcome suggestions for improving these supporting documents, and we encourage translations. Each document has an e-mail address for comments, which is often in the footer, e.g., "Feedback welcome to wai-eo-editors@w3.org."

Thanks for all the support moving WCAG 2.0 towards completion. We look forward to seeing more websites and web applications meet WCAG 2.0.

After a keynote by Tim Berners-Lee on “cleaning the web”, the plenary day of the TPAC 2008 is now in its second session, and the conference room in Mandelieu is packed with participants.

If you are not in Mandelieu, you may not get the whole experience and will miss the great corridor discussion during the coffee breaks, but you can still listen to, and participate to the discussions: tune in to the audio soundcast of the presentations, and join the live discussion and scribing on IRC (join channel #tp on irc.w3.org:6665 )

The work of W3C is sometimes a bit opaque. It is not obvious to people outside of the Working Group. You often only read the end result, a Working Draft, even sometimes the specification.

Yesterday in the WebApps (Web Applications) Working Groups, a discussion has started about a normative reference from XMLHttpRequest to HTML 5. XMLHttpRequest is the technology used in AJAX applications on the Web. XMLHttpRequest is more mature and in the final stages for going to last call and hopefully in a few months a W3C Recommendation. HTML 5 is still in high development and not stable at all. There is still work to do on it. Two options were proposed:

• Should the normative requirement in XMLHttpRequest be a reference to the specific prose in HTML 5?
• Should the normative requirement in XMLHttpRequest be included in the prose of XMLHttpRequest?

There is no formal Process requirement on this, because it is highly dependent on the type of the technology and its level of maturity. The W3C Process Document is here to help and be flexible to many use cases, and not be a hurdle. There is an internal W3C Technical Report publication processes. When a document is moving to Proposed Recommendation, it has to satisfy all exit criterias of Candidate Recommendation. In this document, we can read

Evidence that dependencies with other groups met (or not)

Does this specification have any normative references to W3C specifications that are not yet Proposed Recommendations? Note: In general, documents do not advance to Recommendation with normative references to W3C specifications that are not yet Recommendations.

Is there evidence that additional dependencies related to implementation have been satisfied?

What does it simply mean? Normative references to moving targets are dangerous.

A while ago Dan Connolly told us something along these lines: "W3C Chairs are doing very hard work. I would like a t-shirt to thank them." Daniel Glazman asked us often if we could have cool W3C gears. So the Communication Team started to think about what we could do, exploring ideas. TPAC seemed to be a good opportunity to materialize this. We designed a special t-shirt for the chairs.

Meet Zakim, RRSAgent and Trackbot, 3 home made bots which are essential to W3C Working Group life and are the chairs angels.

• Zakim, the phone, is the bot connecting people on phone and controlling the agenda of meetings.
• RRSAgent, the tape recorder, is recording the IRC log and help to create minutes of meetings.
• Trackbot, the toolbox, is the bot for creating and tracking issues and action items during meetings.

The W3C TPAC 2008 is happening in the south of France near the city of Cannes. The hotel is not close from any fiber optics, which gives certain challenges when you need to provide network for a lot of geeks with their computers working for one week on Web technologies. Vivien Lacourba, W3C staff, gave me a few details about the network.

Orange, the company providing the network, installed a router with 4 ADSL lines (1 Mbs uplink and 6 Mbs downlink each). There will be around 365 participants during the week, with an expected peak of 275 persons. The wifi should be accessible pretty much from everywhere on the conference site.

Let's hope that everything will work well and without troubles. If you had troubles with the network during the meeting, contact Vivien Lacourba (see the photo). He will try to help you.

Sunday, I'm at the conference site, helping people here and there for a couple of things. TPAC stands for Technical Plenary and Advisory Committee. It's a unique moment in the year where people involved in W3C communities meet, discuss, argue, fight and make peace, have good food and sweat on tough issues. It's usually a very interesting week, which helps to remove a lot of misunderstandings built during one year because of online communications.

Just had lunch with some members of the CSS Working Group, they are the only people meeting today. The big show is starting tomorrow.

There were discussions about test cases with Anne and Elika. I discussed a bit of Montreal with Murray Malloney and Steve Zilles (Adobe). Daniel Glazman also shared with me some ideas around W3C gears such as t-shirts. I know that many people would be interested by a W3C shop and we have been testing stuff around this idea for months. We also discussed about the future of validators. Standards Suck released an initial video post explaining the W3C Technical Plenary.

Everything is already set or just in the process of being finished. Active, active, if you like the organization during the meeting, don't forget to thank Amy, Alexandra, Coralie and Kanako.

Let's start. And don't forget to follow and participate to the online discussions Photos, Messages, blogs, blogs.