Considering switching to a larger text field for post bodies

[trichoplax]

#958 was fixed by allowing up to 65,535 bytes of HTML to be generated from 30,000 bytes of raw Markdown. Although it's possible to exceed 65,535 bytes of HTML with just a few thousand bytes of Markdown, I can only think of extremely contrived examples such as absurdly deeply nested blockquotes. I think 65,535 is sufficient for posts that are limited to 30,000 bytes of Markdown.

However, I'd like that Markdown limit be configurable per category. For example, Preferred length limit for Code Golf posts makes a case for at least doubling that limit. Also, Post body too long but not too long? was close to exceeding the 30,000 character Markdown limit even without the bug, so the Code Reviews category would benefit from a higher limit.

Should we consider switching from text (with a capacity of 65,535 bytes), to mediumtext (that allows up to 16,777,215 bytes)?

• Making this switch for the HTML (the body field) would allow the Markdown field to go up to 65,535 without risk of exceeding the HTML limit when converted.
• Making this switch for the Markdown field too would allow some categories to be given a limit higher than 65,535.

With reason to exceed 30,000 in both Code Golf and Software Development's Code Reviews category, I like the idea of being able to do more than just double the limit.

[trichoplax]

A possible alternative might be to avoid storing the HTML in the database, so its size becomes irrelevant and the Markdown limit can be increased anywhere up to 65,535 without problem. The HTML would then be generated on demand (but cached so most requests do not involve any generation of HTML).

My personal preference would still be to allow even longer Markdown, to allow including both readable code and explanations within a single Code Golf answer, and to allow quoting significant portions of reviewed code in a Code Reviews answer, along with review comments and example rewritten code.

[trichoplax]

I've asked the Software Development community what limit they would prefer for Code Reviews to see how much demand there would be for this: Post length limit for Code Reviews questions and answers

[MoshiKoi]

I am against generating HTML on demand. That would mean that any changes in markdown rendering may silently change older posts. (Of course, we should strive to maintain backwards compatibility even if we do change the renderer, but it's a possibility to take into account.)

This also would require using server-side rendering again, which we used to do, but was relegated to a fallback because of performance impacts and synchronization issues because the client and server used different libraries. This kind of on-demand generation would be even worse for performance. Right now we ask the client to send both the markdown and rendered HTML, and store both. I don't feel strongly either way - relying on client rendering comes with its own issues - but it is something that needs to be taken into account.