[00:00:00] Nathan Wrigley: Welcome to the Jukebox Podcast from WP Tavern. My name is Nathan Wrigley.

Jukebox is a podcast which is dedicated to all things WordPress, the people, the events, the plugins, the blocks, the themes, and in this case, how the Interactivity and HTML APIs are transforming the way developers work with WordPress.

If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice, or by going to wptavern.com/feed/podcast, and you can copy that URL into most podcast players.

If you have a topic that you’d like us to feature on the podcast, I’m keen to hear from you and hopefully get you, or your idea, featured on the show. Head to wptavern.com/contact/jukebox and use the form there.

So on the podcast today, we have Milana Cap. Milana is a seasoned WordPress engineer from Serbia working with XWP, and freelancing through Toptal. She’s not just a developer, she’s also active in WordPress community roles such as a co-rep for the documentation team, organizer at multiple WordCamps, and a member of the plugin review team.

We discussed some groundbreaking WordPress features that developers should be aware of, specifically focusing on her presentation at WordCamp Asia in Manila, titled, WordPress gems for developers: Fresh new features you’ll actually want to use.

We start the discussion with the Interactivity API. Milana explains how this feature allows blocks within WordPress to communicate seamlessly with one another. Until now, most blocks were just silos of information, they could not communicate with one another. This API enables developers to manage interactivity across multiple blocks without resorting to custom solutions.

Milana also gets into the HTML API, which underpins the Interactivity API. This empowers developers to manipulate HTML attributes using PHP, thereby reducing the reliance on JavaScript. This not only enhances page load speeds, but also simplifies the code management process. It’s not something that I’d heard of, but Milana explains how important it can be in rewriting the DOM for whatever goals you have in mind.

Throughout the episode, Milana shares examples of these APIs in action, demonstrating how they can simplify and optimize WordPress development projects, particularly at an enterprise level.

If you’re a developer looking to leverage these new WordPress features, this episode is for you.

If you’re interested in finding out more, you can find all of the links in the show notes by heading to wptavern.com/podcast, where you’ll find all the other episodes as well.

And so, without further delay, I bring you Milana Cap.

I am joined on the podcast by Milana Cap.

[00:03:32] Milana Cap: Yes. Thank you.

[00:03:33] Nathan Wrigley: Thank you. I’ve had to practice that name several times. It’s lovely to have you on the podcast today. I’ve never spoken to Milana before, although I’ve seen her from afar many times.

And we’re facing each other because we’re in the Philippines. We’re in Manila. It’s WordCamp Asia, and Milana is doing a presentation at the event. It is called WordPress gems for developers: fresh new features you’ll actually want to use.

Before we get into that conversation Milana, will you just spend a moment introducing yourself. Tell us who you are, where you’re from, what you do with WordPress, that kind of thing.

[00:04:07] Milana Cap: I’m Milana Cap from Serbia, and we have the best community in the world. I am currently WordPress Engineer at XWP and also freelancing through Toptal. I am one of the co reps for the documentation team, one of plugin review team members. I’m also a classical musician and just, you know, being loud all around. I like traveling and speaking at conferences, and that’s basically it.

[00:04:38] Nathan Wrigley: Can you just tell us a little bit about the bits and pieces going on in Serbia there? You sound quite proud of it. You said it the best or something like that. You’ve got a vibrant, healthy growing Serbian community.

[00:04:49] Milana Cap: Well, it’s not really growing, and it’s not that vibrant as it was. But the core of community that started getting together in 2016, or even before that, we still stayed, and we are still active and they’re like my brothers. We travel, we plan together. We visit each other in Serbia as friends, and we plan for barbecues and all the other stuff, besides, you know, organising events.

[00:05:22] Nathan Wrigley: So it really is an actual community.

[00:05:24] Milana Cap: Yeah it is.

[00:05:25] Nathan Wrigley: You spend social time together. Oh, that’s lovely. Yeah, and you mentioned you work with, for, XWP. This is a name that I hear a lot, but I don’t really know much about the company. Just tell us a little bit about what you do for them, and with them.

[00:05:39] Milana Cap: First of all, they are sponsoring my time at wordpress.org. It’s an agency that works mainly with enterprise clients. So we do all of it, like building you a new website, or maintaining the existing one, or fixing problems. And it’s usually, mostly, just enterprise clients.

[00:05:59] Nathan Wrigley: Is that an Australian based company?

[00:06:02] Milana Cap: It’s kind of, yeah, based. It’s created there but we are completely remote.

[00:06:07] Nathan Wrigley: Everything distributed, like a global team. Oh, that’s nice.

Okay, so let’s just move on into the topic today. The presentation that you were giving, I’ll just repeat the title, WordPress gems for developers, fresh new features you’ll actually want to use. And then I’ll read the blurb as well because it’ll give the listeners some context. We’ll take a closer look at the innovative HTML and Interactivity APIs as the most significant game changers in today’s WordPress development, with a splash of WP-CLI magic for fast and more fun development. And there might be a surprise or two.

Well, obviously on the audio podcast, we’re not going to be able to breakout WPCLI, but nevertheless, we’re going to talk about those things. We’re going to concentrate primarily on the Interactivity API. Obviously this is something that you’d need to get your hands on, you’d need to be opening a laptop. But we can’t do that. It’s an audio podcast. So first of all, let’s just break into the topic by asking the question, what is the Interactivity API? And let’s do that from a total novice perspective.

[00:07:07] Milana Cap: Okay, yeah. Well, Interactivity API allows you to get back to the whole page. At least I see it that way. Because before Gutenberg, we were using only PHP, and PHP page is aware of all of its parts. So in header, you know what’s happening in footer and vice versa.

But then we got Gutenberg and these blocks didn’t know about their surroundings. They were just like, oh, I’m a block here, and I do what I do and I don’t care about others.

And it was difficult to get that in your head, like this is a completely separate entity that, once it’s in a page, you can work with that, but there is no way to connect to it to the rest of the page. And today you have a lot of requests for having interactive page. You know, not just showing the text and people come and read, you need to have something that’s happening on that page.

And it was very difficult to, for example, make one block do something and then you use that data in another block, that was insane. And people were trying to do those things in so many different ways. It was a mess. Like, I have a slide with dolls that have misplaced eyes and all of that. That’s how it looks like.

So now with Interactivity API we finally get that connection, but it’s not like hacky thing, it’s in Core. So every block can be aware of the other block, and you can send the data from one block to all other blocks. And that’s really what was missing for a long time. And not just in WordPress, we have the same things happening before WordPress, in Symphony, in Laravel. So now we have that too.

[00:09:04] Nathan Wrigley: So let me just try and sum up what you’ve just said, and see if I’ve parsed it correctly and understood it. So prior to Gutenberg, given the PHP nature of WordPress, the bits and pieces that were displaying on the page, so header, footer content and what have you, they had some recognition within PHP of what one was doing and what the other was doing.

And then along comes Gutenberg and we shatter the experience on the page into a variety of different blocks. There’s an image here, and a paragraph here, and some more text over here, and a heading and what have you. And each of those little blocks is a silo. It lives by itself, for itself, it’s erected walls around itself so that it can’t be communicated.

[00:09:41] Milana Cap: It’s a diva.

[00:09:41] Nathan Wrigley: It can’t talk out and it can’t hear things in. And that’s a problem. I mean, it’s a brilliant solution if you want to move content around, but If you want one thing to shout to another thing and say, look, I just got clicked, go and update yourself. Add one to yourself, or whatever it may be. So that possibility evaporated.

But now with the Interactivity API, we’ve come up with a Core solution. So it ships with WordPress, everybody has it. And suddenly we’re able to say, okay, I’m a block, I’m a button, and when I get clicked, I want you to add one to the cart. And the shopping cart number can increment by one and what have you. So suddenly everything can communicate with everything else. Have I got that about right?

[00:10:23] Milana Cap: Yes.

[00:10:24] Nathan Wrigley: Oh, perfect. Okay. And so I’ve seen examples of Interactivity over many years since Gutenberg came around, and I’m imagining that each developer, therefore has had to create their own way of doing it. And presumably that works for them, but it doesn’t work for the project as a whole.

[00:10:44] Milana Cap: Not just that. It might work for them but, let’s say you have a plugin and your plugin is doing that interactive thing with your own blocks. But me as another developer, I want maybe to enhance your blocks, but I don’t have access to whatever is happening in your blocks. So whatever you are doing, like counting stuff and changing something, I don’t have that info. So I have to do, again, hacky thing.

But with Interactivity API, I have a standardised access to that. So I can, you know, set my blocks to support Interactivity API. And I can get, with just one function, I can get all the data from your blocks and work with them, and it’s completely in Core. It’s standardised. And anybody can take my data and, you know, this data and do whatever they want with that. And it’s not just that it’s easy to get that data, but we all do it the same way. So when I open your block, I know exactly what I will find there. I know exactly how to get that data, and how to provide to others.

[00:11:58] Nathan Wrigley: So the benefit is basically that it’s a standard mechanism. Everybody knows what the rules of the game are. So in the past, the experiences that I’ve seen online where plugin A has been able to clearly demonstrate this interactivity, a different developer coming to that would have to learn how plugin A does it, and then if they go and try and do the same thing for a different plugin from a rival, for example, they would have to learn that one.

And every time you wanted to do it, you’d have to learn how that system does it. So there’s no interoperability. It’s just little silos of interactivity. They worked, but they were a sort of stepping stone to what we’ve got now.

Okay, I think I understand that. That’s great. Hopefully the audience has got that as well. That should be good. Can you give us some nice examples that you’ve seen where the Interactivity API, you describe it, the audience can hear it and readily understand, okay, that’s something that it can handle.

[00:12:49] Milana Cap: Well, there is a beautiful demo that is used for demonstrating the Interactivity API by people who created Interactivity API. It’s a movie demo, and you can find it if you go for introductory post of Interactivity API at Core blog, you will find it. So it’s a simplified Netflix made with WordPress. So you get simple things like there is a favorites. So you can heart a movie, and it’ll show the number, how many favorites you have. But when you dig deeper, you can open one movie and play the trailer, and it’ll have a minimised video on the bottom. And you can, you know, browse the website and switch pages, and the video is still playing in the corner and it doesn’t even hiccup.

The thing that is happening there is you think you are reloading pages. You think you are going to different pages, but it’s really the same page and it’s just being reloaded in what you need to reload. So it’s the hardest thing for developer to do, to switch page, but doesn’t really reload the page. And if you take a look, if you try that demo and you take a look, you will see that URL changes, everything changes, but you really didn’t move from the first page.

[00:14:18] Nathan Wrigley: Okay, so what you’ve just described then, you’ve got a, like a tiled selection of videos, and underneath it is like a little heart icon. So it’s just a demonstration that if you click the heart icon, it says, I like this one. And then it keeps a record of that somewhere else. Like, how many of you hearted over here? Or, click this heart icon and it’ll take you to the ones that you favorited. That kind of thing. But also it gives the impression that you’re reloading pages, but really it’s all just happening within that one page session.

[00:14:46] Milana Cap: Yes.

[00:14:47] Nathan Wrigley: Okay. So that’s a really easy to understand version of it. And I would imagine something like, let’s say a shopping cart, I think I mentioned that earlier, where you, I don’t know, you click that you want to add something to the cart, sort of similar process. It’s a bit like hearting, isn’t it? You add something to the cart and you get that interactive cart icon in the top right of the screen if you’re on a desktop. And it says you’ve got three items in there, and you click it and you’ve got four items in there, and so on. Those kind of things. So again, it’s one part of the website, one block if you like, updating another thing. Are there any other examples that you think are quite useful?

[00:15:21] Milana Cap: Well, I saw like countdown. So if you want your website to show the countdown until launching something. There’s also we have already two examples in Core working. So you have a query block, and you can select to have it paginated, without pagination. That’s Interactivity API.

So anywhere you would use Ajax before, you can use Interactivity API. It’ll give you that feeling of nothing has been reloaded, so it’s just loading in that place. You don’t use Ajax, you just use Interactivity API.

[00:16:05] Nathan Wrigley: So this would be, I don’t know, a list of posts or something like that. And at the bottom of the screen, we’ve seen the first 12, 12 more, you would typically click two or the right arrow or something, and that would do some sort of Ajaxy request. But in this case, that’s now been removed and we’re using the Interactivity API, and it will give you the next 12, and the next 12, and so on. Yeah, that’s a really great example.

So presumably, if this is moving into WordPress Core, does that mean that a lot of the Core features that, like for example, pagination, has that now moved over in WordPress Core to using the Interactivity API?

[00:16:37] Milana Cap: Well, I know that that specific feature has moved to Interactivity API, and also the image block has the option for lightbox. That’s also Interactivity API. That’s currently in Core. And I imagine a lot of other things can be moved. But also it doesn’t have to. The only thing that it needs is a good documentation, and option that you can use it so you can do with it whatever you want.

[00:17:07] Nathan Wrigley: What is the documentation like? You know, if I was a developer and I wanted to begin using this because, sounds good, I’d rather not maintain my own bucket load of code for my interactivity in my plugin, for example. Let’s just throw all that out and go with what WordPress has. Is there a ton of documentation to get developers started?

[00:17:25] Milana Cap: There is. They are not making the same mistake we had with Gutenberg. I think for Interactivity API, the most difficult thing is to actually understand it. Because we had, I had, as PHP developer primarily, I had a problem to understand Gutenberg and to understand how React works, and why React doesn’t understand how I think, you know? And I was always over-engineering it because I was covering all the cases.

But React doesn’t care about all the cases. It was very difficult for me to understand how that works on components based, and these components don’t care about anything else but themselves.

So Interactivity API now connects all of this. And we are coming back to the system that is aware of all its parts. But not just that, in Interactivity API you have the option to write the code where it makes the most sense.

When I was playing with it, I had two blocks that were supposed to talk to each other, and I realised that something that was one block doing, it made the most sense to write the code for it in another block’s VueJS. So I was using the, there is the template that you can use for Interactivity API, and it’ll run the Create Block Script, but just use the Interactivity API template. And then you get the block that has switch from light to dark theme.

There is a toggle. The first was, it was only the toggle, and I was very disappointed. Like, the toggle shouldn’t use any JavaScript at all. But it was a good example for what Interactivity API can do. And now with the theme switching, it’s kind of complete. You understand all the things that Interactivity API is.

So this toggle was another button, and you click on it, and it shows the paragraph. And then you click on it again and it closes the paragraph. And then I used another block, and I wanted that other block to count how many times I opened and closed this toggle. It was mind blowing that that code for counting how many times I open and close it, I will show the data in this other block.

But it made much more sense to write the code for it in this first block, because I already have there code that is aware that this is open and closed. So I could just, you know, add one line of the code, and update the number there in another block. So that’s kind of the most difficult thing with Interactivity API, to understand how that functions, and that you can really achieve a lot with one piece of code, one line of code, but put it in a right place. And it can be in different places. So that’s something, you know, for you as a developer to document where I wrote things.

So with the Interactivity API, the most important thing is to actually understand how that works. There is very good documentation there for the basic stuff, definitions and all of it. And also, examples. But really, it’s not just copy, pasting from example, it’s playing with it and understanding how it is connected.

And once it’s clicked in your mind, it’s mind blowing. It’s like a game. Well, the coding for me is like a game. That’s why I started coding. But it is very interesting that you can, you know, play with it, you can break it, you can find different ways. And I was playing with putting the same code in different places to see if it will work, it will.

So there is a new skill that we will see with Interactivity API, like the most beautiful code and the most beautiful place where you put that code. And I think it’s very much open for optimising code. And you’ll see there the level of expertise of developer for how much they understand the optimisation of JavaScript code.

[00:21:45] Nathan Wrigley: Is the Interactivity API, how to describe it, is it finished?

[00:21:49] Milana Cap: No.

[00:21:50] Nathan Wrigley: Yeah. I mean, basically nothing in WordPress really is ever quite finished, is it?

[00:21:54] Milana Cap: If you software, then it’s never finished.

[00:21:56] Nathan Wrigley: No. But would you say it already has pretty much everything that you require it to have? Or can you imagine scenarios where it would be really nice to have this feature or this feature? What I’m trying to get to is, is it still under active development? Can people listening to this podcast who think that that would be an interesting use of their time to help contribute to that, is there still work to be done? And where would we go to get involved in that?

[00:22:21] Milana Cap: You can go to, there is a GitHub issue that is called Interactivity API showcase. It’s in Gutenberg repository. And you’ll see a lot of different ideas, how people want to use Interactivity API. And you will, when you start looking at those examples, you start to get ideas, what you could use it for. And you get to remember all the projects you had that you could really use Interactivity API there.

I don’t think it’s done. I don’t think it’ll ever be done because, you know, clients get very creative with things they want. And I think we can’t even imagine what we would want until we get to the request to do it for a project. So there’s a lot of things to do, as in feature terms, but there’s always, you know, fixing code, optimising here and there and cleaning things up. And then there’s an update from library that it depends on, and then you have to, you know, do that. So there’s always maintenance if you use software. It’s never done.

[00:23:31] Nathan Wrigley: I feel like if you are, let’s say 18 years old, you’ve been brought up in an era where you’ve had a phone in your hand and the apps on the phone are kind of what you’ve grown up with expecting from things online. And everything over on the phone is interactive. There’s just this expectation that you can click a button and it will do some desired action over there.

And it feels like a website that doesn’t have interactivity is almost, well, I mean, I know you can have brochure websites and things like that where it’s just static content. It feels like that’s the expectation and it’s more and more going to be the expectation. So if a project like this hadn’t come along, WordPress websites would’ve felt really strange. You know, stuck in the past in a way, because of that lack of interactivity.

And now hopefully developers who haven’t got the time, the budget or the experience to do this on their own, hopefully they can start offering solutions by just reading the documentation and not having to dig into the weeds of absolutely everything, just implement what’s been written for you, and hopefully that’ll bring WordPress more into the year 2025.

[00:24:36] Milana Cap: Well, I think that if you take from that perspective, like you are 18 years old and have everything, all the apps you want in your phone, I think that WordPress is already weird to them. They are not using CMS, it’s too much effort for the things they can do with another app in their phone.

But I don’t think that WordPress is for them. I mean, WordPress is CMS. So it’s meant to be used with purpose while kids today still look for, you know, quick content that they can, my daughter is 21 years old and she sends me, you know, memes and videos all the time. Most often than not, yeah, I tell her I don’t understand this. And she says, well, it’s funny because it’s stupid. I say, I still don’t understand this.

I mean, she understands the life cycle of something that is meaningful, something that is important. And that is something that we would use WordPress for. But their concentration and focus span is just, give me this stupid video, that’s funny because it’s stupid, and I’ll move on. So I don’t think we should even try to put WordPress there and try to satisfy that request. But still there are requests that Interactivity API does satisfy. And that was needed to be added to WordPress.

[00:26:07] Nathan Wrigley: Yeah, it’s certainly nice for developers not to have to, well just basically roll their own solution and waste tons of time doing something 1,000 times, literally 1,000, maybe 10,000 times done differently. Whereas now everybody can just lean into this one implementation, and it’s baked into Core. And then everybody can inject things into, on top of your code, and you can look at other people’s code and extend it in that way. So hopefully that will mean that, you know, the project as a whole can move forward.

Let’s move on to something that I literally know nothing about, HTML API. You’re going to have to go from the very most basic description and I will try to keep up.

[00:26:46] Milana Cap: Well, HTML API is actually what powers Interactivity API. So we wouldn’t have Interactivity API as it is right now, if we didn’t have HTML API. For now we have two classes that we can use, HTML tag processor. Which is idea to use PHP to modify attributes in Gutenberg blocks, in their markup. Because it was so difficult to approach the block to get to that code and modify anything once it’s on the page.

So the HTML tag processor is just working with the attributes in markup. But it was meant to be used for Gutenberg blocks, but it really doesn’t matter what you use, it’ll process any HTML if it finds it. And it’s very useful for many things that we would use jQuery for before, and we would load the whole JavaScript file. You can add, remove, classes. You can set the aspect ratio for iframe. You can set image size attributes. You can add accessibility attributes where you need them.

And it’s all happening in PHP, you know, on the page load. It’s very fast. It’s amazing. And that’s what is powering those HTML directives that we have in Interactivity API. So in markup you will find data WP and then the rest of directive. And those directives are connecting the server side and the client side in JavaScript for Interactivity API. I think it’s called WP Directive Manager, the class that is really internal class, and it’s just being used by Interactivity API.

But then there’s a class that’s called HTML processor. And this one is doing more things than tag processor. This one knows about the closing tag, and this one will support inserting and removing nodes from the page, or wrapping and unwrapping tags on the page, then reading and modifying inner content. So everything that you were loading JavaScript for, you know, all the makeup stuff, and if something is clicked then, you know, wrap me this paragraph in this div, and then we will change the class or whatever.

You can do that with PHP now, and it feels so much less hacky. You have it. I had actually example for removing the no-follow attribute for internal links. So searching for internal links, before HTML tag processor, you would have to use regex, and regex is invented by extraterrestrials to make fun of humans.

So it’s also, you cannot cover all the cases with regex. There are always surprises. There is always some edge case you didn’t think of and cover. And when you look at that code, even five minutes later, you don’t understand anything. It’s something that you Google, and you trust the code that you found on Google.

But this one, when you used a tag processor, you actually understand everything. And it covers all edge cases. There are no surprises because it’s been built with HTML standards. So it supports every type of HTML that we will probably never see in our lives. You know, all the broken stuff and all of it, it supports it. And it’s been built by Dennis Snell. That is something unlike Interactivity API.

So we saw that Laravel has it, and Symphony has it, and Phoenix first did it. But this is something that nobody has. This is our own. And Dennis now built it from zero, completely custom. And he’s now working in putting it into PHP. So it’ll be available, yeah, to everyone. That’s a really big thing.

I gave this talk in September at PHP Serbia and people were sitting, you know, PHP developers who are working with Symphony and Laravel and doing custom PHP, and they were like, oh my God. And I was like, yeah, WordPress has something you don’t have. That was really nice feeling. Yeah, I like that Dennis is actually putting that into PHP.

[00:31:30] Nathan Wrigley: So again, like I did with the Interactivity API, I’m going to do the same here. Let me just see if I’ve understood what it is. So the idea really, if you want to interact with the DOM, right now, the typical way of doing that is with some JavaScript or other. So let’s say for example, I don’t know, you want to do the third child of a div, and you want to put a border around that.

With JavaScript, you’re going to find that third div, and then you’re going to insert some class, which will then get modified by the CSS to add a border and a border radius, and what have you. So that’s all done on the client side. Page loads, JavaScript loads, and then the DOM gets rewritten by the JavaScript.

But in this scenario, it’s going server side. It is PHP. So it’s really much more readable and maintainable, and it all just lives in this one spot with all the other PHP. And then you would write something, basically the same thing, but in PHP, to do the same job. And then WordPress, so there’s no rewriting of the DOM. WordPress writes the DOM with that in mind. So the output HTML already has that in it. You’re not using JavaScript to rewrite what’s already been written, so it speeds things up as well.

[00:32:39] Milana Cap: Yes, yes. You have less requests because there’s no file that you are requesting. There’s no waiting on, you know, everything to load. And to rewrite it, it’s just going right there.

[00:32:51] Nathan Wrigley: So it’s the same process though. The way that you would do it in JavaScript, you’re now just transferring that into PHP, but the method that you’re using to do it would be the same, you know, search for the third child of this parent div, and then give it an extra class and that’s what happens.

[00:33:04] Milana Cap: Yes.

[00:33:05] Nathan Wrigley: Okay. Yeah, that’s really straightforward. And really, really, really powerful.

[00:33:09] Milana Cap: It is.

[00:33:10] Nathan Wrigley: Because not only can you write your own thing in that way, but if you want to upend what’s already been written by, I don’t know, let’s say there’s something strange in a plugin that you’ve downloaded. Would this be able to rewrite the things that the plugin is injecting?

[00:33:23] Milana Cap: Yes.

[00:33:23] Nathan Wrigley: Okay, so you can, I don’t know, let’s say there’s a plugin which does something quirky in the HTML, you don’t like it, you want to strip something out or add something in. It sits between where the plugin injects its code and where the end user receives the HTML.

[00:33:35] Milana Cap: Yeah.

[00:33:35] Nathan Wrigley: That is interesting. So it’s a total rewrite of the HTML.

[00:33:38] Milana Cap: Mm-hmm.

[00:33:39] Nathan Wrigley: That is fascinating.

[00:33:41] Milana Cap: Yeah, and it’s fast. It’s actually working faster than when you would load JavaScript for that.

[00:33:48] Nathan Wrigley: So in many cases it renders much of the JavaScript, the JavaScript that’s being used to modify the DOM. It completely negates the need for that?

[00:33:59] Milana Cap: Yes.

[00:33:59] Nathan Wrigley: Have you found it easy to learn this?

[00:34:01] Milana Cap: Yeah, yeah. It’s very easy. It’s even easier than Interactivity API. It’s just, you know, you instantiate the class, pass the string to it that you want to, you know, search for tags, and then you have methods. You call the method and loop through the things, or you don’t have to loop, depending what you are looking for. And there is a method, remove attribute, add attribute, remove class. You know, it’s that easy.

[00:34:28] Nathan Wrigley: And, like everything in WordPress, you said earlier, it’s never finished. There’ll always be work done on it. But as of now, we’re recording this late February, 2025, is it pretty complete for all the things that you’ve wished to do? Does it have an answer for that, or is there still work to be done?

[00:34:42] Milana Cap: The HTML processor needs to be optimised, so it’s not completely production ready yet. Tag processor is optimised and ready to use, and we actually used it in 2023. We waited for new release when it was coming into Core. We waited for two weeks and delayed the deployment to get it in to actually, because that example that I used for removing no-follow attribute from internal links, that’s the real world example that we had. And it was really annoying problem that was so easily fixed with five lines of code, once the HTML API got into Core.

[00:35:25] Nathan Wrigley: I obsess about WordPress, like that’s all I think about most days basically, and yet this is somehow completely passed me by. The Interactivity API, somehow that captured my attention. There must have been some press release, or something to explain that this is happening. But the HTML API completely passed me by. I wonder if that’s just my lack of trying hard enough.

[00:35:46] Milana Cap: No, that was actually the case for many people. So for that WordPress release, I was leading the documentation focus. So I know, I wrote the field guide, and I knew that was there. But many people didn’t know.

And that idea behind this new series of talks that I do. So to find these, it’s very good that these things come into Core slowly, like piece by piece. What is ready? What is optimised? But because they are small, people don’t hear about them, because we don’t advertise that. And Interactivity API is, it gets the same treatment as any other Gutenberg feature. Like, oh, it’s flashy, it’s new, come see this.

But HTML API is completely PHP. It actually powers Interactivity API, but nobody knows that. And those were like small pieces getting in, because its purpose was to serve Gutenberg. So it wasn’t really advertised as something you can use for other things. But you know developers, they find ways to use something for different things.

And that’s why I wanted to create these talks to actually show people there are so many things you can do with WordPress now that are new. And you can use them today, and tomorrow they will be even better.

[00:37:14] Nathan Wrigley: I guess with the Interactivity API you are solving a really hard problem. So to be able to modify one part of the page, it’s content and it’s a separate block, that’s a difficult thing to overcome. So there’s a lot of work to get over that. But if you just want to add a border to the third child of a div, everybody’s using the same JavaScript technique to do it. So there’s a well understood way of doing it.

And so that, I suppose, leads to the question, what is the benefit over just using JavaScript? Why would we want to use the HTML API instead of just the familiar thing, which probably everybody’s doing, you know, just rewrite things with JavaScript. Is it basically coming down to ease of readability for everybody, and speed?

[00:37:57] Milana Cap: Yeah. I think if you take a look at, for example, enterprise projects. The way developers optimise the code, it’s like every piece of millisecond counts because these projects are huge, and they have a lot of visits. So if you can remove all the JavaScript, I mean, that’s huge. That is making such impact, and it brings you like 10 places before your competition. Doing just that is enough to use this over JavaScript.

But also, it replaces not just need for JavaScript, but need for regex as well. And again, in enterprise projects, when you have huge databases running regex and having potential to not work everywhere where it’s supposed to work, as opposed to this, that is very straightforward. Not too many lines of code, and it’s actually faster. You would take that chance.

[00:39:03] Nathan Wrigley: Yeah, I guess if you’ve just got like a five page brochure website, that’s for a mom and pop store, you’re probably not going to be worrying too much. But if you’ve got an enterprise page, you know, an enterprise level website which is maybe getting, I don’t know, 50,000 hits every hour or something like that. Shaving 10 milliseconds out, multiply that by 50,000, I mean, not only is it quicker, so Google likes it, but also the cost of everything goes down. You know, there’s less bits flying across the internet. It’s all been optimised. And I guess at the enterprise level, all of those things matter.

[00:39:36] Milana Cap: Yeah, everything matters.

[00:39:37] Nathan Wrigley: Yeah, that’s fascinating, genuinely fascinating, and something that I’d never heard of. So I will go and, when I’ve edited this podcast, I’ll go and preach the gospel of the HTML and Interactivity APIs. That’s everything I wanted to ask. Milana, is there anything that you wanted to get across that I didn’t ask?

[00:39:53] Milana Cap: No.

[00:39:54] Nathan Wrigley: No. In that case, Milana Cap, thank you very much for chatting to me today. Really appreciate it. I hope you enjoy the rest of your time in Manila.

[00:40:01] Milana Cap: Yeah, thank you for having me.

[00:40:03] Nathan Wrigley: You’re very welcome.