 Can you hear me all right? Awesome, thank you. Yes, so I'm Flo van Schultz. I'm from Bremen, Germany. And today I would like to talk a bit about MDN browser compatibility data for the last eight years or so. I'm working on MDN. MDN is developer.mozilla.org. It's probably, what's that? Closer to the mic? All right, let's see. Like this, maybe? No? All right. Where was I? Good? All right. So MDN is a documentation site where a few tech writers in a large community tries to document the web. And that means we are writing about HTML, CSS, JavaScript, HTTP, and basically all the technologies that the browser runs. And we do this in a wiki form on developer.mozilla.org. And last year, we were, after a long time, also awarded with a prize by slash data, where they said, OK, MDN is a really great site in terms of developer satisfaction. So it means that you guys probably like the stuff that we are writing about. And we've actually did a lot of work over the last 13 years when this content was first open sourced. So this is how it actually started. Like a classic wiki in 2005, it was based on media wiki. Mitchell Baker was able in 2005 to take a few of the Netscape contents, where technical writers from Netscape wrote about the JavaScript and open source into wiki. And this was the layout in 2005, where basically all the Mozilla developers put on all the stuff that they developed about all the technologies they have invented, like JavaScript and so forth. When I joined the team in 2010, more or less, to write about web technology, MDN was actually drastically changing from being a wiki where everyone was dumping content into something where a small team of passionate web developers that were really also hyped by all the HTML5 and CSS3 technologies that came up to create a documentation hub for open web technologies. So the scope was kind of narrowed down from everyone dumps all the contents on MDN, on the developer center, to let's make a coherent website where we document web technologies. And during the last year, we have even changed a bit more the layout of the site. So for example, this is something that recently landed, and it is a bit also inspired from W3 schools. That's the site that everyone is told to don't use it, use MDN because, well, we're having more correct content. But what W3 schools does very good is delivering quick sample code quite fast and easy. And we're trying to address this with our new interactive editor that we've put on the top of the pages. And generally, there's two types of developers. There's the concept-driven ones that really like to read a lot of content and understand the concepts behind a CSS property or a method. But then there's also the ones that just want to perform an action, the action-driven developers. And they basically want to do one thing, and that is copy-paste code. And this is happening with that. But today, I want to focus on one particular project of the MDN team, which is about compatibility. And compatibility is not only important for MDN, but also for Mozilla. We want to encourage everyone to use a variety of browsers and not only write a website for one browser, which used to be the IE problem, which now probably turns into the Chrome problem. And on MDN, what we've done so far is we've provided these kind of tables. I guess a lot of you have seen those. This is a table that displays compatibility information about the CSS background property. You can also see a few sub-features of that same property, like multiple backgrounds and SVG images as a background. And we used to have this table in the Wiki for, I don't know, five, six, seven years now. And if you've ever edited MDN, which is, by the way, easy as just signing up an account and you can edit, it's a Wiki app. So everyone is able to edit and change things on MDN. And this is how it looks like, or it looks like, when editing these combat tables. This is a static HTML table where the versions and little helpers that we wrote around those versions, this is how it was stored. Now, there's a lot of problems with this. So imagine this static table being on all of the MDN reference pages that we have. And we're talking about maybe 10,000 pages. There's, I don't know, 400 CSS properties. There's an amazing amount of APIs and HTTP headers and all that. And all these pages had static information in there about compatibility. So we couldn't mass edit the data. We couldn't mass add data. We couldn't reuse the data. Like combat data is something many people are interested in, but it's kind of locked in our Wiki in those tables. And when we want to change this, we have to go into all the pages and change stuff. We can also not validate data. So as I just said, everyone can edit MDN and put a, say, Firefox 6.3 version for the CSS background property, which is nonsense, as Firefox 3.6.3 never existed. And because of the nature of the Wiki, which in the M team we are also considering rethinking at the moment, everyone can just change things without any further discussion. Which is a problem when talking about factual information like compatibility. There's not actually an opinion around this. It's just it has started to work in this version, or it has not, and it's another version. Or it's not supported at all. We can also have no automation here. Like we could probably write some scripts using source labs or browser stack automatically generating information on when something was supported. And finally, the MDN team is largely, or the MDN website is largely sponsored by Mozilla. And we have a few employees, including me, working on the site. But we want to encourage and invite the other browser vendors as well to document with us together the open web. And we've addressed a few of these points. The last one, for example, in October 2017, Mozilla, we reached out over the last year to a few other industry leaders, namely Microsoft, Google, the WFPC, and Samsung. And they now form with us together the product advisory board for MDN. What this means is that all these companies are now helping us to document the web. Because we are all doing things on the web. We are all like the Microsoft and Google, they are building browsers. The WFPC creates the standards that we are also documenting on Amnion. So finally, after a few years, we came together and formed this board. And this will help us with the whole documentation and also with the combat data. And then what we finally also came up with is we want to get out the combat data out of the wiki. We want to kind of liberate it, break it free from the static tables into a repository. So what we came up with is a repository that you can find on GitHub. It's github.com, slash mdn, slash browser, combat data. And what we did there is we stored all this data that we have in our reference pages in a structure that looks very much like this. So on the left-hand side, you can see the folder for CSS properties, so stuff like Align Self, or Animation, or Backdrop Filter. And in each of those files, you have a JSON structure where you have some interfiers saying that, hey, this is a CSS property. It's the background property. You have a back reference to the MPN URL. And then there's a support object for the various browsers and their versions. And we also provide this as an MPN package, as it is just JavaScript or JSON data. So you can reuse this in Node.js as well. And then access it like it is shown here, and you will get back the JSON that is stored in our Compat Store. And now, when editing MDN, it's a lot simpler, because we don't have to edit every page anymore. We can just mass edit in our GitHub repository. And on our pages, you can call a query like this and get the data from the data store. And thanks to this, we were able to recently redesign those tables also. We got rid of the tap switching from mobile to desktop to show all mobile and desktop browsers at the same time, because many of the web developers are having mobile first approaches. And the mobile data is as important as well. We've added Node.js to the tables, too, because JavaScript is not only in the browser anymore, but it has Node.js. And so we did this redesign, like I think it was last week only, and a lot of the pages are now showing up with these redesign tables. And the good thing is the French pages used to have the static tables as well. So in our old world, it could have been that the French version had some competent information. The English page had some competent information that was always different information all across the wiki, which was terrible. And now the French version can also just call into the data store and display a localized, competent table. So this is what MDN has done to set free this data. So yes, we are open source already. Our content is open source. But the competent information was still locked in in the static tables. Now that is set free. It's open data. And you can reuse it. So if any of you has a project or is interested in writing plugins for Atom, Sublime, VS Code, or if anyone is familiar with writing bots on GitHub, you could imagine using this data to help us for your project to check against compatibility, because the data has a lot of information on what is supported in which version of the browser. So a museum called Eduardo Busas, he did something useful with this data. And you can use this maybe for inspiration. This is DevTools, Firefox DevTools. And he has written an extension adding a new tab called compatibility. And what it does is it analyzes the CSS files of your website and gives you information on what kind of properties you have used. And it will display you a similar compact matrix inside DevTools saying, OK, you've used this on that property. And it doesn't work in IE9. So you will not be compatible on a percent there with IE9, for example. So let's have a little bit of a look now that you fully feel a bit inspired of what you could do with this data set, what's in the data, right? So for now, we're still not completely finished the migration from this static table thing into the data store. We're about 45% done. But right now, what we have is a mixture of this. So there's CSS, HTML, HTTP, JavaScript, and web extensions, competent data in there. And this already gives you a bit of a sense of how large these technologies are. So web extensions has a lot of APIs. So there are a lot of data points here. Same for CSS, all the properties, the selectors, add rules, and so forth. HTTP is a bit smaller because we mostly have combat data for HTTP headers in here. Now, I've looked a little bit deeper into the data for CSS. And if you're into, I don't know, data science-y things, you could also analyze this data set and look at how CSS developed over time. So for example, when we had Firefox 1 10 years ago, there were like 90 CSS properties. And because this data has all the, this combat data still has all the Firefox versions. And I've looked into it when there was little spikes. So in Firefox 16, for example, there were a lot of new CSS properties. And I was like, what's going on there? So it turns out they implemented CSS animations back then, or later, Flexbox. So over the last like 50 or 65 Fox versions, CSS got more complex and complex, adding more features over time. So I could make this chart only out of our data, which was kind of interesting, I thought at least. One thing I need to mention, though, is that the data is, as we've just started to migrate them, we have not yet polished them or validated a lot what's in there. So the chart that you've just seen about the CSS data, I was using the Firefox versions because our data is actually most complete for Firefox because on the Wiki, well, we used to maintain the data for Firefox mostly and not so much for other browsers. So what you can see here is a lot of the data is, either the version is unknown or the compatibility is unknown at all. So, but as it is open data, I can only have a call to action here. You can help us making this data more awesome, which will make the tables displayed on MDN more awesome, which will make the tool that Eduardo brought in DevTools more awesome, which will make the tool that some of you may come up with more awesome. So, yeah, that is that. And with that, that was browser combat data, open data brought to you by the MDN team. Thank you. Any questions? Yes? Yes, I know that. Yes, so we look into, can I use, can I use has about 300 features listed on the page and that's awesome, it's a wonderful site. Our data set is a lot bigger and we're not even done yet. So, yes, we're working together with can I use and there might be some collaboration in the future, but right now the data that we want to set free from the Wiki is just a lot more richer, about 10 to 20 times more richer and we want to preserve that information. And so as a first step, we are putting that into a repository but, yeah, future collaboration. Awesome, let's do it. So, the thing that's, the things that, oh, yeah, sorry. So the question is about the collaboration between can I use and this data set and competing or double effort. And the thing is, this data set is a lot more richer because we have all the information from over 6,000 MDN Wiki pages and can I use has only about 300 pages listed at the moment. And both projects are kind of relying on us on manual pull requests, updating the data. What we want to bring in here is we want to kind of have official status using our partners from the MDN product advisory board, putting in official version numbers when something is supported and also adding on top of the data some validation and automation that actually tells us the truth whether or not something is supported. But, yeah, I'm open to collaboration with can I use as well and, yeah, sure. More questions, no? All right, Dan, thank you.