Skip to content
This repository has been archived by the owner on Feb 21, 2024. It is now read-only.

Retire HTMLMessage #83

Open
TheDiscordian opened this issue May 25, 2020 · 0 comments
Open

Retire HTMLMessage #83

TheDiscordian opened this issue May 25, 2020 · 0 comments

Comments

@TheDiscordian
Copy link
Contributor

TheDiscordian commented May 25, 2020

I just discovered HTMLMessage, and it's not clear why it exists in this form to me. I discovered it by looking at #58, and noticed that my PR #82 seems to more naturally integrate. I don't agree with automatically shaping the HTML (what if a user sends <span> with formatting? Now you have something like <span><span></span>, what part's the body? Admittingly, I don't follow the regex there, though), I don't even agree simply with calling it HTML in a public type as it's merely a subset of HTML, it's just formatted text. Rather I think we should make it clear it's a subset, and link to where the differences are found.

I don't think someone receiving or sending formatted text using this library is going to commonly think to look for HTMLMessage, which doesn't seem to be connected to anything, just an oddity. I think SendFormattedText, linked to the spec where it was inspired (what my PR effectively is) is a lot more natural, and fits nicely along-side SendText, we can also re-use the struct there, as that part of the spec was simply extended, we can simply extend the struct, without breaking backward compatibility (unless someone didn't name their fields while declaring, which is considered bad practice anyways).

I think we should have something more natural, and I say this because it is still just text lol. It's all grouped together in the spec, why split it up in the library? :)

In short: HTMLMessage is very confusing as-is, and seems to break the library's flow. Let's look at the intent behind it, and implement it better.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant