Extend sanitize

[kascote]

This PR extends sanitize_html to allow custom tags and attributes.

• Two new callbacks handle the checks
• The internal functions were normalized using the same parameters as the callbacks.
• Test added to check for the new functionality
• There are no changes to how the library worked before and do not require code changes.

An upcoming PR will handle the remove_contents option as observed on #101

[jonasfj]

I'm include to think this is a bad idea. I definitely need use-cases.

Yes, it's nice to have more features. But if we add more features we also create options for people to make mistakes.

In a sense I'm very tempted to keep this library as simple and fool proof as possible. Personally, I've found that it's very easy to be a fool and think that allowing a certain tag or attribute through can't possibly be dangerous 🙈

This library is heavily influenced by the choices github makes when santizing rendered markdown. What is the reasonable use case for allowing through more tags and attributes?

And would it perhaps be better to put such logic in a separate package that focuses on being more flexible and less fool proof. It's not like this package has a lot of logic, it just uses package:html.

To a very large extend this package expresses an opinion about how HTML can be sanitized, it aims at safety and simplicity over flexibility.

[jonasfj]

This doesn't need a typedef... also why give a callback... why not just make it a list of string?

[jonasfj]

What examples are there of attributes where this makes sense?

[jonasfj]

lol, I just saw the old comment in #101 (comment) 🤣

hmm, ...maybe, I'm should be more open to signatures like:

• bool allowTag(String tag), and,
• bool allowAttribute(String tag, String attribute, String value)

---

Context: I use this library for sanitizing markdown on pub.dev, and I want that to be consistent with how it renders on github.
But yeah, I can also see the value with allowing a few tweaks.. we did that for adding ugc attributes to links.