Add support for customRender in the `RichText` parser

[Sub6Resources]

The RichText version of the parser needs some sort of extension mechanism. See #37 (comment).

[jeffmikels]

Perhaps we can solve this by merging the two parsers into one that implements a virtual DOM that is more Flutter friendly and then specify how to render that DOM as widgets. Both parsers currently create actual Flutter widgets as they walk the html tree, but if we create a middle ground, Virtual DOM, we might end up with something better than both.

How to do this? Some initial ideas:

1. Create a "Virtual DOM" that makes sense for Flutter. The one parser would walk the HTML tree and convert it into a simplified tree of Dart objects that make sense for Flutter apps. We would support a subset of the HTML spec and preserve HTML attributes in objects like Boxes, Paragraphs, Spans, Links, Images, and Tables.
2. Create a default DOM renderer that translates each object to a real Flutter Widget. Boxes become Containers, Paragraphs become RichText, Spans and plain text become TextSpans, etc.
3. Facilitate custom renderers in one or more of the following ways: (1) do nothing and require the end user to extend the HTML widget and override the build method (always an option anyway), (2) on HTML object creation allow the user to specify individual renderers for any specific renderer overrides desired, or (3) on HTML object creation, expose a "styles" object that will work in a fashion like CSS allowing Container styles and TextSpan styles to be associated with class and id values.

[skipness]

@jeffmikels
Do you think this react native library works like what you mentioned above? If yes, I think we can take a look how to implement all this functions in Dart way.

[Sub6Resources]

@jeffmikels I really like the idea of adding an intermediary step to the parser (or as you said, a virtual DOM). As for implementing custom renderers, I think option 2 you suggested above is the best way to go. Like you said, the first option has always been there, but there are few who have used it and lots who want to expand the functionality of this plugin. Option 3 isn't a bad option, but it doesn't allow for additional, currently unsupported elements (e.g. <video>), to be added if desired. I think in the end we'll end up doing both options 2 and 3.

I've been thinking a lot about the general types of elements and nodes HTML has so we can create a simplified tree, and I think I have a pretty good idea of what needs to happen. I'll be working on creating a new version of the parser based on what I've been thinking that will hopefully combine the best of both parsers. 😃 When I finish with my implementation I'll open a pull request so that we can get some discussion and hopefully fix any errors before merging to master. My hope is that the new parser can coincide with a 1.0.0 release of this plugin. 🤞

[hiroshihorie]

Please support this asap, since there is no way to set colors. I need a custom tag that can specify partial colors.

[Sub6Resources]

I've created a development roadmap to show progress and planned features for version 1.0.0.