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

[Henrik Levkowetz <[e-mail]>]

On 2018-10-03 13:58, Julian Reschke wrote:
> 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).

Yes, I've run that through the current text processor, and I particularly
looked at it when working on table rendering.

Where is it you need <br> to make this come out right?

>>> 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).

So the conclusion would be to eliminate <br>, then ...

>> 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>.

Understood.  I still don't see the problem with permitting <br> generally --
the argument about going to artwork has some validity also for body text
if people can't get the output they want.


Best,

	Henrik