On Mon, Jun 23, 2014 at 9:35 PM, Jonas Sicking wrote:
> Note that you can't do JSON decoding without first doing binary->text
> decoding. So by having a "asJSON" function we are automatically
> pulling in charset conversion.
Yes, Domenic pointed that out. The same is true for asText(). But note
t
On Mon, Jun 23, 2014 at 8:46 AM, Domenic Denicola
wrote:
>
>> 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 i
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
ServiceWorkers.
I'd say asHTML isn't going to work out. But
document.parseHTMLStream(response.body) seems fine to me. A discussion
for ano
From: Adam Barth
> 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 H
On Mon, Jun 23, 2014 at 8:28 AM, Anne van Kesteren wrote:
> On Mon, Jun 23, 2014 at 5:11 PM, Adam Barth 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 wan
From: annevankeste...@gmail.com on behalf of Anne
van Kesteren
> 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 co
On Mon, Jun 23, 2014 at 5:11 PM, Adam Barth 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
On Mon, Jun 23, 2014 at 3:15 AM, Anne van Kesteren wrote:
> On Sun, Jun 22, 2014 at 6:10 AM, Adam Barth wrote:
>> I haven't been following the fetch API in detail. Is there some
>> collective understanding of what abstraction layer fetch represents?
>
> It's at the same level as XMLHttpRequest.
Sounds good Anne.
Its pretty easy to feature detect these capabilities now that they are
normal methods.
Patiently awaiting Streams itself to be finalized.
Thanks!
On Mon, Jun 23, 2014 at 5:15 AM, Anne van Kesteren wrote:
> On Sun, Jun 22, 2014 at 6:10 AM, Adam Barth wrote:
>> I haven't been
On Sun, Jun 22, 2014 at 6:10 AM, Adam Barth wrote:
> I haven't been following the fetch API in detail. Is there some
> collective understanding of what abstraction layer fetch represents?
It's at the same level as XMLHttpRequest.
> For example, I could imagine that we might not want to add a
>
I haven't been following the fetch API in detail. Is there some
collective understanding of what abstraction layer fetch represents?
For example, I could imagine that we might not want to add a
dependency from the fetch to the HTML parser because fetch is a lower
layer of the system.
Adam
On Fr
Hey Anne, love the direction of the Fetch API.
I'm curious what you think of an asHTML extension to the FetchBodyStream?
Parsing fragment HTML from XHRs is pretty typical. It could potential
return a DocumentFragment or if it used some streaming HTML parser, it
could emit the top level nodes as t
12 matches
Mail list logo
