um... blasphemy but... what about .xml() ?

[marcoscaceres]

I know, I know stop throwing tomatoes at me... but stupid piece of crap JSON's lack of comment support means we are doing things like this for localization (adding a global JS object! yeah... OMFG bad!!):

https://github.com/mozilla/remote-newtab/blob/gh-pages/src/locale/newTab.js

The above is better suited for XML, as we can have comments there. I imagine there is probably still quite a bit of XML out there also and I doubt browsers are going to drop support for it any time soon, yada yada yada....

[jakearchibald]

Dupe of #16

A method that took a stream…

fetch(url).then(r => parseDoc(r.body)).then(doc => …)

…or a transform stream would be a better solution here.

[marcoscaceres]

... yeah... I guess, but it seems to be putting purity before developer need. I'm happy to wait and see what feedback comes back from the wider web once fetch gets more adoption.

[annevk]

Well, please also consider the affect on potential non-browser implementations if we suddenly import all of XML/HTML as a dependency.

It's not really purity I think, just basic software engineering practices.

[marcoscaceres]

Ok, I was not aware we were now in the business of specifying behaviour for non-browser implementations. That's a bit of a worry, specially given the dependencies on same origin and other browser-environment specific quirks. Which other platforms are implementing fetch?

[annevk]

I believe there's a number of implementations available for Node.js. They might leave out the CORS aspect there though since it makes less sense.

[yanlee26]

I do not think this is a good solution

[marcoscaceres]

@yanlee26, with streams being part of to fetch, you can make a really nice SAX parser for XML. Also using @jakearchibald's solution works well.

[jakearchibald]

@yanlee26 you need to be clear on what in particular you don't like, along with reasons why, otherwise your comment is of no value.