A few weeks ago, I had the honor to be appointed as part of the editorial team of the W3C HTML5 specification.
Since Ian Hickson had recently decided to focus solely on editing the WHATWG HTML living standard specification, the W3C started looking for other editors to take the existing HTML5 specification to REC level. REC level is what other standards organizations call a “ratified standard”.
But what does REC level really mean for HTML?
In my probably somewhat subjective view, recommendation level means that a snapshot is taken of the continuously evolving HTML spec, which has a comprehensive feature set, that is implemented in a cross-browser interoperable way, has a complete test set for the features, and has received wide review. The latter implies that other groups in the W3C have had a chance to look at the specification and make sure it satisfies their basic requirements, which include e.g. applicability to all users (accessibility, internationalization), platforms, and devices (mobile, TV).
Basically it means that we stop for a “moment”, take a deep breath, polish the feature set that we’ve been working on this far, and make sure we all agree on it, before we get back to changing the world with cool new stuff. In a software project we would call it a release branch with feature freeze.
Now, as productive as that may sound for software – it’s not actually that exciting for a specification. Firstly, the most exciting things happen when writing new features. Secondly, development of browsers doesn’t just magically stop to get the release (REC) happening. And lastly, if we’ve done our specification work well, there should be only little work to do. Basically, it’s the unthankful work of tidying up that we’re looking at here. 🙂
So, why am I doing it? I am not doing this for money – I’m currently part-time contracting to Google’s accessibility team working on video accessibility and this editor work is not covered by my contract. It wasn’t possible to reconcile polishing work on a specification with the goals of my contract, which include pushing new accessibility features forward. Therefore, when invited, I decided to offer my spare time to the W3C.
I’m giving this time under the condition that I’d only be looking at accessibility and video related sections. This is where my interest and expertise lie, and where I’m passionate to get things right. I want to make sure that we create accessibility features that will be implemented and that we polish existing video features. I want to make sure we don’t digress from implementations which continue to get updated and may follow the WHATWG spec or HTML.next or other needs.
I am not yet completely sure what the editorship will entail. Will we look at tests, too? Will we get involved in HTML.next? This far we’ve been preparing for our work by setting up adequate version control repositories, building a spec creation process, discussing how to bridge to the WHATWG commits, and analysing the long list of bugs to see how to cope with them. There’s plenty of actual text editing work ahead and the team is shaping up well! I look forward to the new experiences.
I’m only half clear why you would take on this task. I’ve done the same job. Like you say it isn’t very exciting, but it matters to a huge number of people that it gets done right.
So I am very grateful that you have stepped up, and that W3C appointed you.
Good luck.
@chaals Thanks. I guess I do it for the same reasons that you used to do it. 🙂
@sfsdf I’ll look at whatwever bugs I come across at the W3C. Your zooming issue doesn’t seem to be a spec related bug, but rather an implementation quality issue. You should fix a bug with the browser in which you’re experiencing it.
Thanks for caring about specifications.
Will this mean that you will also look over scaling of content aspects?
(Sometimes I zoom in a website to better see text but the way images and other elements are scaled makes it very hard to follow the text where I was. The whole content is seemingly transforming shape. Visual impaired people might have to zoom in to be able to read so this makes it an accessibility thing.)
And please somebody correct the mistake about using html without version number in the doctype! For this fixed specification there should be a mandatory version number in the doctype. For html5 web developers want a clear and STABLE specification.
Furthermore I don’t have any more specific things that are a horrible mistake.
@sfsdf versioning is a terrible idea. HTML has no version – that is what makes it awesome … Constant evolution, progressive enhancement, etc. Versioning on the Web makes no sense and has no use case (and if you need it, you are doing it wrong).
Silvia, wishing for a speedy rec 🙂 happy editing.
Here is the use case for version numbers:
websites that can keep working indefinitely.
HTML has a version!
And versions is something all file formats should have.
For constant evolution we need to be able to change things.
To be able to change things we need a way to be able to change the specification and keep things working.
Versions for stable points allow this.
We could reserve html without version for the living standard and have version numbers for well defined versions with well defined behaviour.
@Marcos
HTML has versions. Lots of html also has browser specific versions browser specific things, these are the horror by the way and has no place on the web. Progressing the specification and evolution will sometimes require that we will change things. We need to be able to build websites that work and keep working. How do you expect to do both (websites keep working and evolution) without having some way of signalling what kind of specification your website uses? If you don’t use versions, you are doing it wrong.
@Silvia
Thanks for reading and responding to my post. I have seen many websites that don’t do scaling very well. What can be done is to make the specification as clear and easy to understand as possible. Make doing the things right as easy as possible.
@sfsdf, @Marcos let’s please not have the discussion of versioning in these comments – it’s been discussed to death at the W3C and has advantages and disadvantages. Let’s move on to something more constructive.