A fairly large amount of time of creating Fidus Writer has been communicating with other editors and web standardization groups. With Fidus Writer we are oftentimes reaching the limit of what is currently possible to do on the web. That’s why we feel it’s important to participate as much as we can in helping the web move forward. But how does this work? And why does one need to communicate to others at all instead of just creating something new and being a good example to everyone else? Developing a software to run inside of browsers rather than by itself as a program one has to install on a computer has several advantages: installation is easier, also for non-techies, there are established ways of communicating with other users, and the software will normally run on modern versions of Windows, Mac OS X and Linux automatically. However, there are also some disadvantages. The main one is probably that one depends on the features that browsers provide. Within any specific are oftentimes browsers either don’t provide the same functionality or they do so in different ways. Or they claim to provide a certain feature in the same way, but the different browsers have bugs so that in practice the same code will not run in the same way on all the browsers. This does that certain parts of the code one needs to have in different versions: one for Chrome, one for Firefox, one for Safari, one for Internet Explorer, etc. . Luckily the browser makers are aware of the problem, and try more or less to follow standards on how to provide features. For the creation and maintenance of those standards there are different organisations: like the World Wide Web Consortium (W3C), or the Web Hypertext Application Technology Working Group (WHATWG). And then there are subgroups for specific areas such as the Cascading Style Sheets Working Group (CSSWG) for questions related to styling. These groups communicate in all kinds of ways (physical meetings, emails, weekly calls, etc.) and try to write documents together that describe how certain things should work in all browsers. But the relationship between browser makers and standardization groups and organizations is not straight-forward: Although all the major browser makers have a lot of people involved in the meetings of the standardization groups, it is not thereby said that they will implement all the standards that come out of that standardization group. Take for example the text entitled CSS Generated Content for Paged Media Module (a standard on how to style page numbers, headers, etc. when printing a webpage or otherwise display it as pages). Although it has the support by Opera’s CTO Håkon Wium Lie, who edited it for years, so far it has not been implemented in any of the major browsers. At the same time there are many features in browsers that the developers of that browser came up with at some time without making a standard of it. Back in the days when Internet Explorer was the most-used browser, Microsoft was oftentimes accused of bypassing standards and just pressing their own way of doing things through. Because their market share was so large other other browser makers oftentimes had to copy the behavior of Internet Explorer. Google’s Chromium team, which now represents the largest browser with close to 50% market share claims to have learned from that experience and not to do the same again. This is why web standards and how browser makers see those standards matters. Can we as a fairly small project actually make a difference? hard to tell, but even if not, we get to understand a little bit more about how a fairly important technology moves forward, and that in itself is quite interesting.