[ad_1]
In this episode of the Smashing Podcast, we’re talking about Web Platform Baseline. What is it, and how can it help determine your browser support policy? Drew McLellan talks to expert Rachel Andrew to find out.
Contents
Show Notes
Weekly Update
Transcript
Drew: She’s a web developer and technical writer and editor. She’s currently working for Google on the Chrome team where she’s a staff technical writer and content lead for web.dev and developer.chrome.com. Prior to Google, she spent 20 years as a freelancer and business owner and she’s written almost countless books and articles where she excels at taking complex technical subjects and making them more readily understandable. She’s also an experienced conference speaker, able to deliver a technical talk to teach an audience about CSS layouts or a keynote to inspire them drawing from her wealth of experience developing for the web. So we know she’s an experienced technical writer, teacher and developer, but did you know she once taught a Canada goose to make a bourbon cocktail? My smashing friends, please welcome back Rachel Andrew. Hi Rachel, how are you?
Rachel: I’m smashing.
Drew: Welcome back to the podcast. It’s been a couple of years and theres been a change of day-to-day role for you.
Rachel: Yes, yes. I guess last time I was here it was mid pandemic and I was still editor-in-chief of Smashing Magazine and yes, these days I’m over at Google on the DevRel team with my content team sort of helping to get good docs and information out to our developers about things on the web platform.
Drew: So still in the realms of helping people learn about the web platform and assisting their busy lives, trying to keep a pace of all the new technologies and developments?
Rachel: Yes. Yeah, it’s kind of a perfect role for someone who spent most of their life sort of explaining things to web developers. So yeah, it’s great and within a really great team of people who were very dedicated to talking about all this new stuff.
Drew: So speaking of new developments and also Google, last week was Google I/O 2023, which is always an exciting time for us tech nerds because there are all sorts of announcements and updates from Google. With Google being such a large contributor to the web platform, it then becomes an exciting time to see whats been worked on for the web in particular and see what might be coming out next. I feel like we’re in a place with a web platform where it’s continuing to develop a fantastic pace at the moment.
Rachel: Yeah.
Drew: Those of us who have been working in the industry for a while remember the years when nothing was added in terms of browser capabilities, I mean sometimes years at a time. You were working on the web back then. Was it frustrating that things weren’t getting added or did it just make it easier to keep up?
Rachel: I think it was frustrating. You know, when we had, we had five years between IE6 and IE7 so that was kind of five years that the web platform just basically stopped because so many people were using IE6, although there were new other browsers around you couldn’t really use all the new stuff that they were putting into the browser because the majority of people coming to your website were in a browser that didn’t support it. So I think it was very frustrating because that’s a very, very long time, especially when IE6 had all sorts of bugs and issues as well so that we weren’t getting fixes to things.
Rachel: It wasn’t even new features. We were dealing with problems, like bits of your content disappearing for no apparent reason. So yeah, it was frustrating, but it was very stable. Buggy but at least the bugs that we could list them, there were websites that listed all of the IE6 CSS problems, so you’d hit one and you’d be like, oh yeah, that’s that. I know how to fix that. So we all became pretty expert in dealing with browser bugs basically and knowing what they were.
Drew: I remember things like Peekaboo, was it Peekaboo bug was that era.
Rachel: Yes.
Drew: And what was the website that listed them, listed them all? I can’t remember it’s name now, but the list of known bugs just got longer and longer and longer over time to the point where it became difficult to find the one you were, the particular bug you were experiencing because the list was so long. We were in a place back then where the dominant browser, which was Internet Explorer at the time, was the browser that was seeing the least technical innovation but that doesn’t mean there was no technical innovation because there was a broader ecosystem, but was it ever possible to use new bits of CSS that were appearing in things like Firefox? Is that something we could do when the dominant browser was so far behind?
Rachel: It was pretty hard. I mean, I think all the ideas of things like polyfills and also there was a lot of us kind of pushing the progressive enhancement story as well and saying, look, it’s fine, your website doesn’t need to look the same in all browsers. I think I’ve been saying that for most of my life at this point. And that was a big thing at the time because people were just sort of A/B test in the browsers, you know, there was no… you’re sensing off to your client and they would just open it in another browser and be like, “Oh no, this is wrong ‘cause it’s three pixels out on this other browser.”
Rachel: And that was very, very common. People would talk about pixel perfect and what they would typically mean is it should be exactly the same as the PDF or whatever that you were working from or the Photoshop file and all of the browsers that they were aware of, or at least both browsers typically. So I think it was quite difficult to push the web forward at the time, you got quite a lot of resistance and you’d often have to just do it anyway and hope you’d get away with it quite a lot of the time.
Drew: We don’t seem to see that so much these days where clients or anyone really is looking at a web experience side by side in two different browsers and saying, oh, they’re not quite the same. Is that because browsers are much more standardized now and they do look the same or have the expectations changed, do you think, because of so many devices that we’re looking at, the fact that mobile devices and tablets and so many different screen sizes that has that expectation gone away?
Rachel: Yeah, I think it’s a bit of both, isn’t it? I think the web browser is how we do everything these days and it’s less of a separate bit of software, it’s just kind of how you use your computer and a lot of the time and I think theres less of an awareness of, oh, we should be checking this for someone who isn’t a developer, we should be checking this in the different browsers. Far more likely, I think, would be someone saying, “This doesn’t work well on my phone.” ‘Cause they’ll get the email saying, oh look at the new site, and they’re probably on their phone when they get that email and they’ll open it on their phone and then they find, oh, somethings overlaying something or it’s hard to get to something because of a toolbar or whatever.
Rachel: So I think it’s far more likely that a client is going to be coming back with that kind of problem. Maybe they’ve got an older version, an older phone that they’ve not updated and it’s got an older version of software on it or whatever than doing that kind of desktop A/B testing that used to be really common, even with a fairly non-technical client, they would’ve been told by someone that they should make sure it works in these browsers and so they would be doing that checking.
Drew: Yeah, I mean clients would come along to those of us who are building sites for them and they would say, right, we need this site built and it needs to work in IE6 or it needs to work in IE7 and they’d have these very definitive browser versions that things had to work in. And now between, as you mentioned, between IE6 and IE7, there was a multiple year gap, so that constraint from the client could have, it could massively impact your sort of choice of technology or design, couldn’t it?
Rachel: Oh, absolutely. Yeah, I mean that was just sort of fairly standard when you were building sites and at the time I was building sites for clients that would be on the spec for the site would be which browsers that you had to support and you would be expected to test it in those browsers and if it worked in those browsers, that was all good. That was the line that you were following.
Drew: Yeah, I guess even things, even that things were pretty limited. It was a fairly easy decision to make to say these are the browsers that we’re supporting. It’s got to work in IE7 for whatever reason.
Rachel: Yeah.
Drew: It was fairly clear cut, but these days I don’t think I could even tell you what version of Chrome or Firefox or Safari I’m running or if that’s the latest, I’m presuming it’s the latest, but it’s not so clear cut and straightforward now, is it?
Rachel: Right, yeah. You don’t even notice that the things update. They just update and you don’t realize if that’s a major version or just some say security release that’s come out that you need to update to. I don’t think most people know which features landed in which version of a browser. We used to know. We used to know exactly what was available in each browser, so it’d be like, “Oh great, this project is IE8 and therefore I’ve got, I don’t know, display table” or something that landed in that browser.
Rachel: We used to know. These days we don’t know. I know I spend all of my time documenting this stuff and writing about whats new in the web platform and even so, I’m fairly hazy. If you said to me, “Oh, what was in Chrome 113?” And I’ve just done the work on that, I’d be like, “Err, was that in that one or was that in the beta?” So the average developer then you’re not going to be able to keep track of all that stuff. Theres so much stuff landing all the time.
Drew: So it makes the situation quite difficult, doesn’t it, when you might have sometimes contracts with people you’re building stuff for and certainly expectations that theres going to be a level of browser support but it’s not, if you don’t know what versions things are and they move really quickly, it can be really difficult to pin down to a targeted browser version. And this is, I believe it’s the crux of the problem that’s addressed by one of the big announcements at Google I/O. How do we figure out whats safe to use?
Rachel: Yeah, and so this is something we’ve been thinking about actually for as long as I’ve been at Google is we’ve been thinking of this top pain point that we hear from developers that they struggle to keep up with the web platform and they struggle to know what is safe to use, what is okay to roll out in production without worrying about it. Typically developers will be building for the latest versions of a site and then suddenly they’ll realize that, oh, this is broken over here and they just don’t, they didn’t realize that and to actually figure out the browser support involves going kind of property-by-property, feature-by-feature to say, can I use our MDN and looking at the compatibility data. It’s all out there, but you have to do that on a feature-by-feature basis.
Rachel: And so we’re kind of thinking about this issue and it always comes up, we talk to a lot of developers and it always comes up as the top problem and so we’re thinking about how we can resolve that. And that’s what kind of came to this idea of, well, can we create this line and say that everything that’s passed this line has interoperability, is kind of safe to use without worrying about it. And that’s where this idea of Baseline came from, to have this kind of moving line that includes all of the features that are interoperable and don’t have any major standout issues. And that’s what we’re calling Baseline.
Rachel: And the whole project is it’s not just a Google thing, this comes from the Web DX community group. So we’re working with other browsers and other people on defining this and kind of coming up with the feature groupings so that we can try and create this clarity for developers that they’ve got a sort of line where they can say, they can look at that and say, oh yes, this thing is in Baseline and therefore I know it’s going to work everywhere in the most modern browsers.
Drew: So instead of saying this, we’re supporting these particular browsers, you’re saying this is a core feature set that’s common across all the currently available browsers. This is a safe set of features and it’s that set that I’m going to be developing for compatibility with.
Rachel: Right, yeah. And that sort of takes that requirement to figure out each individual feature for, and also because we get partial implementations of stuff all the time on the platform and it’s like, so the kind of feature grouping part of this, it is the big piece of work really to actually identify, does the feature completely work everywhere because sometimes there will be support for things. I think one of the things that, an obvious thing that people understand is the gap property in where in Flexbox and Grid and so on. Now you could test for that. You could test for where the gap was supported and a browser would say yes because it was supported in grid layout even when it wasn’t supported in flex layout and therefore there was no way to check for this. And it was quite confusing for people if they were just doing that test. So I think theres these sort of groupings of things is also quite useful. So the things that are in Baseline are things that do work as a feature, even if that does actually involve various moving parts.
Drew: Yes, because theres been a trend from the sort of latest CSS specs to be, whats the word, sort of unifying some of the properties isn’t there rather than-
Rachel: Yes.
Drew:span> … rather than having individual properties that do the same thing in different context, using the same-
Rachel: Right.
Drew:span> … keywords across different uses.
Rachel: Yeah, so things like alignment, fragmentation, we’ve got these specifications that deal with sort of alignment across all of the different layout specs, which is great because it means that say if you want to switch from a flex to a grid layout or whatever, all the alignment stuff should work in the same way, but does mean that we potentially get these partial implementations and that’s quite difficult to understand. So yeah, I think it’s things like that and so that theres an awful lot actually goes into the creation of this sort of feature set grouping and we’re not all the way there yet. We’re hoping to get most of CSS and JavaScript done by the end of the year because it’s actually quite a job just to figure out how things all fit together.
Drew: So it’s almost like instead of targeting a version of any particular browser, we’re targeting a version of the web platform. We’re saying-
Rachel: Yeah.
Drew:span> … look at the web platform as it is here today, these are the things that are universal, that are reliable to use and that’s what we’re going to support. And anything that falls out of that boundary included because the implementation might be patchy.
Rachel: Right, yeah. It might need a bit more care. And it’s not saying to people, oh, you can’t ever use these things, but if you know it’s not in Baseline then maybe theres some things you need to think about there and it might be fine for your project or it might be that it has a good fallback or it’s something that is polyfillable but those are things that you do need to think about on a case-by-case basis rather than just, this should be fine to use.
Drew: I think most of us are familiar with sites like canIuse.com, which you mentioned briefly before. Is this just replicating information that already exists or is it different from can I use?
Rachel: I think it’s different in that, so something that can I use does, and also the MDN BCD data, they work very much on a sort of feature-by-feature basis. They don’t actually cover all of the web platform. Theres definitely, certainly Can I use has made some decisions in terms of how to group certain things. I have a long standing open issue to split out fragmentation from multicar for example, because they’re bundled together, making multicar look harder to use than it actually is because there are fragmentation bugs in there.
Rachel: So they’ve done some of the same stuff, but what we haven’t got there is this sort of full view of the platform and this idea of this is within Baseline, this is out, you still have to go to each thing and make those decisions. Ideally we’re hoping, I mean as MDN are using Baseline on feature pages, they’re rolling that out at the moment. It’s probably saying that we’re hoping that Can I use, we’ll also be able to use and say, “Oh, this feature is in Baseline” as well as that more fine grained data.
Drew: And how do you make that decision to say that yes, this, not only is this supported but this is widely supported enough that we can include it in Baseline. How do you make that distinction?
Rachel: So at the moment we’re going back the last two major versions of browsers and theres been a lot of debate about that — as you can imagine. It’s something that’s great to [inaudible 00:17:38]. The fact is I think the line will always be wrong for if we say this is the line, two versions back, a lot of people are saying, “Oh, you should use minor versions of Safari” because we’ve seen some massive features going in doc releases because of the way that Safari do their versioning because obviously a main version of Firefox and Chrome, that’s every month we’ve got a new main version. And so that’s obviously up for debate. Some people are saying we should go further back. Other people are pointing out the fact that just because Chrome has updated, all of the browsers are derivatives that use chromium, they might not have updated. So I think the line will always be wrong, I think.
Rachel: But what it does give is this sort of stable view onto things. And the other thing that we’re planning to do as part of this is to have these kind of moments in time. So at the end of the year we’re going to say, right this cut is where we are at that point is going to be Baseline 24 and that will be a static line. That will be whats in Baseline at this point in time. And then in a years time we’ll do Baseline 25. And I think an interesting thing then will be the difference between those two points because I think a conservative web team could say, “Right, I am sticking with Baseline 24” even though maybe they’re well into 25, we’re sticking with this.
Rachel: But the things between those two lines then I think become the things that you might want to make judgments on rather than having to look at the entire web platform and say, “Oh, can I use this? Can I use that?” And say, “Well, we’re going to use this yearly cut of Baseline.” And then the things that came after that that are in Baseline as it moves forward we’ll take a look at and see, oh, I can polyfill that or this is fine as a progressive enhancement.
Drew: It puts me in mind slightly of things like Ubuntu Linux distribution and their long-term support releases that they do.
Rachel: Right.
Drew: They’ll say, “This is the one that we offer long-term support. It’s stable, it’s reliable to use.” And so you might adopt that and that doesn’t mean that you wouldn’t necessarily install a couple of key extra, more frequently updated packages or whatever, but you know that the system that you’re working with is sort of frozen in time and supported and is a known quantity going forward.
Rachel: Yeah.
Drew: I guess those who work in very regulated industries who sort of frequently go under contract with customers or suppliers, whatever, to say they’ll provide compatibility with certain browsers as it is at the moment. Surely this would be a very welcome change because these are actually more concrete measures that support can be tied to and it’s a stability that’s more in line with the stability of a binding agreement than an arbitrary version number that some nerd in Silicon Valley might attach to a build of a browser.
Rachel: Right.
Drew: So you can say our platform is targeting Baseline 24 and you could keep that way for three, four years maybe.
Rachel: Yeah.
Drew: And then review it and update.
Rachel: Yeah, I like that. I like that stuff, yeah, the idea, this is a sort of stable thing and I think that that yearly release will become, I think, quite important. So I think I can see libraries and frameworks and so on tying themselves essentially to a stable release, one of the yearly cuts and then moving on. And I think it should be really interesting as well being able to see, well actually how has the platform moved on between those two yearly points? We don’t really have a look at that at the moment. I mean you could work it out, but it’d be quite a lot of work. It’d be nice just to be able to see that and see how things are changing.
Drew: I always enjoy a list of features that are included in whatever. Heres things that you can use that you won’t, perhaps weren’t aware of. And I can see how a big list of Baseline features might highlight different things that an individual developer might not be aware of that-
Rachel: Yeah.
Drew:span> … have arrived on the web platform and are ready to be used.
Rachel: Yeah, I mean the awareness is a big thing. I mean, I’ve been doing, me and a colleague as well have been doing talks, whats new on the web platform type talks and typically introducing things that are interoperable. And every time there will be people saying, “Oh, I never knew you could do that”, or “I never knew that worked. I thought that was an experimental thing.” And then realizing that it’s actually a feature that’s in all engines. And I think that that’s very, very common. So I think that’s the other sort of side of this is that it also raises awareness of features that now are interoperable, that people have got an idea that the web platform moves incredibly slowly.
Rachel: I think particularly people like us who’ve been doing this for a long time and remember those days. And so people are very surprised, you know, you still see people saying about a new feature, “Oh well it’ll be five years before I can use that.” And yet you’re looking at things like container queries and cascade layers. All of these things landed cross browser very, very quickly, which is great. And I think that’s a story that this can help tell as well.
Drew: So this was a big announcement from Chrome at the big Google I/O conference, but you mentioned it’s not just a Google thing is it, there are other parties involved. So who is deciding whats in the collective Baseline? What parties are involved in this?
Rachel: Right, yeah, so I mean obviously we partnered very closely with Mozilla and MDN in launching this. So that actually during the developer keynote we launched this on web.dev and on MDN at the same time on a select number of pages because we haven’t got a full feature site yet. But it was nice to actually show what it would look like rather than it being a kind of theoretical thing. And also MDN published a blog post about it too and their thinking. But yeah, the work has been done within the Web DX community group and that group has representatives from all of the browsers and various other people including interested developers.
Rachel: Anyone can join that group and be part of those discussions. So that’s where we’re also asking people to go and comment on this stuff rather than, I mean people are very welcome to come and talk to me about it, but in terms of getting sort of information out there and discussed by the wider group, raise issues on the Web DX community group site because that’s where the people are who are making the decisions. And at the moment it’s just fantastic to be getting the feedback into that group so that we can actually see is this solving a problem, what problems maybe we’ve missed and be able to talk about that.
Drew: So it’s a broader community effort, but it just so happens that the major players Google, Mozilla and everything are putting a lot of time and effort into it and really backing it as an idea.
Rachel: Yeah, yeah. And I think that’s something that as DevRel, you know, as developer relations, that’s kind of what we do. We try and bridge the gap between browser engineers and spec writers and the developer community. And so I think that’s something that we can do as DevRel for the web is to actually bring forward these things that we think might help and see where we can take them.
Drew: Now I’ve heard about the Interop 2022 and now 2023 initiatives. Does Baseline relate to Interop at all? Or maybe you could talk us through that where it fits in?
Rachel: Yeah, I mean it’s kind of the same group of people certainly as Google who are involved with those projects. So the Interop project takes a set of features that if it’s based on web platform tests, so it takes a set of features that have some sort of interoperability problem. So it might be that they don’t work in one or more browsers or they have sort of bugs that are causing pupil problems. So we’ve got this set of features and then over the year all of the engines work to implement or fix those things. So we’ve kind of got a score, a scoreboard where you can go and look and see how everyones doing.
Rachel: So the Interop project works to fix known issues, either make things interoperable or fix books and things that look on paper like they work, but have some sort of problems. And so that project is getting more things essentially into Baseline. So they’re linked in that way and they’re a lot of the very similar people are working together on those from the browsers. So I think in terms of the relationships there and the fact that Interop did bring, for the first time, all of the vendors together in this sort of common goal to make the platform better, theres definitely a link there in terms of this is what we care about. Whereas Baselines kind of from the other side, it’s saying, well, okay, what is there? What is interoperable? What can we already use? So yeah, hopefully things like Interop will help to add more things to Baseline as we go along.
Drew: So it is basically just identifying things that could potentially go into Baseline, might be nearly there, and then swarming on those features to get them across the line and get them interoperable and usable on the platform because they’re seen as important or significant in some way.
Rachel: Yeah, and I mean we know that that developers aren’t going to use things in general unless they are available across all engines. So it’s kind of in everyones interest to work together to get to that point because then people use the stuff that we’re building so that, yeah, it’s said so they kind of work very well together. And I think it’s just this sort of spirit of collaboration and trying to make things better for developers.
Drew: We’ve talked about how developers might target, in past, a browser version and now we’re saying would target Baseline, but it works the other way around, doesn’t it? If the frameworks and the tools that we are using as dependencies in our projects, they can also declare that as a level of support. Is that right?
Rachel: Yeah, absolutely. I think that’s something that we’d love to see how a framework or whatever you could say, everything that is used by this framework is Baseline or is Baseline 24 or what have you. That’s going to give a lot of clarity to developers to not then need to fish around in the framework and find out what they’re doing to make sure ‘cause if you’ve got to do a certain level of browser support in your project, you need to make sure that everything you use also has that level of browser support so that it could definitely make that a lot clearer.
Rachel: And I think also things like publishing articles. One of the things that frustrates people, and I know as someone who writes and edits a lot of content, is if people get halfway through an article and then they find something that is experimental or is so new or only works in Chrome or whatever, that’s really frustrating because you think, oh, I’ve found the thing that helps me solve my problem. You’re working through it and then you’re like, oh, that’s not coming ‘til next year. And so have been able to put on an article, everything in this article is in Baseline. That gives you a lot of confidence to go forward. So I think theres lots of uses for this out in the community and that’s something we really hope will happen, that just to give that kind of clarity to developers.
Drew: It’s that last section of an article, isn’t it? You’re reading along about some interesting technology and then it comes to the section of how you might work around it for the browsers that don’t support it.
Rachel: Yeah.
Drew: I thought-
Rachel: Exactly.
Drew:span> … we were into a good thing here.
Rachel: Yeah, ‘cause when you’re searching, you’re searching to solve a problem, things come up. It’s very frustrating if you realize that it’s a year away or other browsers have said we’re not doing that or whatever, you know? So yeah, I think theres a lot of opportunities for clarity for people who are writing and for developers of libraries and frameworks to actually just make it very obvious to developers what the status is.
Drew: And things like WordPress themes for example, or any of these sorts of things where you’re taking somebody elses code and making it part of your project to know that what level of support in terms of web functionality is in that is invaluable. I guess it would make sense for things like tools that any tool that gives you code to embed into your site, be that a Stripe checkout or a live chat widget or any of those sorts of things, I guess it would make sense for them to declare their state of compatibility too.
Rachel: Yeah, yeah, it’s just kind of a shorthand. It saves you having to do all of that investigating for each thing that you use. And we know that every website these days has tons and tons of third party stuff in it. We’re not all sitting down with Notepad anymore and carefully crafting our websites. So I think anything that makes that easier and allows people to show the status of things is really helpful.
Drew: It actually is a really simple concept, isn’t it, to say heres the set of features, they’re well supported, we’re giving it a label, we’re documenting it. It’s actually so simple, it’s really rather genius I think. It’s some amazing work that’s been done there by everyone involved.
Rachel: Yeah, I think it speaks to a lot of what I’ve thought about over many years in terms of that kind of clarity. And that’s always been my thing is making things clear to people, making things seem straightforward rather than trying to make things complex. And so I really love being able to be involved with this and bring it forward.
Drew: The HTML spec for example has a process for an element or an attribute to be deprecated. So things get removed from the spec as they become obsolete or they’re replaced by a newer specification. Is it possible for features to drop out of Baseline once they’ve been included?
Rachel: It could be possible. It’s one of the things we’ve talked about a lot. I think really the devil will definitely be in the detail with all this stuff. And that’s one of the things is well what happens if something essentially gets broken? Maybe one engine does something which causes a problem with something. There is a possibility that yes, we’d have to remove something. That’s definitely something we’ve talked about. I mean hopefully browsers aren’t going around breaking stable features, but it is a possibility or something might get deprecated although we tend not to fully remove things from the web platform very often. It’s more that we say, “Yeah, maybe don’t use this,” but there is a possibility that something that is in Baseline could start to have a problem because of something that one of the engines does.
Drew: I guess then that’s one area where these sort of yearly cuts as you’ve described them, become sort of quite useful in that something might have appeared in Baseline 24 but then in Baseline 30 it might be gone and there is a way of having a distinction there.
Rachel: Yeah, and it would also highlight that stuff I think a lot more clearly than we have a way of doing at the moment because I think hard to know what things have actually been deprecated on the platform. A lot of things that are deprecated are things that are only in one engine and therefore would never have been in Baseline in the first place. But yeah, it is possible as things move forward that that would happen and it would make it clearer.
Drew: And such as the way of the web, we do deprecate things, but as you say, they don’t ever go away really.
Rachel: Yeah.
Drew: We don’t-
Rachel: I was just saying maybe don’t use—
Drew:span> … tend to remove things, you know, can still use the, I’m guessing you can still use HTML font tags because we don’t break things once they’re standardized.
Rachel: Yeah.
Drew: Even though nobody would ever recommend using them, they’re still going to work in your browser because sites have been developed to that standard and the browser-
Rachel: Yeah.
Drew:span> … will continue to support it. I guess, in a way, theres Baseline forms a little bit of a positive pressure. If a feature does get broken, then the fact that it was in Baseline and the whole community is relying on it being there is a factor in prioritizing what gets worked on by that particular maintainer of that browser engine. They’re going to see that, no, this is important, we need to fix it pretty quick.
Rachel: Yeah.
Drew: So hopefully it’s a sort of positive pressure in that regard. There seems to be so much really in development and coming to the web platform. Are there any particular things that you’re really looking forward to seeing becoming interoperable in the coming months?
Rachel: Yeah, I mean theres a bunch of interesting stuff. I’ve always been interested in the things that look at things that developers are already doing. So they’re using JavaScript to do it, or what have you, and then having them built into the platform because obviously things that are built into the platform we can build in things like accessibility and also performance. Things that tend to perform an awful lot better if they’re a built-in feature as opposed to being JavaScript on top. So theres sort of interesting stuff from the open UI group. The next thing that is about to land in Chrome is the Popover API. And of course popovers are something like everybodys building all the time.
Drew: Yeah.
Rachel: And I think a lot of these open UI things are very much those sorts of features that pretty much every developer, every front end developer has built on numerous occasions. And every front end developer has tried to solve the accessibility issues and the performance issues and the sort of weird bugs that come up when they interact with other things. And so the fact that these are getting actually built into browsers, I think, is very exciting because it just, it’s a bunch of work you don’t have to do and it’s probably going to have better accessibility and so on than most people are going to be able to manage for themselves and it gives something to build on top of as well, you know, can add things to them.
Rachel: So yeah, so I’m excited to see Popover and in a similar sort of vein is the work on scroll-driven animations because that’s a thing that people like to do and is very hard to do well, you know, having things that animate on scroll and that, again, is something that is coming in. It should be in Chrome 115. So it’s, again, it’s these things that we’re doing on the front end of the web and we’re actually able then to build into the browser. I’m always very keen to see those ‘cause I think they solve a lot of problems.
Drew: Yeah, definitely. I mean anywhere where a developer has to mimic something that you think is native browser UI and you’re trying to build it yourself, there are so many places to go wrong, aren’t there?
Rachel: Yeah.
Drew: If you’ve ever had any of your work through an accessibility audit, you know that it’s things like modal dialogues and all these sort of things that constantly will contain flaws that need to be addressed because theres just so many things to think about in terms of keyboard focus and clicking away and all these different subtleties that you need to make sure that you take care of, that is, as much as anything, as much as it being bad for accessibility, if you get it wrong, it’s a massive waste of time for all us developers doing this all ourselves over and over again when it just makes sense. Most apps will have some sort of modal or popover functionality. So yeah, it makes complete sense for it to be part of the platform implemented by the browser vendors in a way where it’s accessible and it’s just a good solid layer to then build on top of in terms of styling and yeah-
Rachel: Yeah.
Drew:span> … it makes total sense. It’s a exciting way to see the platform go.
Rachel: Yeah and I think, because the other thing with everyone building their own thing is that a lot of people don’t build their own thing, they rely on a third party thing and quite often things people are relying on are actually really old and they haven’t been updated to, they might have issues with accessibility or whatever and they haven’t really been updated for more modern browsers. And so it’s sort of, I think the more that people can use whats built into the browser, the sort of better experience that the end user of the site is likely to have.
Drew: So your team at Google maintains a bunch of resources to help developers keep up-to-date with the web platform. What are those resources and where should people go to look and find things? What would they expect to find there?
Rachel: Yeah, so we’ve got web.dev and developer.chrome.com are our two sites that DevRel own. It used to be, back in the day, when I sort of arrived, there was a real mixture of things on each site and a sort of thing that was commonly said was that Chrome were using web.dev to pretend things that were only in Chrome were stable APIs, lets say I don’t think anyone ever intended to pretend that. I think there was just a slightly disorganized content strategy. So as kind of part of the preparation for Baseline, because I wanted to make sure that we could be clear because if we’re talking about developer clarity, it’s pretty bad if all of our stuffs in a mess. I started moving content. And so now, certainly all the newer content, there may be some older stuff that we haven’t tracked down, but the newer content, if you go to web.dev, you should really be seeing stuff about stable APIs.
Rachel: So things that are interoperable and also things that are coming onto the platform. I do a sort of whats new on the web platform that includes some new stuff from all engines. So that kind of looking at what the broader landscape is and also things like our best practices. So things like about performance, which while some of the tooling is Chrome-only, raising the performance of your site, it is going to help in all engines. So that’s whats there on web.dev. So that’s kind of the practical side of things. You’re building a website, you want some advice. That’s what we’re doing there. And I try very hard to make that about the web, not about Chrome and that’s the sort of content there.
Rachel: But obviously we are a team that’s supporting Chrome and supporting the things that Chromes releasing and so we do that over on developer.chrome.com. So that’s going to be your new APIs. You want to find out about popover that’s landing, there’ll be an article about that soon. So all the things that Chrome is doing for the web, essentially you can find on developer.chrome.com. So that will be experimental things or Chrome-only things, things that are Chrome-only for now, all that stuff is there. And I hope that brings a bit of clarity to our content and that we’re not trying to pretend anything. We’re just trying to be clear about what we’re doing and how well supported it is.
Drew: Great. So we’ve been learning all about Web Platform Baseline. What have you been learning about lately, Rachel?
Rachel: Theres always something interesting to learn about. I’ve done a couple of things. I’ve been learning Python because it’s a language that I, for whatever reason, never learned. I’ve learned various languages over the years, but I do less web development these days and more kind of comparing of data sets and Python is the language that a lot of that stuff is done in. So it’s quite fun to learn new language anyway and it’s useful for the sort of stuff I tend to find myself doing these days.
Rachel: And I’ve also been thinking a bit about the whole generative AI space and in particular as a content lead, how do we prepare our content to make it more useful to those kind of models because theres a lot of stuff about asking questions of a chatbot and so on. And so I’ve been kind of just starting to read around that subject a little bit and start to see, well, if we’re preparing content, how can we be making that more useful for that kind of thing and that interaction?
Drew: If you, dear listener would like to hear more from Rachel, you can find her on the web at rachelandrew.co.uk where you’ll find links to her socials, her writing and numerous other projects. And you can find her writing regularly about the web platform at web.dev. Thanks for joining us today, Rachel. Did you have any parting words?
Rachel: Let us know about Baseline. Comment and raise some issues, or just join in the chat on the Web DX community group, on the GitHub repo there. We’d really like to hear what you think. This is, we’ve been talking about it internally for a long time and so now we’ve got it out there and I think the work starts now and the discussion with the community starts now. And so we’re all very, very excited to read the feedback and find out what you think.
Resources
(il)
[ad_2]
