DOMParser Discussion

[sno2]

I think that we should try to implement an official module like the Deno DOM third-party module that includes the DOMParser. The whole part about Deno is to mirror the Browser APIs, but we don't even have an official DOM Parser in the std. I think that this should definitely be in the std as it is something that is in every single browser shipped out of the box. I understand that the deno-dom third party module does include a DOMParser, but there are a couple of issues and if a module were created by Deno, it would be worked on as a community. The author of the module did amazing at starting the project, but we must have one included with Deno. Also, it would make Deno viable for scraping which is very important for a lot of node users. Thank you for your time!

[sno2]

There is also more discussion over at #6794

[0kku]

but there are a couple of issues and if a module were created by Deno, it would be worked on as a community.

Hi! The module is in prerelease so issues are to be expected — please report the issues so we can fix them! Implementing DOM is a lot of work. Also, we do accept PRs for deno-dom, so nothing should stop the community from contributing.

[kitsonk]

Duplicate of #6794

We really don't need to split issues like this.

[sno2]

I did read through #6794, @kitsonk, but the title of that issue was not indicating that there should be an official DOMParser implemented nor did the description so I thought that it would be better to just have it as a separate issue as @jsejcksn stated within the issue. Also, @jsejcksn stated the following in a comment:

Can the scope of the request be clarified?

I don't want to assume anything, but it sounds like DOMParser and XMLSerializer are being abandoned by closing #3447 in preference to this one.

Originally posted by @jsejcksn in #6794 (comment)

Also, @nayeemrmn reacted to the closing of a different issue (#3447) saying that the existing issue (#6794) was not related to implementing a DOMParser, but a basic feature of manipulating the DOM. Therefore, I thought a separate issue dedicated to the DOMParser development discussion will fasten its journey towards production. Here are @nayeemrmn's words:

... are being abandoned by closing #3447 in preference to this one.

@jsejcksn This issue requests a specific and foundational part of the DOM with a use case. It's better to let any more advanced API be gradually requested after the prerequisites are implemented, with specificity and a use case. See #4756. As another reason, #3447 is requesting a jsdom port in std which would be redundant if we're considering built-ins.

@brianleroux For server rendering, I guess for now you're looking for the ability to document.createElement()s, append them to each other, change attributes etc. and just stringify it for the client?

Originally posted by @nayeemrmn in #6794 (comment)

And to you, @0kku, I have been working on trying to understand the code for contributing and I have already reported an issue towards the module. I know this is a lot of work and I understand that I may have sounded pushy within the PR desc, but I was meaning that it should be stated that some Deno module or repo should be declared as the future DOMParser to make sure that everyone understands that that repo will someday be the official DOMParser for Deno that will be incorporated into the std once it is finished.

Sorry if I offended any of you I had honest hopes of bettering the development of a DOMParser into Deno.

[MarkTiedemann]

Here's a ref to an even older DOMParser issue (and it's companion API XMLSerializer) if anyone's interested: #3648

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.