Discoverability on crates.io
opened this issue · comments
About a week ago I was searching for a library to manipulate HTML documents using a DOM like structure. I found many crates, none of which were really ready in my opinion, but I did not find this crate.
In fact, is you go to crates.io now and search for any of the following, you will not find it either:
- html
- html dom
- html manipulation
- html tree
I only found out about this project by googling "rust rctree html" which led me to the users.rust-lang.org forum thread.
It seems that crates.io has an issue with your written description:
(朽木) HTML/XML tree manipulation library
It sees "HTML/XML" as a single word and as a result if you just search for "html" or "xml" you will not find the crate. I will create an issue regarding this on the crates.io repo if one doesn't already exist.
However for the time being, you can probably solve this by adding the keywords property to Cargo.toml:
keywords = ["dom", "xml", "html", "markup", "language"]
Honestly, I’m conflicted. I’m made this library as a proof-of-concept for how to use the html5ever and selectors crate together, because multiple people had asked. But I’m not all that interested in developing it further or maintaining it over time.
So as long as there aren’t other people doing that work, I’m not sure I actually want to make this library more discoverable.
Do what you wish. I don't want to force you into anything.
I started writing my own today anyway as an exercise in learning rust.
@anarchistmae I'm doing 180 on this. However, kuchiki can't parse xml atm. Feel free to submit a PR.
I'm willing to implement this (just some changes to the Cargo.toml?) and submit a PR if it is still relevant.
Nothing about #48 (comment) has changed, so improving this crate's discoverability is not a priority.
@jdm I thought that Ygg01's comment indicated it was wanted?
Well, I would definitely want that functionality, but if jdm and Simon disagree, I'm outvoted.
I’m not sure which one you mean so: adding XML1 parsing or serialization support sounds fine to me. (For XML5 I’d prefer also having XML1 and some docs explaining the differences.) What I’m not thrilled about is more discoverability without more active maintenance.
I will soon archive this repository and make it read-only, so this issue will not be addressed: https://github.com/kuchiki-rs/kuchiki#archived