Proposal for Adding .xml() and .html() Methods to Async Parsing in ECMAScript

💡 Ideas
1

Introduction

This proposal aims to introduce two new methods, .xml() and .html(), to the existing asynchronous parsing interface in ECMAScript. Currently, developers have access to .text() and .json() for handling text and JSON responses, respectively. The addition of .xml() and .html() would streamline the processing of XML and HTML content in a manner consistent with the current standards.

Rationale

  1. Consistency and Simplicity: The .text() and .json() methods are widely used due to their simplicity and consistency. Adding .xml() and .html() would extend this ease of use to XML and HTML data, which are common in web development.

  2. Performance Benefits: By integrating these methods into the language standard, parsers can be optimized at the engine level, potentially leading to performance improvements over custom parsing solutions.

  3. Improved Readability and Maintenance: Native methods simplify code, making it more readable and easier to maintain. This aligns with modern JavaScript's goal of providing a more concise and powerful syntax.

Technical Specification

.xml() Method

  • Purpose: Parses the response body as XML.
  • Usage: response.xml().
  • Return Type: A promise that resolves with the result of parsing the response body text as XML.

.html() Method

  • Purpose: Parses the response body as HTML.
  • Usage: response.html().
  • Return Type: A promise that resolves with the result of parsing the response body text as HTML.

Implementation Notes

  • The implementation should be in line with the existing structure of .text() and .json().
  • Error handling for malformed content should be consistent with the handling in .json().
  • Consideration for security implications, especially with .html(), is crucial to prevent injection attacks.

Use Cases

  1. XML Feeds: Simplifying the consumption of XML feeds like RSS or Atom.
  2. Client-Side Templating: Easier integration of HTML templates fetched from a server.
  3. Web Scraping: Streamlined parsing of HTML for data extraction in web scraping applications.

Potential Challenges

  • Security Concerns: Particularly with .html(), ensuring safe parsing to prevent cross-site scripting (XSS) attacks.
  • Browser Support and Polyfills: Ensuring consistent behavior across different JavaScript engines and providing polyfills for backward compatibility.

Conclusion

The addition of .xml() and .html() methods to asynchronous parsing in ECMAScript will significantly benefit developers by providing a consistent and optimized way to handle XML and HTML data. This proposal seeks the TC39's consideration for these additions, which align with the ongoing evolution of JavaScript towards a more powerful and developer-friendly language.

2

On what object are these methods? There's no i/o in Ecmascript, so this might be something more relevant to WHATWG.

1 Like
3

Yeah, these would be on the Response object from fetch(), so it should be proposed in the Fetch repo

1 Like
4

…where it already has been shot down repeatedly: Proposal: response.xml() · Issue #16 · whatwg/fetch · GitHub

1 Like
5

Given that DOM nodes (what I assume would be the return type of a .*ml call) all belong to an owner document, I'd think a method on Document that accepts a Response as parameter, or perhaps a constructor or static method on that or DocumentFragment, would be a more natural place for such a feature. Do you happen to know if it's been proposed as such for the DOM? I can't recall who owns that off the top of my head

6

That would be exacty what @bergus said: [quote="bergus, post:4, topic:1869, full:true"]
…where it already has been shot down repeatedly: Proposal: response.xml() · Issue #16 · whatwg/fetch · GitHub
[/quote]

7

yes, it has been shot down as an addition to Fetch. I personally agree that it doesn't have a place on Fetch, so the question becomes "where does this feature belong". That's why I'm curious if this has been proposed as an addition to Document or DocumentFragment, which are not part of Fetch but rather, part of the DOM.

8

In any case, it's not really a JS feature, so you'd have better luck asking in various WHATWG repos (in your case, GitHub - whatwg/html: HTML Standard is likely your best bet).

9

I mean I personally don't have enough interest or motivation to pursue this myself, but the responses @tabatkins and @bergus suggest a message of "this feature has no place in spec", and that's not true. I wanted to provide @brandonmcconnell with an idea for where the feature might be more appropriate, and given that @bergus had some useful info about how this concept has fared when proposed to the Fetch group, I thought that perhaps he, or someone, might have seen similar proposals in a different group or have some other useful information about how likely such a proposal would be to succeed.

1 Like