On Mon, Jun 23, 2014 at 9:35 PM, Jonas Sicking jo...@sicking.cc 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().
On Sun, Jun 22, 2014 at 6:10 AM, Adam Barth w...@adambarth.com 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
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 ann...@annevk.nl wrote:
On Sun, Jun 22, 2014 at 6:10 AM, Adam Barth
On Mon, Jun 23, 2014 at 3:15 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Sun, Jun 22, 2014 at 6:10 AM, Adam Barth w...@adambarth.com 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
On Mon, Jun 23, 2014 at 5:11 PM, Adam Barth w...@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
From: annevankeste...@gmail.com annevankeste...@gmail.com on behalf of Anne
van Kesteren ann...@annevk.nl
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
On Mon, Jun 23, 2014 at 8:28 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Mon, Jun 23, 2014 at 5:11 PM, Adam Barth w...@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
From: Adam Barth w...@adambarth.com
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
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
On Mon, Jun 23, 2014 at 8:46 AM, Domenic Denicola
dome...@domenicdenicola.com 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 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
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
12 matches
Mail list logo
