The implementation looks good, but I just now noticed that fmt::Write has its own error. This means that it's no longer possible to pass along IO errors. If a write fails to a Write object, the user will have no way to discover why. This seems like a serious drawback of the change.

Yeah, I agree :/

Maybe not worth doing for now.

@marcusklaas Not sure if you're on the Rust Zulip, but I posted this: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/fmt.3A.3AResult.20doesn't.20allow.20having.20an.20error.20message

From that topic:

simulacrum: It is perhaps worth noting that io::Write::write_fmt does preserve the io Error in the raw form (https://doc.rust-lang.org/nightly/src/std/io/mod.rs.html#1498-1513)
simulacrum: so if you're using write! or similar with io sources, and not the fmt trait directly, you'll get the error

From my understanding, our use case falls under the former category, so is this still considered a blocker?

I wonder if this PR could be extended to allow a more generic representation of push_html(&mut String,..)? I'm running into a related problem where a template library (Sailfish) has a Buffer type that impls fmt::Write, but not io::Write for similar reasons (i assume) that this library originally wrote StrWrite.

As far as i can tell this requires users of Sailfish to allocate a secondary String to receive html from this lib. Making the push_html generic seems a good way to deal with this, and fmt::Write seems a possible candidate to support that with this PR. Thoughts?

This is an old pull request and in draft state, it should be redesigned and thought again. Sorry, but this will not happen in the short term unless someone else begin to work in this.