Revise "unimplemented content" UX for general release

[gnprice]

In lib/widgets/content.dart, we have:

InlineSpan _errorUnimplemented(UnimplementedNode node) {
  // For now this shows error-styled HTML code even in release mode,
  // because release mode isn't yet about general users but developer demos,
  // and we want to keep the demos honest.
  // TODO think through UX for general release

Related:

• Systematically survey message content for unimplemented features #190

[gnprice]

There will also be a small number of areas where we expect to see particular concrete forms of unimplemented syntax, and there's a natural fallback way we should style them. Or at least one such area: #242 (comment)

So when we take up this issue, we should do a grep for TODO(#194) to find any places where we've flagged such cases in a comment.

[gnprice]

A related change we might make for general release is:

• Currently the parser is fairly paranoid about having important semantics it didn't know about go over its head. So when it sees a CSS class it didn't expect, it behaves with the assumption that it's some new feature it doesn't know how to handle, rather than trying to round it off to something it does know about.
• We might adjust things so that for certain types of unexpected elements where we think we can "round off" to a reasonable approximation that we do expect — for example, when the element has unexpected extra CSS classes but looks otherwise like something we understand — we could render that approximation.
• Probably in that case we'd still want it to complain loudly in a debug build, and/or with some "I'm a Zulip developer, please flag errors" setting (so that in e.g. my daily usage with release builds I'd still see the errors), and/or would log errors.

Chat thread here.

(We might split this out to a separate issue when we go to take care of these.)

[gnprice]

We haven't yet thought through what we want this UX to look like in a general release.

At this point it should be pretty rare that this situation arises — our coverage of content features is getting pretty comprehensive, other than rare or historical forms. So I think it's appropriate for it to be fairly conspicuous to the user (and then hopefully some will send us bug reports with screenshots, when it does happen).

One thing we should probably do is make sure that a given unimplemented item doesn't get super long. Some features, notably TeX math, can involve a lot of HTML, so that showing the full HTML (if it turns out to be unimplemented) takes up a lot of space and gets in the way of reading the rest of the thread. That came up here:
https://chat.zulip.org/#narrow/channel/48-mobile/topic/mobile.20beta.20feedback/near/1998686
in the course of discovering an unimplemented case in KaTeX math blocks.

(But then if it's not showing the full HTML in the first place, it should probably have a button to show the full HTML in a modal, or something — so that it's easy for a user to get a screenshot they can send us with the full details to debug. I guess once we're doing that, a bonus feature we could add is to try to fetch the original Markdown from the server and show that too, since that's often very helpful for reproducing.)