Re: [xml2rfc-dev] RFC 7991 issue #37: Schema Issue, RFC 7991, In Section 2.12, <br>

[Julian Reschke <[e-mail]>]

On 10/3/2018 1:49 PM, Henrik Levkowetz wrote:
> ...
>> How did you arrive at 30?
> 
> That's an arbitrary choice.  Insert your choice of width, and remember
> that when rendering body text to html on a small device, the case could
> be similar to the case for a table cell.

While that is true for narrow screens (smart phone), it's not really a 
good argument in this context: you don't want to have an *enforced* line 
break - it would affect "regular" rendering as well.

>> Table cells can get very narrow, like just a few characters, and in that
>> case it can be desirable to control line breaks.
> 
> No, it doesn't help the argument that you repeat the statement.
> 
> I seriously want to be shown examples where <br> makes sense in a cell
> and not in body text.
> ...

<https://greenbytes.de/tech/webdav/rfc2629xslt/v3test.xml#n-rfc-7541> is 
an example copied from a real table in an RFC (which back then used 
<artwork> though).

>> FWIW, HTML5 *allows* <br> in many places, but says clearly that it's
>> only to be used when the line break has semantic meaning, such as in a poem.
> 
> But doesn't that approach make more sense that the current limitation?

Well, the examples given in the HTML spec do not seem to occur in RFCs 
normally (poems, line breaks in addresses, for which we have other 
notation).

> Please note that my suggestion was to either remove <br> altogether, or
> permit it in inline context consistently.  I don't care that much about
> which choice we make, but I still haven't seen any concrete example that
> shows why it makes sense to disallow it in one context, and not the other.

My concern is that when people can't get the table output they want, 
they'll fall back to artwork, which isn't helpful. See 
<https://greenbytes.de/tech/webdav/rfc7541.html#huffman.code>.

Best regards, Julian