Re: [xml2rfc-dev] [Ext] Re: [xml2rfc] [Rfc-markdown] <br> is back, was: New xml2rfc release: v2.32.0

[Henrik Levkowetz <[e-mail]>]

On 2019-10-08 23:08, Paul Hoffman wrote:
> On 10/8/19 10:51 AM, Henrik Levkowetz wrote:
>> So that removes dt, em, strong, title and tt.
> 
> Another way to look at this is to say "it does not include them in a new design".

My point was simply to list the ones we didn't agree on.  Does this really
need a quibble?

>> <title> is one of the cases the RPC already ran into, so eliminating that
>> from the list will leave one of their cases unhandled.
> 
> I agree with Julian: putting <br> in a title for various reasons can
> cause various bad side-effects.

Yes, well, there's a need here.  I tried to say that already a year ago.

> Sandy: Can you tell the group what the specific need that the RPC saw
> for <br> in <title>? 
>   
>> The case I made in the original issue #37 still holds:  Limiting <br> too
>> strongly will result in a lot of surprises for authors, when they expect
>> to be able to use <br/>, but the validation fails.  I think this is
>> applicable for em, strong, and tt.
> 
> There is literally no way to avoid surprises for authors in v3, or in
> v2. Document formatting always has surprises.

That doesn't mean we should do it harder than it needs to be.  We should
try to consider the needs of the users, not only principles of the design.

>> Additionally, the case Sandy mentioned where the author wanted a piece of
>> text set on two lines is very likely to come up for <tt>, so not permitting
>> <br> there seems wrong.
> 
> <t>
> <tt>This is the first line</tt><br>
> <tt>This is the second line</tt>
> </t>
> .... is exactly the right semantics for what a line break is meant to do.

I'm sorry, but I really cannot see how that is more pure and right than

 <t>
   <tt>
      This is the first line<br/>
      This is the second line
   </tt>
 </t>

I think this is very much a difference in the eye of the beholder.

>   
>> As for dt, it will have similar issues as <title> and <name>.  
> 
> It will also have the same problems.
> 
>> It will only
>> become an issue when the RPC runs into a case where there's a long <dt>
>> text which doesn't display well without <br>.
> 
> This is not about "display well", it is about semantics. One of the
> overarching goals of the v3 work was to have semantically sensible
> long-lived documents that can be displayed in a variety of formats on
> a variety of types of displays.

Unfortunately, a complete semantic model for what RFC authors might want
to express in an RFC would be so complex that we'd probably never complete
it.  Providing escape hatches that lets authors generate text that
communicates their ideas is more important than sticking to a restricting
semantic model for unbounded semantic content.

>> I think the right thing, both for the RPC and authors in general, is to have
>> <br> available everywhere they might end up using it, rather than restricting
>> it too strongly.
> 
> We should hear directly from the RPC about their needs. Also, none of
> us in this conversation are good representatives of typical authors
> of RFCs because we are already too familiar with v2 and v3 and XML
> and so on.

I'm very happy that in this round of comments more people have expressed
a viewpoint than in the previous round.


	Henrik