Open Subtitles Design Summit – Interacting with the W3C

In my previous post I talked about the Open Subtitles Design Summit. I attended numerous sessions one of which was a discussion on how to interact with the W3C. The W3C stands for World Wide Web Consortium and its purpose is working together to develop standards for the World Wide Web. Read more here.

For a long time I thought that the W3C worked alone to make these standards and that there was no way of collaboration with them. However, I found out that this was not true. In fact, this is quite the opposite. Let me run down the process. I will be using the SVG specification document for my examples.

Find the technology/ standard you want to talk about

The W3C has 60 different specification documents dealing with different web technologies. Due to the large-scale the W3C has different working groups dealing with the technology/standard. Think of it like a different department of the same company. This means that each department will have their own way of accepting feedback this may include email or bug filing. The link I provided above for the SVG spec document is an example of the Scalable Vector  Graphics technology/standard. To find this document I usually type “w3c svg spec” on Google.

Figure out how to contact the right people

Each specification document follows a similar (if not the exact same) template. The very top of the document tells you when it was last edited. So if you look at my SVG example you will see that it was edited on”W3C Working Draft 22 June 2010″. Further down you will notice a section entitled “Status of this Document”. This section will let you know how to get involved. Back again to the SVG example, you can send your issues via email to www-svg@w3.org. You will also notice that the document states that last call ends on 13 July 2010. What does this mean? Last Call means that the group is believed to have finished the specification. If you believe that the outline specification will not work in some instances you should contact them before Last Call and demonstrate why. After Last Call it is very hard (but not impossible) to change the specs. This does not include clarifications to the documents.

Best Practices for Contact

So you know who to contact but what do you say. The best way to prove your point is to illustrate it. This means provide basic examples of features that you believe need fixing. Basic is the key term here. Attaching a simplified test case is key. Do not include extra css, or libraries that will complicate the code. For example if you believe audio looping is broken (which it may be on Firefox) provide a simple html page with one audio tag with no other div, images, or html elements.  You want people to look at the code and not have to dissect it.

Other interesting features

The “Status of this Document” section also often gives you a link to a test suite. A test suite is a collection of tests that is used to check the browsers compatibility/behaviors. This is the tool the W3C uses to check if any part of the specifications are broken or not supported in the browser. Why wouldn’t a browser support the specification? With the frequent changes it is hard for browsers to catch up. Some browsers choose to support older specifications along with newer ones while others only support the newer ones. Either way the changes wont be available to the public until the browser (Firefox, Opera, Safari, Chrome) releases and updated version.

For more notes on this session check out the wiki.

View all of my blogs