Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Proposal: response.xml() #16

Closed
fflorent opened this issue Nov 19, 2014 · 10 comments
Closed

Proposal: response.xml() #16

fflorent opened this issue Nov 19, 2014 · 10 comments

Comments

@fflorent
Copy link

Since XMLHttpRequest.prototype.responseXML used to exist, I guess response.xml() should exist too, right?

Florent
@domenic
Copy link
Member

domenic commented Nov 19, 2014

See the Note

Formats you would not want a network layer to be dependent upon, such as HTML, will likely not be exposed here. Rather, an HTML parser API might accept a stream in due course.

A network layer should not be dependent on an XML parser.

@domenic domenic closed this as completed Nov 19, 2014
@domenic
Copy link
Member

domenic commented Nov 19, 2014

Sorry, didn't mean to close, that should be @annevk's prerogative.

@domenic domenic reopened this Nov 19, 2014
@domenic domenic mentioned this issue Nov 19, 2014
Closed
@fflorent
Copy link
Author

I am not sure what this note means. As I understand, a HTML Parser could build a DOM Tree as it receives data from the request, and the intermediate state of this tree exposed to the user? (sorry if I am completely misunderstanding)

Also I don't see why exactly for XML this proposal is invalid. An XML document meaningful (and valid) once it is entirely loaded, right? And why is this valid for JSON and not for XML?

Florent

@annevk
Copy link
Member

annevk commented Nov 20, 2014

JSON is low on complexity and JavaScript has JSON built-in.

@annevk annevk closed this as completed Nov 20, 2014
@fflorent
Copy link
Author

I thought it would have targeted browser environments (so parsers are built in them).

Edit: If you could explain a bit further (with links maybe) so I can be more pertinent next time I propose something else, I would be thankful.

Florent

@annevk
Copy link
Member

annevk commented Nov 21, 2014

The idea is to have some amount of layering in APIs. Say you implement fetch() in JavaScript. You would not want to import an entire XML and HTML stack to do that.

@fflorent
Copy link
Author

Oh, I see now. Thanks for this explanation.

Florent

@Mouvedia
Copy link

@annevk so the reason for the lack of .document() (or .xml()) is the polyfill itself?
Well you don't have to worry since you have "document" listed here. And as you can see here it has been supported for quite some time now.
cf JakeChampion/fetch#204

Id say this should be reopened.

@annevk
Copy link
Member

annevk commented Sep 28, 2015

@Mouvedia no, the reason for lack of that is that it would be poor architecture. It would be better to have a way to create a document from a stream and use that.

@Mouvedia
Copy link

@annevk are you saying it belongs on whatwg/streams?

This was referenced Oct 28, 2015
Closed
Closed
@yan12125 yan12125 mentioned this issue Jul 15, 2016
Closed
@Mouvedia Mouvedia mentioned this issue Sep 20, 2016
Closed
darknoon added a commit to darknoon/sketch-module-fetch-polyfill that referenced this issue Mar 25, 2017
@darknoon
Remove xml() Response method since it's not part of the spec or polyf…
b18d6a8 
…ills

see whatwg/fetch#16
@darknoon darknoon mentioned this issue Mar 25, 2017
Merged
@ghost ghost mentioned this issue Feb 2, 2018
Merged
@muthurathinam muthurathinam mentioned this issue Aug 13, 2018
Merged
yutakahirano added a commit that referenced this issue Jun 23, 2020
@yutakahirano
# This is a combination of 2 commits.
db9fbcd 
# This is the 1st commit message:

# This is a combination of 23 commits.
# This is the 1st commit message:

Integrate CORP and COEP

This is part of the introduction of COEP
(whatwg/html#5454). The CORP check now takes
COEP into account. Also, responses coming from service workers
are checked.

# This is the commit message #2:

Update fetch.bs

Co-authored-by: Domenic Denicola <d@domenic.me>
# This is the commit message #3:

Update fetch.bs

Co-authored-by: Domenic Denicola <d@domenic.me>
# This is the commit message #4:

fix

# This is the commit message #5:

fix

# This is the commit message #6:

fix

# This is the commit message #7:

fix

# This is the commit message #8:

fix

# This is the commit message #9:

fix

# This is the commit message #10:

fix

# This is the commit message #11:

fix

# This is the commit message #12:

fix

# This is the commit message #13:

fix

# This is the commit message #14:

fix

# This is the commit message #15:

fix

# This is the commit message #16:

fix

# This is the commit message #17:

fix

# This is the commit message #18:

Update fetch.bs

Co-authored-by: Anne van Kesteren <annevk@annevk.nl>
# This is the commit message #19:

Update fetch.bs

Co-authored-by: Anne van Kesteren <annevk@annevk.nl>
# This is the commit message #20:

fix

# This is the commit message #21:

fix

# This is the commit message #22:

fix

# This is the commit message #23:

fix

# This is the commit message #2:

fix
@domenic domenic mentioned this issue Dec 8, 2020
Closed
@domenic domenic mentioned this issue Jan 19, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@Mouvedia @fflorent @domenic @annevk