The Web Compatibility Summit was organized in Mountain View (USA) on February 18, 2015. I summarize the talks that we have been given during the day. I encourage to continue the discussion on compatibility@lists.mozilla.org.
If you want to look at the talks:
Intro to Web Compatibility
Mike Taylor (Mozilla) has introduced the Web Compatibility topic. The Web being a giant set of new and old things. We need to care for a lot of different things sometimes incompatible. Features will disappear, new features emerge, but you still need to make the Web usable for all users whatever their devices, countries, browsers.
Mike reminded us of the evolution of User Agent strings and how they grew with more and more terms. The reason is that the User Agent string became an ID for having the content rendered. So any new User Agent is trying to get access to the Web site content by not being filtered out.
Then he went through some traditional bugs (horrors) be JavaScript, CSS, etc.
WebCompat.com has been created to give a space for users to report Web Compatibility issues they have on a Web site. But the space is useful for browser vendors, it is relatively easy to tie the bug reporting of browsers directly to webcompat.com.
Discussions
Beyond Vendor Prefixes
Jacob Rossi (Microsoft) introducing the purpose and the caveats of vendor prefixes. Vendor prefixes have been created for helping people to test the new API safely without breaking other browser vendors. It shields against collision with other implementations, but it also creates Web Compatibility issues. The main issue being that Web developers use these on production sites and on articles, examples, documentations.
Microsoft tried to contact Web sites with bogus code examples and articles. They also created new content with the correct way of writing things. The results were promising for the FullScreen API but the experiment was less successful for other properties. Basically, fix the problem before it happens.
So how do we keep the possibility to have a large surface for feedback and at the same time limit the usage so that it doesn't become a requirement to use a specific browser. The first idea to put new features behind flags. Then the issue becomes that the feedback is shallow. So Jacob is floating the idea of an API trial, where someone would register to get a key for enabling a feature. It would help the developer to test and at the same time, make it possible to set deadlines for the test.
It would probably require a community effort to set up. It has a cost. Where this discussion should happen? It could be a community group at W3C. Not all APIs need to be used at scale for having a real sense of feedback. IndexedDB, appcache would have been good candidates for this thing. If there was a community site, it would be yet another good way to build awareness about the features.
A good discussion has been recorded on the video.
How CSS is being used in the wild
Alex McPherson (QuickLeft) introduced the wonderful work he did about CSS properties on the Web as they are currently (2014) used by Web devs. The report was initially done for understanding what QuickLeft should recommend in terms of technology when they tackle a new project. For this report, they scrap the CSS of the top 15000 Web sites and checking the frequency, values, doing graph distributions. The purpose was not to be an exact academic research. So they are definitely caveats in the study, but it gives a rough overview of what is done. The data were collected through a series of HTTP requests. One of the consequences is that we probably miss everything which is set through JavaScript. A better study would include a browser crawler handling the DOM. There are probably variations with regards to the user agent too.
It would be good to have a temporal view of these data and repeat the study continuously. So we can identify how the Web is evolving. Browser vendors seems to have more resources to do this type of studies than a single person in an agency.
Engaging with Web Developers for Site Outreach
Colleen Williams (Microsoft) talked about what it takes to do daily Web Compatibility work. Contacting Web developers is really about trying to convince people that there could be a benefit for them to implement with a wider scope of platforms.
Social networking and using linkedin are very useful to be to contact the right persons in companies. It's very important to be very upfront and to tell developers:
- Who we are?
- What we are doing?
- Why are we contacting them?
Microsoft IE team has a list of top sites and systematically test every new version of IE into these sites. It's an opportunity for contacting Web sites which are broken. When contacting Web sites, it's important to understand that you are building a relationship on a longterm. You might have to recontact the people working for this company and/or Web sites in a couple of months. It's important to nurture a respectful and interesting relation with the Web developers. You can't say "your code sucks". It's important to talk to technical people directly.
Do not share your contact list with business departements. We need a level of privacy with the persons we are contacting. They keep contact with you because they are eager to help of solving technical issues. Empathy in the relationship goes a long way in terms of creating a mutual trust. The relationship should always go both ways.
Having a part or the full solution for solving the issue will help you a lot in getting the issue fixed. It's better to show code and help the developer demonstrate what could work.
Companies user support channels are usually not the best tool, unfortunately, for reaching the company. There's a difference in between having a contact and having the right contact.
Web Compatibility Data: A Shared Resource
Finally Justin Crawford (Mozilla) introduced the project about having a better set of site compatibility data. But I encouraged you to read his own summary on his blog.
Unconference
We discuss at the end of the day using an unconference format. Alexa Roman moderated the session. We discussed about User Agent Sniffing and the format of the UA string, console.log for reporting Web Compatibility issues, API trials, documentation, etc.
More information
You can contact and interact with us: * IRC: irc.mozilla.org #webcompat * Discuss issues on compatibility@lists.mozilla.org * Twitter: @webcompat * Report bug: http://webcompat.com/