W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2014

Re: [whatwg] Fetch API: asHTML

From: Joshua Peek <josh@joshpeek.com>
Date: Mon, 23 Jun 2014 10:56:40 -0500
Message-ID: <CA+RmjJL0ef8_X=xG6o8=nOkmWVO5yAdLQ1qM1ExTyNDbHDpBxA@mail.gmail.com>
To: Adam Barth <w3c@adambarth.com>
Cc: WHATWG <whatwg@whatwg.org>
Thats a good point.

You need a document context to do any sort of Element construction.

Fetch shouldn't have any dependency on a document since its targeting

I'd say asHTML isn't going to work out. But
document.parseHTMLStream(response.body) seems fine to me. A discussion
for another thread.

On Mon, Jun 23, 2014 at 10:41 AM, Adam Barth <w3c@adambarth.com> wrote:
> On Mon, Jun 23, 2014 at 8:28 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>> On Mon, Jun 23, 2014 at 5:11 PM, Adam Barth <w3c@adambarth.com> wrote:
>>> XMLHttpRequest isn't particularly cleanly layered.  It's sounds like
>>> you're not overly concerned about layering, which is probably fine.
>> I think I see what you mean. If you wanted to implement this in terms
>> of JavaScript then indeed you would end up importing several modules
>> other than the fetch module to implement these methods. E.g. encoding,
>> for asText, filesystem and MIME for asBlob, and encoding and JSON for
>> asJSON. For asHTML you'd need encoding and HTML.
> Yes, exactly.  However, the sadness comes when the HTML module ends up
> depending on the fetch module because that creates a circular
> dependency.  You then need to merge them into one module, which will
> quickly become the "everything" module.
>> This seems fine to me.
> This discussion is about theoretical purity, which is pretty far down
> the list things we should care about.
>> However, I could see it instead has to go the other way around.
>> Instead of having a bunch of methods on stream to convert it into
>> various other pieces. Other pieces could have ways of dealing with
>> streams. That might make coding a bit more awkward though.
> It might be instructive to think about how the Node community would
> structure these APIs.  Node has a much stronger notion of modules and
> dependencies than browsers because Node uses npm.  As Node developer,
> I would be sad if my networking module dragged in an entire HTML
> implementation.
> Adam
Received on Monday, 23 June 2014 15:57:05 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:21 UTC