[rfc-i] The <tt> train wreck

Julian Reschke julian.reschke at gmx.de
Sun Aug 15 23:30:28 PDT 2021

Am 16.08.2021 um 03:11 schrieb Martin Thomson:
> It seems like overloading this with three levels of semantics is the original sin.

Absolutely; and it's because of that chaos I chose not to document the
later "add-ons" in RFC 7749.

> decorations (italic, bold, monospace), quoting (_, *, "), line breaking
>  From my perspective, it would be good to control each independently.  With tags.  I don't care if that is different tags, attributes on a single tag, or some combination of that with some global flags to control it.  (Global flags => stylesheet?)

Yes, but we really need to understand which of these we really need.
Which brings us back to the question: "what purpose does the TXT version

> Regarding non-breaking options:
> I personally find the current reliance on   &nbhy; (and worse, ‌ of which we have one in RFC 9000) to be problematic.  It means that the text you copy is not the text you expect which can confuse all but the smartest searcher.  I would prefer to control this with tags.  If nothing else, it would be much more explicit and less error-prone.

I agree with that, but would ask first what we need the break control
for. Is this about avoiding line breaks, or about making whitespace in
prose significant? Both? These are different problems.

> With all the effort that went into making BCP 14 not wrap, I note that RFC 9000 wraps between BCP and 14.  Something that RFC 9087 doesn't do - at least for the text rendering (the   is in the XML, but not the HTML, which suggests that xml2rfc is bleaching it incorrectly).

Avoiding line breaks in BCP14 markup is another sad story. If the intent
is not to break inside those consistently, then this is something the
formatter could do (and not require authors to modify the source text).

Best regards, Julian

More information about the rfc-interest mailing list