Upstreaming of community fork `anstyle-html`

[Urgau]

I have a fork for anstyle-svg but for HTML, anstyle-html.

The advantage of HTML is that web-browsers can easily handle a 20000 lines long output, while can barely handle a 1000 lines long SVG from anstyle-svg.

Compared to anstyle-svg, anstyle-html basically the same except for the main function render_html.

Would this be something you would be interested having upstreamed? as a new crate? directly in anstyle-svg?

[epage]

Great question! When creating anstyle-svg, I had considered whether to do SVG or HTML.

One of the big questions I had with HTML was whether to offer HTML fragments or complete HTML pages. The benefit to an SVG is they are individually viewable while also easily embedding within a page (not counting iframes which I have built up the impression over the years that they have problems). This works well for both snapshot testing and generating snapshots for documentation.

It sounds like your render_html is exclusively for a full HTML page.

If we supported HTML also, the name of the library would be a little off. Would we merge in anstyle-html or provide a more general name (but not too general?).

[Urgau]

It sounds like your render_html is exclusively for a full HTML page.

That's because I only needed full a HTML page, but I don't think there is anything preventing generating fragments, we could have a HtmlFragment { style: String, body: String } of some sort.

provide a more general name (but not too general?).

Would that be a new crate incorporating both SVG and HTML? and potential other I guess?

[epage]

We can either have parallel crates or one crate for this. SVG and HTML are similar enough in their needs and burden. However, if people want to generalize this past that, then that becomes a problem as it can add a lot of complexity that might be better left for other crates.

If we officially support two, we'd likely need to deal with that the ANSI escape code parser was recently forked from anstream in #255 and we'd likely want to find a home for that rather than fork it again.

[Urgau]

My opinion (which isn't based on much) would be to have a single crate for SVG and HTML as they are so similar, also given that anstyle-svg already exist on crates.io I would just reuse it and deal with the slightly weird name.

[epage]

Sorry for the delay; I've been letting this sit in the background a bit to process. I especially find this useful to overcome knee-jerk reactions.

I still hesitate a bit but I think we can go forward with working towards merging a PR for a render_html function.

[Urgau]

Great, opened #258 for that.