WEBVTT 00:00.000 --> 00:13.000 All right, my name is Patrick, I work as a PM on the Edge web browser at Microsoft, before 00:13.000 --> 00:17.720 that I used to work at Mozilla for a few years, and I'm here today to talk to you about 00:17.720 --> 00:21.720 improving the web developer experience one feature at a time. 00:21.720 --> 00:26.720 So it's not just about the code, obviously, these conferences prove that open source code 00:26.720 --> 00:32.320 is a thriving ecosystem that a lot to talk about, as if you work on the web, if you build 00:32.320 --> 00:36.720 stuff for the web, you probably use open source software all the time, the browsers that 00:36.720 --> 00:42.480 you use to build your stuff, even ease open source itself, most of the time as well. 00:42.480 --> 00:46.640 But that's not what I'm here to talk to you about, as a developer for the web platform, 00:46.640 --> 00:49.920 you'll probably use documentation and data all the time. 00:49.920 --> 00:56.200 Sometimes not even realizing it, and what I want to talk to you about today is data. 00:56.200 --> 01:00.840 So if you think about a typical day as a web developer building your website, a web app, where 01:00.840 --> 01:08.560 any product that uses HTML, CSS, and JavaScript, obviously, you write code, well, normally 01:08.560 --> 01:12.880 now, with AI, maybe less so, but you write the code, and to even know what to write, you 01:12.880 --> 01:17.840 probably read documentation, you probably consume data without knowing that you do, and 01:17.840 --> 01:22.200 then to actually build that code, you probably use tools to debug that code as well, you 01:22.200 --> 01:26.760 probably use tools as well, and those, all of those things, they consume massive amounts 01:26.760 --> 01:32.560 of data that need to be to date, high quality, and all of that good stuff. 01:32.560 --> 01:36.480 You are likely familiar with this, this is the MDN website, this is a compatibility table 01:36.480 --> 01:41.040 at the bottom of the MDN website that tells you all about this particular feature and whether 01:41.040 --> 01:44.720 it's supported in which browsers, et cetera. 01:44.720 --> 01:49.000 This also probably rings a bell if you've done any web development, this is can I use.com, 01:49.000 --> 01:54.000 it tells you all about the compatibility of various features on the web, depending on 01:54.000 --> 01:55.960 websites and stuff. 01:55.960 --> 02:00.800 Other examples include little tools inside of DevTools, if you open up F12, you know, a 02:00.800 --> 02:06.160 control shift I, whatever you do to open DevTools on the website, you will see probably 02:06.160 --> 02:11.240 these tools, if you're playing around, that tells you some documentation and some information 02:11.240 --> 02:16.640 about the features that you're using, same in your IDE or text editor or whatever you're 02:16.640 --> 02:22.760 having to be using, there's a lot of this information that you use that you rely on every 02:22.760 --> 02:30.440 day, and these are, you know, obvious ways in which open-source data helps you do your job 02:30.440 --> 02:36.080 and without which it would actually be super hard. 02:36.080 --> 02:41.280 Other less-obuse examples can include in the top left corner here, there's a deprecated banner 02:41.280 --> 02:45.840 at the top of an MDN website, web page as well, it tells you that hey, that feature that 02:45.880 --> 02:49.920 you're using or thinking about using is actually deprecated, so you might want to rethink 02:49.920 --> 02:50.920 that. 02:50.920 --> 02:55.920 In the top right corner is, can I use.com, and here it's a little bit different, a feature 02:55.920 --> 03:00.600 is not supported on a browser, but if you, you know, if you turn on a specific flag in the 03:00.600 --> 03:04.360 browser, then you might be able to use it to early test it. 03:04.360 --> 03:09.200 Bottom left corner is an example of an ESLINCE plugin, which is a Linting tool for your code 03:09.200 --> 03:14.280 that actually checks for compatibility of the features you use, and in the bottom right 03:14.280 --> 03:20.000 it is one more example of MDN, and this time it's a link to a bug, so now you know that 03:20.000 --> 03:23.720 that feature is not supported, but you know why, because there's a bug in a particular 03:23.720 --> 03:28.200 browser and you might want to click on it to learn more if you want to. 03:28.200 --> 03:33.200 So now imagine, you know, documentation without deprecated warning, imagine documentation 03:33.200 --> 03:35.240 without this compatibility data. 03:35.240 --> 03:41.080 Imagine your Linters not being able to tell you exactly that your code does not, is not 03:41.080 --> 03:47.480 going to work on your target browsers, you know, your lives as a web developer will be 03:47.480 --> 03:50.400 a lot harder to do, right? 03:50.400 --> 03:57.440 So all of these to say that my point is that up to date high quality data is critical 03:57.440 --> 04:03.080 infrastructure for our entire industry, you know, as browser makers, as web developers 04:03.080 --> 04:08.400 where we lie, sometimes indirectly on this data, but it is really playing a crucial role 04:08.400 --> 04:11.240 in our daily lives. 04:11.240 --> 04:15.040 So I want to talk to you about a few different data sources, one of which is browser 04:15.040 --> 04:19.920 compatibility, it's called BCD for short, it is the data that powers all of the compatibility 04:19.920 --> 04:26.200 tables on MDN, as well as a lot of the pages on can I use.com, it's using VS code, it's 04:26.200 --> 04:32.600 using many other ideas, I believe in ESLint, in Babel, in Bun, if you look at the list 04:32.600 --> 04:37.440 of projects that use BCD, it's quite impressive. 04:37.480 --> 04:42.400 So BCD is a project that's open source, it's on GitHub.com if you want to check it out, it 04:42.400 --> 04:48.240 has like a million downloads per week on NPM, if you want to talk about the package itself, 04:48.240 --> 04:52.240 there's more than a thousand contributors, they've together written more than 20,000 pool 04:52.240 --> 04:56.840 requests to keep the data up to date, it's suffice to say that it's a very, very active 04:56.840 --> 04:59.080 project and it needs to be, right? 04:59.080 --> 05:03.800 Like it needs to always be a today because it describes the state of the web platform, 05:03.800 --> 05:08.280 it describes everything that there is to use for the web, so it needs to be always up 05:08.280 --> 05:09.280 to date. 05:09.280 --> 05:13.520 The way that it does this is by using the concept of keys, so there are 20,000 keys 05:13.520 --> 05:20.520 in BCD, a key could be like a CSS property value, it could be a JavaScript method, argument 05:20.520 --> 05:24.520 or option or something like that, it could be an attribute to an HTML, and like everything 05:24.520 --> 05:31.800 every little detail of the web is in BCD in some shape of form, always up to date, always 05:31.800 --> 05:40.040 updated by actual people, and tools as well, semi-automatically updated because every time 05:40.040 --> 05:45.520 there's a beta, release of a browser, there's a tool that's used to update some of the 05:45.520 --> 05:51.600 data in an automated way, so it's not all humans, we are trying to use tools as well 05:51.600 --> 05:58.240 to help with that, so very active project, the way that it's able to be active and to continue 05:58.240 --> 06:03.040 being active, apart from the many, many contributors, which is awesome to see, and a few 06:03.040 --> 06:07.880 individual people at browser-maker companies because they know best what features are available 06:07.880 --> 06:14.040 and where, the two main ones would be one, the MDN team at Mozilla, who spends a lot of 06:14.040 --> 06:18.760 time in supporting and maintaining the data and the infrastructure and stuff, but also 06:18.760 --> 06:23.720 open web docs, if you don't know about open web docs, I have a segment about that coming 06:23.720 --> 06:31.680 later, it's a vendor-neutral nonprofit initiative that is really here to guarantee the 06:31.680 --> 06:36.400 long-term health of the web platform documentation and data and they play a huge role when 06:36.400 --> 06:45.040 it comes to the BCD data. If you want to use BCD in your projects and you happen to use 06:45.040 --> 06:50.680 NPM, really simple, you can pull in that dependency through the NPM package manager, I believe 06:50.680 --> 06:55.440 you can also download it as JSON if you want, if you prefer to do that too, and then 06:55.440 --> 07:01.840 you import it in your projects and just use it there, so quite simple. But now, I mean, 07:01.840 --> 07:06.440 you're probably familiar with this, BCD is an open source project, like any open source 07:06.440 --> 07:12.640 project, or any project of that matter, if there's work to be done, somebody has to do 07:12.640 --> 07:17.640 that work and that person needs to be paid for it, and even though it's so simple, it 07:17.640 --> 07:22.120 remains one of the biggest challenges with open source funding. There's a whole track 07:22.120 --> 07:27.240 of these very conference about that, so it's really not that simple, it's something 07:27.240 --> 07:31.240 that people who maintain those projects have in mind constantly and sometimes have to do 07:31.240 --> 07:35.720 a lot of work for at the expense of actually doing the work to maintain the data or the 07:35.720 --> 07:43.200 coding instead. So, really big shout out to all of the sponsors and the maintainers of BCD 07:43.200 --> 07:48.840 and other CMD projects. For BCD, I mentioned already, a large part is Mozilla, another big 07:48.840 --> 07:56.240 part is the open web docs, who have been very active over the past five years or so. 07:56.240 --> 08:05.760 Open web docs is actually funded, is funded by web companies who have a lot of investment 08:05.760 --> 08:11.440 on the web edge, where I work, we do, we fund open web docs and have been for the past five 08:11.520 --> 08:17.840 years, Google has been a funder for a long time as well, more recently Bloomberg, EGALIA has 08:17.840 --> 08:22.800 been a funder as well, some of you are in the room and that's been awesome, Kenva, sovereign 08:22.800 --> 08:28.160 take agency and others that have been coming and going over the years, and plenty, like 08:28.160 --> 08:35.200 a lot and lots of people who have donated personal money to keeping open web docs alive, 08:35.200 --> 08:40.960 which in turn helps support MDN, BCD, and all of the ecosystem that relies on it. 08:40.960 --> 08:44.960 So if you want to be part of the family, you can scan the QR code on the left, give some 08:44.960 --> 08:49.760 money, but even better, if you work at a company that has some business on the web and 08:49.760 --> 08:54.320 that's pretty much all companies at this point, scan the QR code on the right to try and 08:54.320 --> 08:59.600 convince your boss to be a sponsor to open web docs, that's going to be making a world of 08:59.600 --> 09:04.080 a difference for all of these tools and all of these data that we all consume every day. 09:04.320 --> 09:13.040 So me, I work at a browser vendor company, and we rely not only on BCD, but on a plenty of 09:13.040 --> 09:17.920 other data sources that are here that describe the way in some shape of form. 09:18.720 --> 09:23.680 Top left is state of CSS, state of HTML, state of JavaScript, you might have taken those surveys 09:23.680 --> 09:29.280 they run every year, and they constitute for us, browser makers, a really big might of information 09:29.280 --> 09:34.480 that's super fantastic for us to prioritize some of our work. We can learn from these data 09:34.480 --> 09:41.680 tools, and we can apply it to our own prioritization processes in the bottom left is WPT web platform 09:41.680 --> 09:48.400 tested. It describes the quality of the implementation of all browsers of the web platform, right? 09:48.400 --> 09:54.400 It's a giant test suite that runs in every browser all of the time, and we can see it can 09:54.400 --> 10:00.480 keep us honest on what it is that browser actually implement and to what level. So we use this 10:00.480 --> 10:05.440 as well to know the state of things. In the bottom right is browser specs, which is a repository 10:05.440 --> 10:10.560 that tells us the state of specifications of the web, in what state everything is. 10:12.640 --> 10:16.960 Browser standards position is another source of information that we use to know 10:17.760 --> 10:23.040 what Mozilla or WebKit think about a particular Web feature or do they agree with it? Do they have 10:23.040 --> 10:27.280 concerns with it, et cetera? In the top right corner is a new experiment we're making, which is 10:28.080 --> 10:32.080 if you go to can I use, you might see a little thumbs up with a number next to it now. It's 10:32.080 --> 10:39.920 fairly new. It is a way for us to capture interest in features from the wider community of web users 10:39.920 --> 10:45.440 and sorry web developers, and people can also leave use cases and stuff over there as comments. 10:45.440 --> 10:51.520 So all of these data tools is super helpful, and they help everybody who build for the web. 10:51.680 --> 10:56.720 Sometimes indirectly, sometimes without realizing it, but it does help everybody, and it'd be great 10:56.720 --> 11:03.040 if we could put all of that together in a consistent way that's easy to discover and navigate. 11:03.840 --> 11:08.240 So one more data source I want to talk to you about today is called web features. You might not have 11:08.240 --> 11:14.800 heard of web features. I don't think the word the term is very well known, but baseline is way more 11:14.800 --> 11:19.600 popular. If you've you know followed a little bit of the news around the web for the past two years, 11:19.680 --> 11:24.800 you might have come across baseline. You might be even more familiar with these these 11:25.360 --> 11:31.440 banners at the top of MDN pages. You might have seen them. If a feature is widely available across 11:31.440 --> 11:36.080 old browsers, you will have these green checkmark and a baseline that says, hey, this is, 11:36.080 --> 11:41.760 you know, you can use it. It's sort of safe. It's widely available across the browsers that 11:41.760 --> 11:47.280 baseline considers. Or it could be blue, which means yes, it is available everywhere, but it's recent. 11:47.280 --> 11:51.760 You might, you know, think about using it. Maybe you're not all of your users have that 11:51.760 --> 11:57.280 feature in their browsers. And then the other status at the top is it's limited availability. It's not yet there. 11:58.880 --> 12:03.760 So that's baseline. But baseline is really based on web features and web features is the project 12:03.760 --> 12:09.200 that's open source that I want to talk to you about. And it looks something like this. It's a catalog 12:09.200 --> 12:16.640 of files. It's it's a flat list of files, thousands of them that describe the entire web platform. 12:16.640 --> 12:23.520 So if as a web developer, you've used the fetch API to get some JSON files from the server, 12:23.520 --> 12:29.600 then there's a feature in the catalog that's called fetch. Same with anchor positioning, same with 12:29.600 --> 12:36.800 everything, right? So that's the, that's the main point of the project is to describe the entire 12:36.800 --> 12:44.080 web platform everything. Now you might be thinking BCD, which I talked about before already does that, 12:44.080 --> 12:49.680 right? I mentioned that BCD had the concept of keys, which describe everything. It does, but it's 12:49.680 --> 12:55.680 two granular, two fine-grained. So what we needed was something that developers would understand. 12:55.680 --> 13:00.320 There's a fetch feature here. It is a greed feature for CCS greed. There's a Flexbox feature. 13:00.320 --> 13:06.320 Everything described in a very simple manner with a name, a unique ID, a short description. 13:06.320 --> 13:12.960 And that's basically all it is. And so the value of the project here is not in the data that it contains, 13:12.960 --> 13:18.720 because it contains very little data, but it's more in the fact that we now have a unique ID for 13:18.720 --> 13:24.960 each and every thing that people can use on the web. So we can use this as a reference data set. 13:24.960 --> 13:31.200 To then put everything together in a map, in a graph that's interconnected with this unique ID. 13:32.400 --> 13:38.160 And that's what we do now with web features. That's what's happening behind the scenes. You might not 13:38.640 --> 13:45.120 see it, but it is happening. And it's making certain tools, certain dashboards, 13:45.120 --> 13:49.920 possible that were not possible before. So web features, let's say you have a fetch feature called 13:49.920 --> 13:55.680 fetch, is in the center. It has this unique ID. And based on this unique ID, we can now map to all sorts 13:55.680 --> 14:02.240 of other information about the web. So can I use is an obvious example? MD and Docs is the other 14:02.320 --> 14:08.880 example. We can link those things. We can link to web platform test, easily we can link to the 14:08.880 --> 14:14.320 spec. We can link to bug trackers. We know that if there's a fetch feature, we can probably link 14:14.320 --> 14:19.760 you to all of the relevant bugs in the various bug trackers that relate to this feature. 14:19.760 --> 14:26.880 Giving you more information about the state of this feature, more ways for you to keep track of 14:26.960 --> 14:36.880 what's happening, what's new, and what's problematic. This project is being driven by the W3C 14:36.880 --> 14:42.240 WebDX community group. So it's the standard group that I'm part of with a bunch of people, some 14:42.240 --> 14:50.000 of which are here, and which you're very free to join if you want to. So the project itself is 14:50.000 --> 14:57.280 a on GitHub, open source project. You can contribute to it's very simple to do so in a way because 14:57.280 --> 15:02.560 it's just in least the features is really not that much in terms of architecture or complexity of 15:02.560 --> 15:10.800 the code. It's a bunch of YAML files. It's available as a JSON format if you want downloaded and use it 15:10.800 --> 15:17.760 in your projects or via NPM as well, which is what many people want to use nowadays, and to use it 15:17.840 --> 15:22.320 NPM install web features, and then you can use it in your project. So it's fairly simple to 15:22.320 --> 15:29.360 integrate into your, if you want to build a dashboard for the web or anything, if you are building 15:29.360 --> 15:35.600 your tool, where you want to list features and stuff like that. One of the things we do on the 15:35.600 --> 15:41.600 WebDX community group is also build a visualization of this data because the YAML is not that easy, 15:41.680 --> 15:47.280 not that succeeded look at. So we are building this website. It's called the web features explorer. 15:49.360 --> 15:53.680 I realize I don't have a link to it here, but I can give it on my matrix later if you want. 15:53.680 --> 15:58.880 It lists all of the features we have. So the thousands of features we have are available here. 15:58.880 --> 16:03.680 You can see one of them here with, I don't know if we can see my cursor and probably not. 16:03.680 --> 16:10.880 You can see the unique idea in the top right, then the title of feature, the description, and then 16:11.360 --> 16:16.240 as an illustration of what I said before of this interconnection of data that's useful for web 16:16.240 --> 16:21.600 developers, you can see a bunch of stuff here. You can see a link to MDN. So now, for this 16:21.600 --> 16:26.240 particular feature, which is called invoker commands, you can see, hey, here's the link to MDN. 16:27.200 --> 16:32.960 You can see a link to the spec as well if you're into reading specs. You can see a link to a 16:32.960 --> 16:38.080 bunch of questions that came out on state of CSS or state of HTML in that case, I think, 16:38.160 --> 16:42.480 so that particular feature, so that you can find out what people thought about this feature 16:42.480 --> 16:49.360 and responded to two survey questions. And in the bottom right, you can see a link to the developer 16:49.360 --> 16:54.720 signals repo that I mentioned earlier where people have voted for this feature and left comments 16:54.720 --> 17:00.880 about it. And here is another example for another feature called scroll driven animations. You might 17:00.880 --> 17:06.400 have used it. It's the really cool animation CSS feature where you scroll and then you can trigger 17:06.480 --> 17:12.560 some stuff moving on the screen. This one shows, again, the description of the feature, 17:12.560 --> 17:18.160 link to MDN, et cetera, but also links to browser bugs. You can see in the red in the center 17:18.160 --> 17:23.840 that Mozilla Firefox does not yet have support for the feature, but you can see a link to a bug. 17:23.840 --> 17:27.440 And maybe you're interested in clicking on that and being like, hey, that's why, you know, 17:27.440 --> 17:32.720 they're working on it or maybe there's a technical problem. Whatever, you can track more. You can 17:32.800 --> 17:38.320 have a look into it and you can even have a say into it if you want to be part of the whole thing. 17:39.440 --> 17:45.120 And you can also see next to Firefox a little green rectangle that says vendor position. It 17:45.120 --> 17:50.080 might be a little bit small, but what it tells you is that Mozilla actually agrees with the 17:50.080 --> 17:54.880 feature. They really like it. They want to implement it. It's just that they have not done it yet. 17:54.880 --> 18:01.200 So, again, as a web developer, it gives you a ton of information to follow along with the web 18:01.200 --> 18:07.760 platform and understand more of what's happening behind the scenes. Web features is used by 18:07.760 --> 18:12.960 more and more people or more and more projects, as I say. The two obvious ones are MDN and kind of 18:12.960 --> 18:17.360 use, which I mentioned before, because they show this big banner that says baseline or not. 18:18.800 --> 18:25.200 But VSCO uses it, jet brains, IDs as well. There's a number of examples here. One of which is 18:25.200 --> 18:31.520 browsers list. If you do anything, if you have a build step in your web project that has a 18:31.520 --> 18:36.080 definition of target browser, you're probably using browsers list already. And now browsers 18:36.080 --> 18:42.960 list use it web features as well. You can use the data as well. On the left here, it's just an 18:42.960 --> 18:48.960 example that I made. It is quite small, but it's basically a, I played around with the idea of 18:48.960 --> 18:56.320 having a way to discover features. Like the web platform contains thousands of features 18:56.320 --> 19:02.640 who knows them all. So, I created a catalog of them that's organized hierarchically by tasks. 19:02.640 --> 19:06.640 If you want to do networking and security, you can click on those tasks and then discover 19:07.520 --> 19:11.440 these features and then maybe use them in your projects. So, it's just an example of things 19:11.440 --> 19:17.040 you can do with the data source. And on the right, it's just an example of somebody on the social 19:17.120 --> 19:22.640 media who shared that they were building a baseline countdown. So, something that tells you how long 19:22.640 --> 19:27.280 you would have to wait for this feature to become widely available for all of your users. 19:27.280 --> 19:33.120 So, there's lots of little things you can deal with it that are, I think, super useful to developers. 19:33.120 --> 19:40.000 So, why is this useful again? Well, we know for a fact by doing surveys after surveys that 19:40.000 --> 19:46.560 developers have, you know, the field frustration and pain points based on the fact that 19:46.560 --> 19:51.760 keeping track of changes is really hard and knowing what's okay to use is really hard. So, 19:51.760 --> 19:57.120 knowing what's okay to use, baseline can help you with that. Keeping track of changes, 19:58.000 --> 20:02.800 these dashboards that I mentioned before, the feature explorer website can help with that. 20:02.800 --> 20:07.280 If you build your stuff as well, it can help with that. We could also explore building 20:07.280 --> 20:14.720 release notes for the entire web. Release notes are usually stuff that each browser publishes every 20:14.720 --> 20:21.120 months or so and say, hey, here is what's available in Safari or Edge or whatever. We can, 20:21.120 --> 20:25.840 with data like that, we can build release notes for the entire web. And that is, I think, 20:25.840 --> 20:34.080 a much more useful thing for developers to do. The project does not cover everything yet, 20:34.240 --> 20:40.880 accessibility, assistive technology, support is not included yet. This is definitely something that's 20:40.880 --> 20:45.920 top of our mind and we want to work on it and we're actually working with Lola, who's giving a 20:45.920 --> 20:53.760 talk here later today on accessibility. So, this is something we have in mind. We don't yet have the 20:53.760 --> 20:58.880 data to support it, but we're hoping to have it at some point in a near future. Stuff like progressive 20:58.960 --> 21:04.320 enhancement and polyfills is not supported either. And what I want to leave you with here is 21:04.320 --> 21:09.600 baseline, which I've talked about, is not never take baseline as yes or no, right? If something 21:09.600 --> 21:14.560 if a feature is not baseline, it doesn't mean you can't use it. It means that maybe you pause and 21:14.560 --> 21:20.240 you think about your users and what it is that you want to do with your, with the feature. 21:20.960 --> 21:28.800 It is, baseline is a yes, for sure, or yes, maybe kind of indicator. But that's something that we 21:28.800 --> 21:33.280 are improved as well. Partial support, form factor, specific feature, has well is something that's 21:33.280 --> 21:38.560 not clearly supported. But again, web features is an ongoing project. And like any ongoing project 21:38.560 --> 21:43.440 is always more to do, more to improve. And that's, we're in the process of doing that. So, 21:44.400 --> 21:49.520 these are tools. This is data to help you. It's continued to be responsible web developers, 21:49.520 --> 21:54.720 baseline, and the web features projects, they don't help you do and solve everything. But it is 21:54.720 --> 21:59.120 something that you can start using to gain more understanding of the web platform. 22:00.160 --> 22:07.680 Make quicker decisions as to what to use, what not to use. And yeah, just a final point, data 22:08.400 --> 22:13.360 and documentation, by the way, this is critical for the web. We must have it up to date. 22:13.360 --> 22:19.280 We must fund together as an entire industry. These two continue being up to date and high quality. 22:20.000 --> 22:25.680 We have fun with web features. If you want to play with it. And otherwise, join the web 22:25.680 --> 22:30.240 DX community group. We're super welcoming bunch of people. And we just want to push the web 22:31.200 --> 22:33.920 forward. So, that's, that's me. Thank you. 22:44.160 --> 22:45.520 We have time for questions. 22:46.400 --> 22:48.400 Yes. 22:57.280 --> 23:05.280 You mentioned something like process, run tests all the time. Is that something that is always necessary? 23:05.280 --> 23:08.720 Or is it something that can be disabled as well from time to time? 23:09.440 --> 23:15.920 So, these tests that I mentioned, they were, they've run on a testing, continuous testing infrastructure, 23:15.920 --> 23:20.800 not within the browser. I don't know whether that's what you had in mind. But these tests are always 23:20.800 --> 23:27.600 run continuously on a platform, just to make sure that whenever a new version of the browser comes in, 23:28.400 --> 23:32.160 we know that these tests are doing the development of the browser itself, you mean? Yeah, 23:32.160 --> 23:36.480 yes, thanks. That's our question. 23:46.560 --> 23:52.960 So, did you say that if I put target browsers in the IDE, I'll get warnings. If I use a feature that's 23:52.960 --> 23:56.400 not supported by one of them, just because browser-specific bugs are very frustrating. 23:57.360 --> 24:01.600 Sorry, could you repeat a little bit louder? Because the sound is not super loud here. 24:01.600 --> 24:08.160 Did you mention there that if I put target browsers in my IDE, I should get warnings. 24:08.160 --> 24:11.360 If I've hit something, that would be a browser-specific bug for them. 24:12.000 --> 24:19.360 Yeah, so not necessarily a browser-specific bug to speak off. But the baseline information or 24:19.360 --> 24:25.840 web features information can be used in VS code and IntelliG has support for it. 24:25.840 --> 24:30.720 And it's going to tell you, if a feature, I think, especially in CSS right now, 24:30.720 --> 24:34.960 I don't know about the other languages, but in CSS, it is able to detect the things you're using 24:34.960 --> 24:40.000 and telling you whether what you're using is baseline or not. Okay, so more on the gist than, 24:40.000 --> 24:41.840 which, but it's okay, noise. 24:49.360 --> 25:02.160 One more question. Okay, thank you for coming. Thank you. Thank you for taking us here.