I spoke at An Event Apart yesterday, you can see my slides and resources here. One of the themes of my talk is that anyone can contribute to the web platform, and CSS in particular. I had loads of questions from atttendees about this so here is a quick list of getting started suggestions, with a focus on CSS as that’s what I know best. If anyone has similar advice for people wanting to work on other parts of the web platform, let me know on Twitter and I’ll link it up.
Get familiar with the specifications
To be able to contribute to specifications you first need to be able to read them. Thankfully modern specs are a lot more readable than they used to be. I wrote an article for 24 Ways last year about researching a property in the CSS specifications, which is a good start in terms of learning to read a spec.
This will be helpful to you as a developer, you’ll be able to look at the source rather than read an interpretation someone else made of it. It may well also offer up initial ways to contribute, you might spot a spec that has issues related to diagrams that are needed, or come across a typo. If there is already an issue raised for something you should be able to follow it to the CSSWG GitHub repo, and if you spot something yourself, you can raise an issue.
Respond to issues that request feedback from authors
When the Working Group talk about authors, they are talking about people who write CSS, so that is web designers and developers – but also people who write CSS for other media. Sometimes we have issues that need feedback from authors. There are a few of us who will use Twitter to send people to these issues. Me, Jen Simmons, Lea Verou and Amelia Bellamy-Royds are all good people to follow in that regard.
If you have a use case, or some other thoughts on the issue, add a comment. While there are some authors represented in the Working Group, we’d generally rather not become the voice of all authors, so your feedback will be welcomed.
Raise issues for things that you need
As I said in my talk yesterday, don’t worry that you haven’t got the solution, or even that your suggested solution might be unimplementable. It takes many heads to actually create new CSS, and that is what the CSS Working Group is for. It may be that your use case is ultimately solvable in a different way to what you imagined, but knowing that authors need a thing is a very good place to start. These suggestions do get brought up at meetings, while it may seem that othing happens on an issue for a long while, it isn’t because we aren’t interested. It is likely that the things it touches just haven’t been a recent focus.
I mentioned the Web Platform Tests project to a few people after my talk yesterday. Writing tests is a very good way to get into the world of the web platform, it is also an excellent way to contribute as it takes work off the plate of specification authors. Also for 24 Ways I wrote about how to get started.
Other ways to help
Stepping away from contribution to the specifications directly, having something written up in a spec is only the first step – we also need to have browser implementations, and we need those to work according to the specs. If we take the subgrid feature for Grid Layout, we know that is being implemented right now in Firefox, I’ve been playing with an early implementation. However it is not currently being worked on in Chrome. A two-minute way to help there is to head over to the Chrome bug and star it to show your interest.
If you find a browser bug – especially with new features – you may be the first person to encounter it. Have a search on the browser bugtrackers and log it if you can’t find a match. Learning how to create a reduced test case is a skill you need to hone to be involved in a lot of this work, reducing and reporting issues a good way to practice!
Writing up your ideas for features, or your desire to see a feature implemented is also very useful. It demonstrates a need for that feature from authors, and that can help inform the roadmap for browser vendors as well as the working group. Also, if you are a person who has done the work of understanding a spec and thinking deeply about a feature, you can encourage more authors to get excited about it by sharing it in an easy to understand way. Pretty much all of the writing and speaking I do is along those lines, particularly when talking about new features. It definitely takes time to get to a point where you can understand from a spec along how a feature will work, with no implementation to test against, I don’t assume everyone wants to spend that time. Instead I write things which explain the feature as if it already existed, and make diagrams or mocked up examples to show how it works. That approach worked well for Grid Layout, it meant I could get people interested long before they could really play with it.
There isn’t really one way into standards work, it requires curiosity, willingness to understand issues from many points of view, free time unless you have an amenable employer, and often a fair bit of tenacity. There are rarely immediate results! Start by following along with our work via the GitHub issues, comment on relevant things, and learn to read specs. You will probably find that you become more involved over time if this is something that you enjoy doing, and you will definitely learn a lot!