RFC: split HTML renderer into processor and renderer components #987
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
systemsoverload
force-pushed
the
systemsoverload/html-writer-trait
branch
3 times, most recently
from
c5b0d1b to
f4a1c38
Compare
This commit introduces a significant architectural improvement to the HTML rendering system by splitting it into two main components: 1. HtmlEventProcessor: Handles event processing and document structure 2. HtmlElementRenderer: Defines the interface for HTML element rendering Key changes: - Move HTML rendering logic into a trait for better abstraction - Export all of these in the `html` module of the crate - Create a default implementation (HtmlWriter) of the renderer interface - HtmlWriter/push_html should behave exactly the same as before The refactoring grants an easy way for third parties to create their own extended impl of `push_html` that provides a custom event iterator, html renderer, or both. This will specifically make writing external HTML rendering crates much simpler as `pulldown-cmark` can continue to own the default html rendering implementation which these crates can use as their own defaults.
systemsoverload
force-pushed
the
systemsoverload/html-writer-trait
branch
from
f4a1c38 to
2369ed4
Compare
systemsoverload
changed the title
|
Interesting, but this is a pretty big change and it requires a closer look about how to handle this (at a first look it seems too much new code, performance implications, etc.). Thanks! |
|
Im relatively new to rust so Im definitely open to any kind of feedback that you might have that could get something like the end goal (an exposed trait) without the implications you've called out above. If it's just not that compelling to you though, feel free to close the issue - no sore feelings for an RFC to which the response is "no thank you" :) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit introduces a significant architectural improvement to the HTML rendering system by splitting it into two main components:
Key changes:
htmlmodule of the crateThe refactoring grants an easy way for third parties to create their own extended impl of
push_htmlthat provides a custom event iterator, html renderer, or both.This will specifically make writing external HTML rendering crates much simpler as
pulldown-cmarkcan continue to own the default html rendering implementation which these crates can use as their own defaults.