Re: [Rfc-markdown] [rfc-i] [Tools-discuss] Tool to convert TXT to RFCXML

[Martin Thomson <[e-mail]>]

On Mon, Jul 17, 2023, at 02:45, Julian Reschke wrote:
> I agree partly.

Same.

> The trouble with that is that even a rule like "do not insert LF into
> terms" may not be always desirable. For instance, jn HTTP we have
> several longish header field names, and I would not want them to be not
> broken across lines.

Yep, and there are lots of those examples.  Sometimes you want line breaking and other times not.  The "don't break me" ultimately ends up needing some amount of authorial control, which is sometimes orthogonal to any semantic distinction we might invent.  For instance, a blanket rule for HTTP fields seems wise... up until the point when you are introduced to all the terrible CORS names, which are so long that avoiding wrapping creates a worse outcome than just letting them flop around all over the place.

I have a real soft spot for purity as far as it relates to the split between semantics and presentation.  CSS takes a pretty good swing at this.  But in practice, this line never holds firm.  For instance, when authoring HTML you always have a bunch of <span or <div elements that exist only so that you can hang styling rules on them.  I've seen a lot of attempts at a clean split and the discipline just never lasts.

So I tend to think that we need to identify those things that we know we need to make things work properly.  Acknowledge that this isn't a pure stance, but a pragmatic one.  We won't get it right always, but we should probably stop the ad hoc use of Unicode and edge closer to giving authors hinting tools.

I'd start with line breaking.  Disabling line breaking is an extremely common request[1].  

The rest of the list is pretty short: Soft breaks would also be a nice feature (so that you can break X_Y_Z at underscores to keep wide tables tight).  Emphasis/monospace is also something I'd want to fix (Carsten's <tt bugbear).  Widow/orphan control would be nice, but I have less of a good handle on that (and the need is diminished given our current output format status) so it can probably sit unattended for a good long time.

--Martin

[1] Almost 100%, even: the BCP 14 boilerplate includes a non-breaking space between the "BCP" and the "14" in most RFCs, which I don't like.  But "BCP 14" would otherwise wrap in the text output and that is not cool.