WordCamp Asia 2026 Hardik Thakkar Parsing HTML Without Pain

WordCamp Asia 2026: Hardik Thakkar "Parsing HTML Without Pain" ![rw-book-cover](https://img.youtube.com/vi/eBqdVaHChCo/maxresdefault.jpg) 🔗 **Source:** [WordCamp Asia 2026: Hardik Thakkar "Parsing HTML Without Pain"](https://www.youtube.com/watch?v=eBqdVaHChCo) > [!note]+ Document Notes > tags: #wordpress #html-api #web-performance #security #accessibility > author: Hardik Thakkar > source: WordCamp Asia 2026 > reference: https://www.youtube.com/watch?v=eBqdVaHChCo > date created: 2024-12-30 15:30 > > # 🏷️ Title: Parsing HTML Without Pain >  ## 🧰 Action Inbox - [H1] Migrate from regex to WordPress HTML API for HTML parsing — performance and security benefits #wordpress - [H2] Implement image lazy loading using Tag Processor class — better core web vitals #web-performance - [H3] Add privacy-compliant YouTube embeds with HTML API — GDPR compliance #security ## 🧭 Table of Contents - [[#📝 Summary]] - [[#📖 Main Content]] - [[#🗒️ Notes]] - [[#📚 References]] - [[#🗣️ Paraphrase]] - [[#📰 Newsletter]] - [[#✅ Action Items]] - [[#🧪 Hypotheses]] - [[#📊 Methodology]] - [[#❓ Questions]] - [[#🔮 Future Research]] - [[#💡 Implications]] - [[#🧠 Learning Styles Assessment]] - [[#📊 Accessibility Assessment]] - [[#🌍 DEIB Assessment]] - [[#✅ Logical Validity]] - [[#🛡️ DARVO Analysis]] - [[#🎯 Conclusion]] ### 🔗 References - [WordPress HTML API Documentation](https://developer.wordpress.org/) - [WordCamp Asia 2026](https://asia.wordcamp.org/) ## 📝 Summary - Hardik Thakkar presents WordPress HTML API as a superior alternative to regex for HTML parsing and manipulation - The API includes Tag Processor (6.2+) for attribute manipulation and HTML Processor (6.4+) for structure-aware parsing - Key benefits include memory efficiency, HTML compliance, security, and readability compared to regex or DOMDocument - Real-world examples demonstrate performance optimization, privacy compliance, and accessibility improvements - Currently has limitations but extensive roadmap for CSS selectors, node insertion, and broader HTML support ## 📖 Main Content WordPress developers frequently need to parse and modify HTML for tasks like adding attributes, modifying images, or importing content. Traditional approaches using regular expressions are fragile and create edge cases, while PHP's DOMDocument is memory-intensive and adds unwanted alterations. The WordPress HTML API, introduced in core since 6.2, provides a built-in, spec-compliant solution that's both memory-efficient and secure by default. The API offers two main classes: Tag Processor for basic attribute manipulation and HTML Processor for structure-aware parsing with parent-child relationship understanding. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/eBqdVaHChCo?t=0) — [H1] Introduction and Problem Statement - Key idea: HTML parsing is a common WordPress developer challenge often solved incorrectly with regex - Evidence: "Whether you are adding attributes to links, modifying images, modifying blog output, or importing content, you might have come across this" #### ⏱️ [02:15](https://youtu.be/eBqdVaHChCo?t=135) — [H2] The Iceberg Problem with Simple HTML Tasks - Key idea: Simple tasks like adding lazy loading reveal complex edge cases beneath the surface - Evidence: "What if the image already has attribute? What if there is a greater than sign in the alt tag?" #### ⏱️ [03:30](https://youtu.be/eBqdVaHChCo?t=210) — [H2] Why Regex Fails for HTML - Key idea: Regular expressions create more problems than they solve for HTML manipulation - Evidence: "If you have a problem and we decide to use regular expression for it, now we have two problems" #### ⏱️ [05:45](https://youtu.be/eBqdVaHChCo?t=345) — [H3] Limitations of DOMDocument - Key idea: PHP's native DOMDocument is memory-intensive and adds unwanted HTML alterations - Evidence: "We are just passing a simple P tag, but after initializing the DOM document, it is adding unnecessary HTML" #### ⏱️ [07:00](https://youtu.be/eBqdVaHChCo?t=420) — [H1] WordPress HTML API Introduction - Key idea: WordPress provides a built-in, spec-compliant solution for HTML manipulation - Evidence: "It's part of WordPress core since 6.2. It is built on same HTML specs that the modern browsers like Chrome, Firefox, and Safari uses" #### ⏱️ [08:30](https://youtu.be/eBqdVaHChCo?t=510) — [H2] Tag Processor vs HTML Processor Classes - Key idea: Two core classes serve different needs - basic attribute manipulation vs structure-aware parsing - Evidence: "Tag processor class is used to add attributes and classes. HTML processor class is structure aware with parent, child nesting information" #### ⏱️ [11:15](https://youtu.be/eBqdVaHChCo?t=675) — [H2] Tag Processor API Methods and Workflow - Key idea: Linear scanning with methods for navigation, attribute manipulation, and HTML retrieval - Evidence: "next_tag method will put your pointer to that particular tag. Then get_attribute, set_attributes methods" #### ⏱️ [14:00](https://youtu.be/eBqdVaHChCo?t=840) — [H3] Bookmarks for Forward References - Key idea: Bookmarks solve cases where later document information affects earlier tag decisions - Evidence: "Sometimes we need information from later in the document to make a decision about an earlier tag" #### ⏱️ [16:30](https://youtu.be/eBqdVaHChCo?t=990) — [H2] HTML Processor for Structure Awareness - Key idea: HTML Processor understands parent-child relationships that Tag Processor cannot detect - Evidence: "HTML processor understand the parent-child relationship and nesting. It can handle malformed HTML as well" #### ⏱️ [18:45](https://youtu.be/eBqdVaHChCo?t=1125) — [H2] Integration with WordPress Hooks - Key idea: HTML API works seamlessly with existing WordPress filter hooks - Evidence: "the_content hook, render_block hook, and output buffering that will allow us to modify the full output" #### ⏱️ [20:00](https://youtu.be/eBqdVaHChCo?t=1200) — [H1] Performance Optimization Example - Key idea: Automatically add performance attributes to images for Core Web Vitals improvement - Evidence: "For the first image, we will set attribute with fetch priority high. For the rest of the image, we will add loading lazy and decoding attributes" #### ⏱️ [23:15](https://youtu.be/eBqdVaHChCo?t=1395) — [H1] Privacy Compliance with YouTube Embeds - Key idea: Convert YouTube embeds to privacy-friendly domains for GDPR compliance - Evidence: "YouTube suggests that we use a privacy-friendly URL like youtube-nocookie.com instead of youtube.com" #### ⏱️ [25:30](https://youtu.be/eBqdVaHChCo?t=1530) — [H2] Content Security Policy Implementation - Key idea: Add nonce attributes to inline scripts and styles for CSP compliance - Evidence: "All the inline script tags and style tags will be blocked unless we have provided a nonce value" #### ⏱️ [28:00](https://youtu.be/eBqdVaHChCo?t=1680) — [H2] Interactivity API Integration - Key idea: HTML API enables server-side directive addition for WordPress Interactivity API - Evidence: "For the interactivity API to work, we need to add certain directives to the HTML structure" #### ⏱️ [31:45](https://youtu.be/eBqdVaHChCo?t=1905) — [H2] Current Limitations and Future Roadmap - Key idea: API has current restrictions but extensive planned improvements - Evidence: "Cannot insert new nodes, cannot wrap existing elements, bookmark limits are restrictive. Future: CSS selector support, ability to fully modify tags" ## 📚 References - [WordPress HTML API Documentation](https://developer.wordpress.org/) - [Learn WordPress](https://learn.wordpress.org/) - [WordCamp Asia](https://asia.wordcamp.org/) ## 🗣️ Paraphrase - WordPress HTML API provides a safe, efficient alternative to regex and DOMDocument for HTML manipulation tasks - The API offers two classes: Tag Processor for simple attribute work and HTML Processor for structure-aware parsing - Real-world applications include performance optimization, privacy compliance, security headers, and accessibility improvements ## 📰 Newsletter 🚀 **WordPress HTML API: The End of Regex Pain** WordPress developers, stop wrestling with fragile regex patterns! Since WordPress 6.2, we've had a powerful built-in solution for HTML manipulation that's memory-efficient, spec-compliant, and actually readable. **Key Benefits:** - **Tag Processor**: Perfect for adding attributes like lazy loading to images - **HTML Processor**: Structure-aware parsing for complex DOM relationships - **Production Ready**: Already used extensively in WordPress core **Practical Applications:** - Automatic performance attributes for Core Web Vitals - GDPR-compliant YouTube embeds - Content Security Policy nonce injection - Accessibility attribute automation The API works seamlessly with existing WordPress hooks and eliminates the edge cases that make regex unreliable for HTML. Resources: [Learn WordPress](https://learn.wordpress.org/), [Developer Docs](https://developer.wordpress.org/), [WP-CLI](https://wp-cli.org/) ## ✅ Action Items #### WordPress - **Core**: Promote HTML API adoption in developer documentation and best practices guides - **Training**: Create comprehensive lesson plans covering Tag Processor and HTML Processor usage patterns - **Documentation**: Expand DevHub examples with real-world use cases like performance optimization - **Community**: Develop workshop materials for WordCamps focusing on migration from regex to HTML API #### DevRel - **Developer advocacy**: Create conference talks demonstrating HTML API benefits over regex approaches - **Education**: Develop video tutorials showing step-by-step migration from regex to HTML API - **Developer experience**: Improve HTML API documentation with more practical examples and edge case handling - **Community management**: Moderate discussions about HTML parsing best practices in WordPress forums ## 🧪 Hypotheses - WordPress sites using HTML API for image optimization will show measurable Core Web Vitals improvements compared to regex-based solutions - Developers switching from regex to HTML API will experience reduced bug reports related to HTML parsing edge cases - Memory usage will decrease significantly when replacing DOMDocument with HTML API for simple attribute manipulation tasks - Developer productivity will increase with HTML API due to improved code readability and maintenance ### 📊 Methodology - A/B testing websites with regex vs HTML API implementations measuring Core Web Vitals scores - Bug tracking analysis comparing edge case failures between regex and HTML API approaches - Memory profiling WordPress sites before and after HTML API migration - Developer survey measuring code review time and debugging effort between approaches ### ❓ Questions - How does HTML API performance compare to regex for large-scale HTML processing tasks? - What migration path should be recommended for sites heavily dependent on regex HTML manipulation? - How can the bookmark limitations be worked around for complex multi-pass processing scenarios? ### 🔮 Future Research - Impact analysis of upcoming CSS selector support on WordPress development patterns - Performance benchmarking of HTML API vs browser-based manipulation for interactive features - Integration possibilities between HTML API and emerging WordPress block development workflows ### 💡 Implications - **Practice**: Fundamental shift needed in WordPress development education away from regex for HTML - **Security**: Reduced XSS vulnerabilities through spec-compliant HTML parsing and nonce injection - **Performance**: Significant memory usage improvements and Core Web Vitals optimization opportunities - **Education**: Developer training curricula must include HTML API as standard WordPress development practice ### 🧠 Learning Styles Assessment Reading level estimate: 12th Grade (Technical presentation with code examples) #### 👀 Visual learners - Present: Code comparison slides showing regex vs HTML API syntax differences - Improve: Architecture diagrams showing Tag Processor vs HTML Processor workflows #### 🔊 Aural learners - Present: Live presentation with verbal explanations of code examples - Improve: Audio walkthrough of API method chains and processing flow #### 🗣️ Verbal learners - Present: Clear analogies like "bookmark as pin on map" and technical term definitions - Improve: More real-world metaphors for DOM traversal and HTML parsing concepts #### 🧩 Kinesthetic learners - Present: Multiple hands-on code examples with immediate before/after results - Improve: Interactive coding exercises and live debugging sessions #### 🧠 Logical learners - Present: Clear problem-solution structure with systematic API method progression - Improve: Decision trees for choosing Tag Processor vs HTML Processor #### 🧑‍🤝‍🧑 Social learners - Present: WordCamp presentation format encouraging community learning - Improve: Group coding exercises and peer review of HTML API implementations #### 🧘‍♀️ Solitary learners - Present: Comprehensive examples suitable for independent study and practice - Improve: Self-paced tutorial materials with progressive difficulty levels #### 🌿 Naturalistic learners - Present: Ecosystem thinking about WordPress core integration and hook compatibility - Improve: Environmental impact discussion of memory efficiency benefits ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading structure and code block organization - Improve: More descriptive alt text for code comparison screenshots #### Keyboard navigation - Present: Standard presentation format with logical flow - Improve: Interactive code examples need keyboard accessibility #### Contrast and readability - Present: Standard conference presentation contrast levels - Improve: Code syntax highlighting optimization for low vision users #### Media and captions - Present: Live presentation with clear verbal explanations - Improve: Automated captions and downloadable transcript needed #### Forms and interactions - Present: No interactive forms in presentation - Improve: Any future interactive demos need accessibility review ### 🌍 DEIB Assessment #### Cultural breadth - Present: Technical content with universal WordPress development applications - Improve: Examples could include international sites and multilingual considerations #### Inclusive language - Present: Professional technical language avoiding jargon where possible - Improve: Define more technical terms for developers at different experience levels #### Neurodiversity support - Present: Well-structured content with clear examples and consistent formatting - Improve: Provide summary checklists and step-by-step guides #### Representation - Present: Technical focus on code rather than personal examples - Improve: Include diverse use cases from different types of WordPress sites #### Psychological safety - Present: Non-judgmental tone about past regex usage - Improve: More explicit encouragement for developers transitioning approaches ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Strong logical progression from problem identification to solution implementation - Inductive strength: Good use of specific examples to demonstrate general principles - Causal reasoning: Clear cause-effect relationships between regex problems and HTML API benefits - Analogical strength: Effective analogies like iceberg metaphor for hidden complexity #### Fallacies - Appeal to novelty: Minor tendency to favor newer API simply because it's newer - addressed by focusing on concrete benefits - False dichotomy: Presentation could acknowledge legitimate regex use cases outside HTML parsing #### Tone of voice - Overall tone: Professional, educational, and encouraging with technical authority ### 🛡️ DARVO Analysis - Deny: No denial patterns present - acknowledges regex limitations fairly - Attack: No attacks on alternative approaches - constructive criticism of tools - Reverse victim/offender: Not applicable to technical content - Emotional cues: Positive, solution-oriented presentation without manipulation ## 🎯 Conclusion The WordPress HTML API represents a significant advancement in WordPress development practices, offering a spec-compliant, memory-efficient alternative to regex and DOMDocument for HTML manipulation. Developers should prioritize migrating existing regex-based HTML parsing to this built-in solution, which provides better security, performance, and maintainability. The API's integration with WordPress hooks and production-ready status make it an immediate practical improvement for WordPress sites requiring HTML manipulation for performance, privacy, security, or accessibility enhancements. ## 🧱 Refactor Appendix ### 📚 Literature Split Pad Purpose: Stage CEE units that become Literature notes. Split level: H3 ### [H1] WordPress HTML API provides spec-compliant HTML parsing > [!quote] [Parsing HTML Without Pain](https://www.youtube.com/watch?v=eBqdVa --- ## Full Transcript [00:04] Hello everyone. [00:06] Good afternoon. [00:08] Uh my name is Hardik Thakkar. [00:10] Uh I have been working with WordPress [00:12] for almost a decade now and for the last [00:14] 8 years I've been part of Multidots as a [00:16] senior WordPress engineer. [00:18] Uh today we are going to talk about [00:20] something that every WordPress developer [00:23] has came across. [00:24] It is like parsing parsing and modifying [00:27] HTML. [00:28] So whether you are adding attributes to [00:32] uh links, modifying images, modifying [00:34] blog output, [00:36] uh [00:37] or importing content, you might have [00:39] come [00:40] across this. And if you are like me, you [00:42] probably have used uh regular expression [00:45] for it. And if you are like me, you [00:47] probably have regretted it. [00:49] So after this session, [00:52] uh you will have a better, safer, and [00:53] faster way to handle all of this. [00:56] All right, let's get into it. [00:59] So let's start with something simple [01:01] like adding [01:02] uh loading [01:04] uh lazy attribute to all the images of [01:06] in your WordPress site. [01:08] Okay, so on the surface, it looks like a [01:11] very tiny harmless request. [01:14] Uh it's just a single uh simple string [01:16] replacement. What could possibly go [01:18] wrong, right? So on the surface it it [01:21] looks like this iceberg. But if you [01:25] uh [01:25] take a deeper look, you will find many [01:27] edge cases. Like what if the image [01:29] already has attribute? What if there is [01:31] a greater than sign in the alt tag? What [01:34] if the image tag is inside [01:36] uh [01:36] another tag like picture or figure? So [01:39] there are these uh edge cases which [01:42] could come up if you take a deeper look. [01:45] And uh [01:47] this is just for the image tag. So if [01:48] you want to modify multiple tags like [01:51] this, [01:52] uh it could be very tricky. [01:54] And uh this in reality looks like this [01:56] iceberg. So in these cases what what do [02:00] we usually go with? So we usually uh go [02:05] with regular expression as a first [02:06] solution. [02:07] Uh I'm not actually here to bash regex, [02:11] uh [02:11] but we all we all have been there, [02:13] right? So if you have if we have a [02:16] problem and we decide to use regular [02:18] expression for it, now we have two [02:19] problems. It's a classic regex meme. [02:22] So the thing is uh regular expression is [02:25] not a a bad tool. It it it actually is [02:28] not a right tool for this job. [02:31] And uh [02:32] let's see what regular expressions are [02:34] good for. [02:37] So it is good for validating our input [02:39] with patterns. Then it is helpful us to [02:43] uh find patterns in large files. Then [02:46] for string manipulation, it is very [02:48] useful. But on the other hand, there are [02:51] some places where it is extremely [02:53] challenging to work with them. So it has [02:55] a steep learning curve. It is very [02:57] fragile and extremely hard to read and [02:59] extend. [03:01] Uh it it is uh [03:03] HTML is nested while regex is built to [03:06] be read flat strings. [03:08] Uh it doesn't have any concept of [03:10] parent, child, or any kind of [03:12] relationship. [03:13] And the last is unexpected edge cases. [03:16] So what I call is context blindness. It [03:18] doesn't have any context of the HTML [03:20] uh [03:21] that it we pass to it. [03:23] Uh if if we pass if if the tag has [03:26] greater than sign in it, it will think [03:28] that the tag is ending there. [03:30] So it is very uh unexpected. [03:33] So here is a simple regular expression [03:36] for the case that we saw in the iceberg [03:39] image. So here I have tried to covered [03:41] almost all cases, but you can see like [03:44] how big the regex has become. And it [03:47] will still break on certain edge cases. [03:51] Now you might be thinking like we PHP [03:54] has already native DOM document class. [03:57] So we why can't we use that? We can, but [03:59] it is not uh quite close. [04:01] So first of all, it's built on legacy [04:04] architecture. [04:05] Uh modern HTML is built on HTML5 tags. [04:08] So if you pass any unfamiliar [04:11] attributes, it might throw an error. [04:14] Uh other than that, uh DOM document [04:16] loads entire document into memory. So it [04:19] is memory intensive. And because [04:23] it is uh adding so much into the memory, [04:26] uh we might have unwanted alternation. [04:29] So it it might add additional uh HTML. [04:33] So you can see here like we are just [04:35] passing a simple P tag, but after uh [04:37] initializing the DOM document, it is [04:39] adding unnecessary HTML. [04:43] So [04:44] uh regex is fragile, DOM document is [04:46] very heavy. So what do we actually use [04:48] here? What if I tell you that WordPress [04:51] already has a built-in solution for [04:52] this? We don't need any external [04:55] libraries or dependencies. [04:58] The answer is WordPress HTML API. [05:00] Uh it's part of WordPress core since [05:02] 6.2. [05:04] Uh it is built on same what we HTML [05:06] specs that the modern browsers like [05:09] Chrome, Firefox, and Safari uses. [05:11] It is HTML aware, not string aware, [05:13] unlike regex. So it knows like what tag [05:16] is. [05:17] So it can uh [05:19] it can differentiate between an IMG tag [05:22] and I and IMG word in the string. [05:25] Right? It uses single pass scanning. It [05:27] will scan each tag by tag. And that's [05:30] why it's very memory efficient. It is [05:32] extremely readable compared to regular [05:34] expression and it is secure by default. [05:36] And since it is a part of WordPress, it [05:38] will [05:40] be we can use it with WordPress hook. [05:43] So [05:44] uh [05:45] the WordPress HTML API is con- mainly [05:48] built on two core engine class. [05:51] First is the tag processor class. [05:53] It is used to add attributes and classes [05:56] to [05:57] uh HTML tags. It was introduced first in [05:59] WordPress 6.2. And the other is the HTML [06:02] processor class, [06:04] which is an advanced level of tag [06:06] processor. It is structure aware. It has [06:09] all the information about parent, child [06:11] nesting, and everything. It is it was [06:13] introduced in 6.4 6.4. Now we'll take a [06:16] look at both the class in detail [06:17] starting with the HTML tag processor. So [06:21] as I mentioned, it it scans every tag [06:25] one by one in a linear fashion. [06:27] So it doesn't uh build our HTML document [06:31] in the DOM in a tree manner unlike the [06:33] DOM document class. [06:35] And that's why it is extremely memory [06:37] efficient. There is no memory overhead [06:39] there. [06:40] Uh it has tag awareness. Unlike unlike [06:43] regex, it can differentiate between tags [06:46] like where the tag is starting, when the [06:48] tag is ending. [06:49] Then it provides query matching. So we [06:51] don't need to go each tag one by one. We [06:54] can just directly give them a tag name, [06:56] it will jump to that tag immediately. [06:59] And unlike regex, it is non [07:02] non-destructive. So it will not break [07:04] our HTML if something goes wrong. [07:07] Right? So the tag processor uh API [07:10] provides certain methods. So starting [07:12] with the next tag method, we we will use [07:15] mostly this method for almost all over [07:19] uh use cases. So next tag uh method will [07:22] basically put your put the pointer to [07:25] that particular tag. So here if we are [07:28] passing the IMG tag, it will put [07:31] uh I it will find the next IMG tag and [07:33] put the pointer there. [07:35] Right? Then once the pointer is on that [07:37] tag, we will have additional method like [07:39] get attribute, set attributes, where we [07:42] can get the attribute value or we can [07:44] set these attribute values. Then we also [07:47] have some additional methods for adding [07:49] and removing class. [07:51] So [07:52] these all methods will make sure that [07:55] they don't break anything. Plus they [07:56] will also handle all the edge cases that [07:58] we saw in the first [08:00] tag first slide. [08:02] Then we have some additional method like [08:04] get tag, which will uh tell us the [08:07] current tag that we are on. And once [08:11] all the modifications are done, we will [08:14] be able to get the updated HTML [08:19] Now let's see how the [08:21] tag processor [08:23] uh works. So we have a simple div. [08:26] And inside that div we have IMG tag and [08:29] a P tag. So when we start the processor, [08:33] we will first use the next tag next tag [08:35] function. So it will put the first [08:38] pointer on the first tag it find, which [08:40] is div. [08:41] Then [08:42] on the next iteration, it will get the [08:44] next tag, which is IMG tag. [08:47] And then it will move the [08:49] uh iteration to the P tag. Now while we [08:52] are at these tags, we will be able to [08:54] use this set attribute, get attribute [08:56] method, and all the other methods. [08:58] And once it completes all the HTML tags, [09:01] it will return false so that we can know [09:03] that now there are no uh any more tags. [09:06] Right? [09:07] So now let's look at uh real comparison [09:09] here. [09:10] Uh so remember our iceberg case? So this [09:14] is the uh regex pattern for this. [09:17] And you can see like how complicated [09:19] this is to read and to write. [09:22] And now let's look at the same example [09:25] with WordPress HTML way. [09:27] So with WordPress HTML tag processor, we [09:30] only need to initialize the class and we [09:32] need to ask that to move the to the next [09:35] image tag. And once we have that, we [09:37] will set attributes [09:39] uh as per our requirements. And then we [09:41] just return the updated HTML. So you can [09:43] see side by side how easy and readable [09:46] the HTML uh API is. So even if some new [09:51] developer joins the team, it can easily [09:53] pick and work on it. [09:57] Now [09:58] uh as I mentioned HTML tag processor [10:01] moves tag by tag in a linear forward [10:04] way, but sometimes we need information [10:07] from later in the document to make a [10:09] decision about an earlier tag. A classic [10:11] example is like we have a UL tag and [10:14] inside this UL tag we have a bunch of [10:16] bunch of LI tags. And if you want to [10:19] count how many LIs are there and add a [10:23] data count attribute to UL. So, if we go [10:26] in the in this linear fashion, we will [10:28] not get the count at the initial stage. [10:30] Right, we have to go through each LI tag [10:32] first and then we will be we'll be able [10:34] to get the count. So, this is where the [10:36] bookmarks come. [10:38] Uh this solves this uh [10:40] issue. So, think of it like uh dropping [10:43] a uh pin on a map. So, at [10:48] So, in this code we can see that we are [10:50] first at the UL tag. We will set a [10:52] bookmark there with the set bookmark [10:54] method. And then we will move forward [10:56] with the all the LI tags. [10:58] And once once we have once we have the [11:01] LI tag, we will again go to that [11:03] bookmark [11:05] uh which is UL tag and then we will set [11:07] the attributes there. [11:08] And once the bookmark uh is completed, [11:11] we will have to call the release [11:12] bookmarks method to [11:14] free up free up that space. [11:16] And bookmarks [11:18] doesn't add any memory overhead. They [11:19] are just a memory location in the [11:23] uh in the memory. [11:26] Right? [11:26] So, [11:28] now we have complete picture of the tag [11:30] processor. It scans forward. [11:33] It add attribute and classes. But, [11:36] uh [11:37] there is still one thing that it cannot [11:39] detect. It cannot detect nesting. It [11:42] cannot tell if a if a tag is a parent [11:44] tag or a child tag. [11:46] Right? For it for it uh all tags are [11:48] identical. [11:50] Um let's look at this uh let's take a [11:53] look at this example [11:55] where we have a P tag inside a [11:56] blockquote and there is also an [11:58] additional P tag which is the direct [12:01] child of the document. And if you want [12:03] to target this second P tag and if you [12:05] use the tag uh processor API, [12:08] uh we will not be able to do this [12:09] because it will find the first [12:11] P tag which is inside the blockquote [12:14] as the first tag. [12:16] So, if you want to solve this uh issue, [12:19] we will need some uh tool that can [12:21] detect uh nesting and the position of [12:24] the tags. So, this is where our second [12:27] uh API come into picture which is the [12:29] HTML processor. [12:31] So, HTML processor understand the [12:33] parent-child relationship and nesting. [12:36] It can handle malformed HTML as well and [12:39] it is extending the tag processor API. [12:41] So, all the methods that we have seen so [12:43] far will work with the HTML processor as [12:47] well. [12:48] So, if you look at in the code for HTML [12:50] processor, we need to use the create [12:52] fragment method because we are only [12:55] processing chunk of HTML and we will use [12:57] the same next tag methods to move [13:00] forward to the [13:01] P tags. [13:02] Right? Here then we will use the get [13:04] breadcrumb method to [13:07] list the full DOM path of that element. [13:12] So, [13:13] you can see in the output that we have [13:15] a full nested path and there is this [13:17] direct child. So, using this HTML [13:19] processor, we'll be able to find the [13:21] direct child. [13:24] Okay, now how do we decide which one to [13:26] use? So, it is actually very simpler. [13:28] So, if we only need to modify attributes [13:31] or classes, then we will use the tag [13:33] processor, but if we need structure [13:35] awareness, [13:36] like if we want to see where the tag is [13:39] placed, then we will use the [13:41] HTML processor. [13:43] So, it is like what versus where. That's [13:45] the decision that we need to make. [13:48] Now, [13:49] uh before we jump on to the examples, [13:52] let's see how we can use the HTML API. [13:55] Like how where do we actually put this [13:57] all this code? [13:58] So, [13:59] you might all be aware of this hooks [14:02] that WordPress provides. These are [14:04] uh pretty standard hooks that we already [14:06] use in everyday. [14:08] So, like the the content hook which will [14:10] allow us to modify the content and the [14:12] render block hook and the output [14:15] buffering that will allow us to modify [14:17] the full output of the page. [14:19] Right? And there is this widget text [14:21] which is for legacy. And there are some [14:23] additional hooks as well that we can use [14:25] uh [14:26] to implement the HTML API. [14:29] All right. So, [14:31] uh now now that we are familiar with the [14:33] HTML API, let's see some real world [14:35] examples. [14:37] So, first up is the performance example. [14:40] So, this is the most probably very [14:42] common request that you will get. So, [14:44] imagine you have a site with thousands [14:46] of images and [14:49] those images don't have any performance [14:51] attribute like fetch priority or loading [14:54] lazy or decoding. [14:56] So, that will hurt your hurt the core [14:58] web vitals of the site. So, we cannot go [15:01] into the admin and [15:03] edit each post. That will be not [15:06] feasible. And we cannot even use regex [15:08] here because we will not be able to [15:10] determine whether the image is a first [15:12] image or [15:14] uh it's a lower image. Right? So, in [15:16] this case, how we can use HTML API to [15:19] simplify this? [15:22] So, this is the [15:24] uh code for that. So, we'll start with [15:25] the the content filter. It will provide [15:27] us the HTML for the page. Then we will [15:30] initialize the tag processor class. [15:32] Right? Then we will use the next tag [15:34] method to move to the image tag. And if [15:38] it's the first image, we will set [15:39] attribute [15:41] with fetch priority high. And for the [15:43] rest of the image, we will add loading [15:45] lazy and decoding attributes. And once [15:48] this is done, we will return the updated [15:51] HTML with this method. Right? So, [15:54] initially we had this kind of uh image [15:57] tags and after applying the HTML API, we [16:00] will have the [16:01] uh necessary tags added. So, you can see [16:03] how simply we can do we can this and [16:06] achieve this requirement using the HTML [16:09] tag processor. [16:12] Now, next example is [16:13] privacy compliance. So, imagine that [16:16] your site editors put a YouTube link in [16:19] the content. Now, WordPress will [16:21] uh [16:22] turn this into an embed link and it will [16:25] uh create an iframe and that iframe will [16:27] put additional tracking cookies on the [16:29] front end every time the user loads the [16:31] page. And even if user has not accepted [16:34] the cookies. So, this is a clear GDPR [16:36] violation and uh the simpler fix for [16:39] this is that YouTube suggests that we [16:42] use a privacy-friendly URL like [16:44] youtube-nocookie.com [16:46] instead of youtube.com. [16:48] Right? And we also uh add some loading [16:52] performance uh attributes as well. So, [16:54] let's see how we can do this with HTML [16:56] API. So, we will again use the the [16:59] content filter that will provide us the [17:01] HTML. We will initialize the class [17:04] and instead of uh the image tag now, we [17:06] will we are after the iframe tag. So, [17:09] we will find the iframe tag. We will [17:11] check if it's a youtube.com domain and [17:14] we will replace it with [17:15] youtube-nocookies.com and we will return [17:18] the HTML. [17:20] So, [17:21] now earlier what was a simple iframe, [17:23] now it will be have the updated [17:26] privacy-friendly domain and as well as [17:28] some performance attributes as well. [17:31] Right? Next example is about the content [17:34] security policy error. So, this is very [17:37] uh important security header for our [17:40] site. It provides [17:42] uh [17:43] uh it protects our site from the [17:45] cross-site scripting attacks on our [17:47] site. And we actually have a dedicated [17:49] session on this, so I highly recommend [17:51] that you all attend that and learn more [17:53] about how to implement the content [17:55] security policy. [17:57] So, uh as per the content security [17:59] policy, [18:00] all the inline script tags and style [18:02] tags will be blocked unless we have [18:05] provided a nonce value. [18:07] Right? So, [18:09] to do this or to achieve this, how we [18:12] can use the HTML API to achieve this. [18:15] So, we will initially [18:17] create the nonce first, then we will use [18:20] the template redirect hook here because [18:22] we want to target the whole uh HTML of [18:25] the page, then we will use the output [18:27] buffering and then is the same similar [18:31] step that we are seeing. First, [18:32] initialize the tag processor class, then [18:35] we will move forward with script tags, [18:37] style tags and adding nonce attributes [18:40] to [18:40] those. [18:42] Once that is done, we will use the [18:44] standard WP headers filter to send the [18:47] content security policy [18:49] header. [18:50] Right? [18:53] Right? So, before uh this, our HTML [18:56] markup was looking like this. [18:59] And after applying these changes, we now [19:01] have the nonce attributes [19:03] uh present on the [19:05] inline script and style tags. [19:11] Okay. Now, next is the [19:14] uh [19:16] example of real world example of the [19:18] interactivity API. So, interactive API [19:20] is like future of WordPress front end. [19:23] And this is where this is the place [19:25] where both the APIs meet. So, let's say [19:28] that uh client wants to [19:30] have certain buttons on the site to open [19:33] model pop-up instead of navigating to [19:36] the particular page. Now, we can [19:38] uh do this via custom block, but that [19:41] will add some additional scaffolding and [19:44] code and overhead. Right? So, instead of [19:46] that, [19:48] we can use the interactivity API to make [19:51] the links open the model pop-up instead [19:54] of navigating to their individual pages. [19:56] Right? [19:57] So, now for the interactivity API to [20:00] work, we need to add certain directives [20:02] to the HTML structure. So, let's say we [20:05] have this HTML button core button block [20:08] and we want to open a model pop-up for [20:10] this. [20:12] And for the interactivity API, we need [20:15] to add this [20:17] uh directives. [20:20] So, to do this, we will target the core [20:22] button block with this render block [20:25] filter. [20:26] Again, we will initialize the same tag [20:28] processor class. We will target the [20:30] anchor tag [20:31] and we will add the attributes like data [20:35] WP on click and action model. [20:39] Now, [20:40] to target the parent div, we will again [20:42] initialize the processor and we will set [20:45] attributes there. [20:46] Now, [20:47] uh [20:48] we will still need some additional [20:50] JavaScript to uh register the [20:54] interactivity API store and the actual [20:57] action that will open the model. But, [21:00] the HTML [clears throat] wiring that is [21:03] done on the server side is totally [21:05] handled by the HTML API. [21:08] We can also do this [21:10] uh with the vanilla JavaScript approach, [21:13] but that is for the single button and [21:15] model. So, that's fine. But, like if you [21:18] want to use the interactivity API that [21:19] will give some additional benefits like [21:21] if we have a shared state between [21:23] multiple blocks and we have progressive [21:26] enhancement. So, this is where the HTML [21:28] API useful in within the interactivity [21:31] API. [21:32] And even on the WordPress core, uh the [21:35] HTML API extensively used for the [21:38] interactivity API. [21:42] Now, next is the [21:44] uh [21:45] context aware lead paragraph styling [21:46] example. So, this is again the classic [21:49] uh requirement from the editor. Like for [21:51] example, they want to [21:52] uh make the first [21:54] uh [21:56] paragraph [21:57] a bit larger. So, we we can achieve that [21:59] by adding a CSS class to the first [22:02] tag, but in that case, we will need uh [22:05] additional details like where the P tag [22:07] is currently residing. So, if we use [22:10] regular expression, we already know that [22:12] it is very complicated. Now, if we use [22:15] the tag processor, this could even cause [22:18] some issues [22:19] with this HTML. Like this is a similar [22:22] example that we saw earlier. So, let's [22:25] say if the paragraph tag is under the [22:27] blockquote [22:28] uh div and uh [22:31] the first paragraph tag is actually [22:34] after in the DOM document. [22:37] So, in that case, we cannot use the tag [22:40] processor. Otherwise, it will find the [22:41] first P tag, not the second one which we [22:43] are actually targeting. [22:45] So, this is our expected output where [22:48] the class should class has drop cap [22:50] should be added to the second paragraph [22:52] tag. [22:53] So, here [22:56] this is the perfect example of how we [22:58] can use the HTML processor. [23:01] So, we will again use the same the [23:03] content filter. We will initialize the [23:05] create fragment method. [23:08] Then, we will [23:09] uh [23:10] move our pointer to the first P tag. [23:13] Then, instead of [23:14] the get attribute and set attribute [23:16] method, we will use the get breadcrumb [23:18] method here. That will provide us the [23:21] full path [23:22] of the [23:23] element from the DOM. [23:25] Right? [23:27] And once we have that, we will add the [23:30] uh drop cap class and we will return the [23:32] updated HTML. [23:37] So, uh we covered all these cases, but [23:39] this is the HTML API is not limited to [23:41] those these example only. [23:44] Like uh there are a lot of more use [23:47] cases that you can achieve with the HTML [23:49] API. So, like first is like if you want [23:52] to add uh this rel, target, and area [23:55] label attributes to links, we can you [23:58] easily do it with this HTML API. Then, [24:01] if you want to assign accessibility [24:03] attributes like aria label, role, or [24:05] scope, we can do it. Then, certain [24:08] organization enforce certain [24:11] uh [24:12] design [24:13] uh [24:14] design elements to their [24:16] all the all the sites. So, we can [24:18] enforce the consistent uh design system [24:22] using HTML API. Then, we can also use [24:25] the HTML API to [24:27] clean up the migrated data and if we [24:29] have [24:30] uh [24:31] structured data like the for rich [24:34] results, we can easily [24:36] use the HTML API to add this attributes. [24:41] Okay. Now, so far we have seen all the [24:43] positive things about HTML API. Now, [24:45] let's see some of the limitations. [24:48] So, as of now, the HTML API cannot [24:51] insert new nodes. So, we cannot insert [24:54] new tags using the HTML API. We cannot [24:58] wrap and wrap existing elements. [25:00] We cannot remove or replace the tags. [25:03] Right? And the bookmark limit is limit [25:06] is also restrictive. So, for the tag [25:09] processor, the limit is 10 and for the [25:11] HTML processor, it is currently 100. [25:14] And it still not support the some of the [25:18] complex elements like SVG [25:21] then complex table elements. [25:23] And [25:24] the HTML processor currently limited to [25:27] body context only. We cannot read head [25:30] part of the DOM document using it. And [25:33] the error handling is also like somewhat [25:35] restrictive. We do not get proper error [25:37] messages. We will only get certain [25:40] uh [25:41] return statements like false and all. [25:45] And let's see what's in the road map. [25:48] So, there are a lot of good things are [25:51] planned for the future. So, first is the [25:53] CSS selector support. So, as of now, we [25:56] are targeting uh ele tags by their [26:00] names. Now, in future, we'll be also be [26:03] able to target the selectors based on [26:05] CSS [26:06] syntax. [26:08] Then, we will have ability to fully [26:10] modify the [26:12] uh tags. We can we will be able to [26:14] insert or remove new tags. [26:16] Then, additional support for the uh [26:20] complex complicated tags like SVG, [26:21] tables. [26:22] Then, text node processing. As of now, [26:25] we can grab the text, but it is quite [26:27] limited. We cannot process the uh alone [26:31] text text node as of now. So, that is in [26:33] the future road map. And to make the [26:36] HTML API as much compliance similar to [26:39] browser. So, [26:40] uh the HTML API will be able to read the [26:43] HTML same as how the browsers currently [26:46] parsing it. [26:48] Right? So, before we wrap [26:50] these are the six things that [26:52] uh [26:53] that we should [26:54] uh [26:55] take away from this session. Like first [26:57] of all, uh we should not use regex for [27:01] HTML parsing. Regex is just for strings [27:03] and HTML is a structured [27:06] uh structured string. So, we should not [27:08] use regex to parse them. [27:10] Then, the HTML API works with existing [27:12] WordPress hooks. So, it is extremely [27:14] easy to use it. [27:15] Then, tag processor is your default [27:18] class. [27:19] We will mostly use that and whenever we [27:21] read we need structure awareness, we [27:24] will use the HTML processor. [27:26] And all this is [27:28] is done on server side. There is no [27:30] client side code. So, there is no layout [27:32] shifting or no uh performance impact due [27:35] to this. And HTML API is already [27:38] production ready and already used at [27:40] multiple places in the WordPress core. [27:43] So, [27:44] we should be start using it if you are [27:47] not. [27:48] Right? [27:49] So, that's pretty much it about the HTML [27:51] API. Thank you for [27:53] uh being here. And if you have any [27:55] question, please feel free to ask. [27:57] Thank you.  📄 **Full text:** ![[Full Document Contents/Articles/WordCamp Asia 2026 Hardik Thakkar Parsing HTML Without Pain.md|WordCamp Asia 2026: Hardik Thakkar "Parsing HTML Without Pain" by YouTube]] ## Highlights - additional uh HTML. So you can see here like we are just passing a simple P tag. But after initializing the DOM document, it is adding unnecessary HTML. So uh reax is fragile. DOM document is very heavy. So what do we actually use here? What if I tell you that WordPress already has a built-in solution for this? We don't need any external libraries or dependencies. The answer is WordPress HTML API. It's ([View Highlight](https://read.readwise.io/read/01kp8ghpw5fwg41jeg0wrq896f)) - Tags: 👻 ai highlighted - part of WordPress code since 6.2. uh it is built on same what we HTML specs that the modern browsers like Chrome, Firefox and Safari uses. It is HTML aware not string aware unlike reax. So it knows like what tag is so it can uh it can differentiate between an img tag and and img word in the string right it uses single pass scanning. It will scan each tag by tag and that's why it's ([View Highlight](https://read.readwise.io/read/01kp8ghpwe9vgxwj4hn8zmk4gz)) - Tags: 👻 ai highlighted - classes then we will use the tag processor but if we need structure awareness like if we want to see where the tag is placed then we will use the uh HTML processor. So it is like what versus where that's the decision that we need need to make. Now uh before we jump onto the uh examples, let's see how we can use the HTML API like how where do we actually put this all this code. So you might all be aware ([View Highlight](https://read.readwise.io/read/01kp8ghpxjpng731bnwwv9neh7)) - Tags: 👻 ai highlighted - the for reach results, we can easily use the HTML API to add these attributes. Okay. Now so far we have seen all the positive things about HTML API. Now let's see some of the limitations. So as of now the HTML API cannot insert new nodes. So we cannot insert new tags using the HTML API. We cannot wrap unwrap existing elements. We cannot ([View Highlight](https://read.readwise.io/read/01kp8ghq19pbmv70s2vthmvpk4)) - Tags: 👻 ai highlighted - names. Now in future we'll be also be able to target the selectors based on CSS syntax. Then we will have ability to fully modify the uh tags. We can we will be able to insert or remove new text. Then uh additional support for the comp complicated tags like SVG, tables. Then text node processing as of now we can grab the text but it is quite limited. We cannot process the uh alone text node ([View Highlight](https://read.readwise.io/read/01kp8ghq4z05xn6rbxp134z55j)) - Tags: 👻 ai highlighted