https://github.com/mastodon/mastodon/pull/23913 Skip to content Toggle navigation Sign up * Product + Actions Automate any workflow + Packages Host and manage packages + Security Find and fix vulnerabilities + Codespaces Instant dev environments + Copilot Write better code with AI + Code review Manage code changes + Issues Plan and track work + Discussions Collaborate outside of code + Explore + All features + Documentation + GitHub Skills + Blog * Solutions + For + Enterprise + Teams + Startups + Education + By Solution + CI/CD & Automation + DevOps + DevSecOps + Case Studies + Customer Stories + Resources * Open Source + GitHub Sponsors Fund open source developers + The ReadME Project GitHub community articles + Repositories + Topics + Trending + Collections * Pricing [ ] * # In this repository All GitHub | Jump to | * No suggested jump to results * # In this repository All GitHub | Jump to | * # In this organization All GitHub | Jump to | * # In this repository All GitHub | Jump to | Sign in Sign up {{ message }} mastodon / mastodon Public * * Notifications * Fork 6k * Star 40.6k * Code * Issues 3.6k * Pull requests 290 * Discussions * Actions * Security * Insights More * Code * Issues * Pull requests * Discussions * Actions * Security * Insights New issue Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community. Pick a username [ ] Email Address [ ] Password [ ] [ ] Sign up for GitHub By clicking "Sign up for GitHub", you agree to our terms of service and privacy statement. We'll occasionally send you account related emails. Already on GitHub? Sign in to your account Jump to bottom Add support for incoming rich text #23913 Merged Gargron merged 3 commits into mastodon:main from ClearlyClaire: features/incoming-rich-text Mar 3, 2023 Merged Add support for incoming rich text #23913 Gargron merged 3 commits into mastodon:main from ClearlyClaire: features/incoming-rich-text Mar 3, 2023 +85 -27 Conversation 15 Commits 3 Checks 12 Files changed 4 Conversation This file contains 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 Show hidden characters ClearlyClaire Copy link Collaborator @ClearlyClaire ClearlyClaire commented Mar 1, 2023 * edited Add native support for the incoming tags: del, pre, blockquote, code, b, strong, u, i, em, ul, ol, li Transform h1 through h6 tags to

contents

image Sorry, something went wrong. 38 shleeable, Lonor, McKristoffer, snarfed, manton, paulrobertlloyd, Ciantic, aslakr, mattstein, cam-rod, and 28 more reacted with thumbs up emoji 3 bremensaki, Sollace, and mnhrdt reacted with thumbs down emoji 17 shleeable, snarfed, freyaalminde, Ciantic, teacherbuknoy, jlelse, PsypherPunk, lguenth, LucasJanin, Quiel245, and 7 more reacted with hooray emoji [?] 28 ykzts, connyduck, shleeable, rinsuki, BasixKOR, jhp0tter, ThatOneCalculator, McKristoffer, RileyApeldoorn, freyaalminde, and 18 more reacted with heart emoji 7 SouthFox-D, freyaalminde, Ciantic, teacherbuknoy, jlelse, simonemargio, and brycewray reacted with rocket emoji 1 saschanaz reacted with eyes emoji All reactions * 38 reactions * 3 reactions * 17 reactions * [?] 28 reactions * 7 reactions * 1 reaction ClearlyClaire added 3 commits March 1, 2023 16:44 @ClearlyClaire Allow a wider range of HTML tags in incoming posts f84f1ab @ClearlyClaire Add CSS for rich text in posts c46ab11 @ClearlyClaire Fix sanitizing tests 2e74577 @shleeable Copy link Contributor shleeable commented Mar 2, 2023 * edited This is a wonderful user facing addition. Request to add extra highlighting to code quotes. This will make it easier to read, and make it consistent with other pages. Github image Elk image Slack image 14 freyaalminde, Fastidious, JensAyton, Nekkowe, jacobras, brendanjones, ariasuni, CrazyJake88, blittle, GabDug, and 4 more reacted with thumbs up emoji 2 bremensaki and EvelynSubarrow reacted with confused emoji All reactions * 14 reactions * 2 reactions Sorry, something went wrong. @bremensaki Copy link bremensaki commented Mar 2, 2023 Is there any chance of this being a user-configurable option or will it be always-on for every instance? I highly value the clarity of extremely predictable text formatting to follow this stuff, and I think a timeline with extra formatting scattered through it is going to be very hard to process. I have always considered Mastodon's lack of formatting options like this to be a fantastic feature, not a deficiency. 14 strelka145, L3viathan, CrazyJake88, shafy, jmcunx, mnhrdt, audaciouscode, quentez, dumduma, chusopr, and 4 more reacted with thumbs up emoji 9 Nekkowe, brendanjones, lexd0g, donaldw, steve-bate, cornelk, frumble, bmanturner, and calebhearth reacted with thumbs down emoji All reactions * 14 reactions * 9 reactions Sorry, something went wrong. @ClearlyClaire Copy link Collaborator Author ClearlyClaire commented Mar 2, 2023 Is there any chance of this being a user-configurable option or will it be always-on for every instance? I highly value the clarity of extremely predictable text formatting to follow this stuff, and I think a timeline with extra formatting scattered through it is going to be very hard to process. I have always considered Mastodon's lack of formatting options like this to be a fantastic feature, not a deficiency. I guess it could be made optional, but I am not sure it is worth introducing an option considering how marginal disabling it would be, especially when disabling that option would alter the meaning of posts. Posts authored from outside Mastodon can already include more formatting, and that has been the case for years. Dropping blockquotes and strike-through in particular can change the meaning of a post quite a bit. In contrast, some Mastodon users sometimes emulate bold or italics by inappropriately using unicode characters, which leads to a worse experience for everyone, and especially for users of screen readers and similar assistive technology. 23 davmillar, kaniini, ConfuSomu, taniki, teacherbuknoy, protospork, McPringle, Krinkle, Nekkowe, hirnsushi, and 13 more reacted with thumbs up emoji All reactions * 23 reactions Sorry, something went wrong. @bremensaki Copy link bremensaki commented Mar 2, 2023 I feel like this is being implemented is a foregone conclusion and I'm in a significantly small minority, so I'm done here. Just going to leave it at saying I really do think this is a move that will be a big step backwards to some users and should be optional or controllable in some way. All reactions Sorry, something went wrong. @ClearlyClaire Copy link Collaborator Author ClearlyClaire commented Mar 2, 2023 While not completely ideal, if this ends up being an issue for you, you could maybe rely on user CSS to override the style changes. All reactions Sorry, something went wrong. @trwnh Copy link Contributor trwnh commented Mar 3, 2023 disabling that option would alter the meaning of posts. if the intention is to preserve meaning, then what about that old approach of having css styling to keep a "plaintext appearance" by essentially mimicking markdown? i can't find the PR in question, but it used css :before and :after to add asterisks around em and strong, before ul li, and so on. aside from that, a few concerns: * nested lists becoming too narrow on the multi-column UI * nested blockquotes being a generally bad idea * overly long lines inside pre blocks (unless you use a pre-wrap strategy... which can break pre-formatting and/or make things unreadable) * headings lose their hierarchy * i suppose this also represents a contract violation for API consumers who now have to deal with more than the p br span a that they were promised... 5 noiob, EvelynSubarrow, teacherbuknoy, hazycora, and gaelicWizard reacted with thumbs up emoji All reactions * 5 reactions Sorry, something went wrong. Gargron Gargron approved these changes Mar 3, 2023 View changes Hide details View details @Gargron Gargron merged commit 3a6451c into mastodon:main Mar 3, 2023 13 checks passed noellabo pushed a commit to fedibird/mastodon that referenced this pull request Mar 3, 2023 @ClearlyClaire @noellabo Add support for incoming rich text (mastodon#23913) ddcece6 kmycode pushed a commit to kmycode/mastodon that referenced this pull request Mar 5, 2023 @ClearlyClaire @kmycode Add support for incoming rich text (mastodon#23913) 3c3da81 @Ciantic Copy link Ciantic commented Mar 5, 2023 * edited This is the right choice. HTML is accessible for screen readers but text formatting like pure Markdown isn't (if it is not converted to HTML first). People are misusing Markdown-like formatting by plastering messages with *something* and _something_, and * bullet lists etc. and it is not accessible for screen readers. There are complaints from screen reader users about Markdown-like plain text formatting as reading those characters out loud makes no sense. HTML has no problems in this regard, screen readers can handle strong, em etc, much better than a jumble of special chars of *, _, ... HTML should be the choice for formatting in Mastodon for accesibility reasons. 18 aslakr, kaniini, ConfuSomu, bleonard252, sgrigson, Techie-Pi, regulardesigner, amadejpapez, Nekkowe, hirnsushi, and 8 more reacted with thumbs up emoji All reactions * 18 reactions Sorry, something went wrong. loqibot pushed a commit to indieweb/wiki that referenced this pull request Mar 5, 2023 [tantek] added "Criticism: mastodon/mastodon#23913 (comment)" to "See... ... 46dfa49 ... Also" @Huy-Ngo Copy link Huy-Ngo commented Mar 6, 2023 @Gargron you might want to close these issues with this PR: #18958 # 15311 #15554 #8474 All reactions Sorry, something went wrong. This was referenced Mar 6, 2023 Add support for posting with Markdown syntax #23981 Open Mastodon can't just choose to not show markdown anymore. #18958 Open @rckoenes Copy link rckoenes commented Mar 6, 2023 This is the right choice. HTML is accessible for screen readers but text formatting like pure Markdown isn't (if it is not converted to HTML first). People are misusing Markdown-like formatting by plastering messages with *something* and _something_, and * bullet lists etc. and it is not accessible for screen readers. There are complaints from screen reader users about Markdown-like plain text formatting as reading those characters out loud makes no sense. HTML has no problems in this regard, screen readers can handle strong, em etc, much better than a jumble of special chars of *, _, ... HTML should be the choice for formatting in Mastodon for accessibility reasons. Well as a mobile developer I can say parsing HTML to rich text is harder then Markdown and a webclient would still output HTML and not the markdown. So I fully agree with the accessibility feature, but say that markdown will not work is not case since it is up to the client te render the content is such a way the user will have a good experience even if they use screenreader. 8 cam-rod, donaldw, quentez, jerome-tgl, petergeneric, aloisdg, marckohlbrugge, and kaiserkiwi reacted with thumbs up emoji All reactions * 8 reactions Sorry, something went wrong. @cam-rod Copy link cam-rod commented Mar 6, 2023 * edited Agreed that HTML should remain the main way of transferring messages. When supporting other types of formatting, we should use the existing definition in the ActivityPub spec, section 3.3. The source field stores the original formatting, with a Content-Type like text/ markdown, and then the posting client is expected to convert to HTML for the content field. 5 rckoenes, jerome-tgl, Ciantic, aloisdg, and gaelicWizard reacted with thumbs up emoji All reactions * 5 reactions Sorry, something went wrong. @Gargron Copy link Member Gargron commented Mar 6, 2023 This PR is not about changing the content-type of the content field. 3 rckoenes, cam-rod, and Ciantic reacted with thumbs up emoji All reactions * 3 reactions Sorry, something went wrong. @Ciantic Copy link Ciantic commented Mar 6, 2023 * edited So I fully agree with the accessibility feature, but say that markdown will not work is not case since it is up to the client te render the content is such a way the user will have a good experience even if they use screenreader. This is not about choosing between Markdown or HTML. ActivityPub and Mastodon already use HTML for sending messages, and this is about rendering more HTML tags correctly. Currently if someone tries to shovel Markdown-like content it comes out like this:

Hello *World*

* Bullet item 1

* Bullet item 2

This causes the issue with accessibility as readers read out loud those * and other Markdown-like content. That obviously makes no sense, this PR allows to render of more tags, and further down the line Markdown support can be added with a source field like @cam-rod just mentioned. 1 cam-rod reacted with thumbs up emoji All reactions * 1 reaction Sorry, something went wrong. @aloisdg Copy link aloisdg commented Mar 6, 2023 Screen readers limitations should be work upon. Is there an existing issue about that on nvaccess ? All reactions Sorry, something went wrong. @sk22 sk22 mentioned this pull request Mar 6, 2023 Render Markdown lists correctly mastodon/mastodon-android#434 Open @zichy Copy link zichy commented Mar 6, 2023 Please note that the element is in fact not called "underline" anymore and should only be used for unarticulated annotations. I think that implementing it in the way proposed would be counterproductive. All reactions Sorry, something went wrong. @hatkidchan hatkidchan mentioned this pull request Mar 6, 2023 Telegram -> Mastodon reposting hatkidchan/mastoposter#18 Closed @gaelicWizard Copy link gaelicWizard commented Mar 6, 2023 shovel This kind of plain-text markup predates the world-wide-web. Markdown syntax deliberately mimics the long extant tradition, not originates it. All reactions Sorry, something went wrong. Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment Reviewers @Gargron Gargron Gargron approved these changes Assignees No one assigned Labels None yet Milestone No milestone Development Successfully merging this pull request may close these issues. None yet 12 participants @ClearlyClaire @shleeable @bremensaki @trwnh @Ciantic @Huy-Ngo @rckoenes @cam-rod @Gargron @aloisdg @zichy @gaelicWizard 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. Footer (c) 2023 GitHub, Inc. Footer navigation * Terms * Privacy * Security * Status * Docs * Contact GitHub * Pricing * API * Training * Blog * About You can't perform that action at this time. You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.