[rfc-i] draft-iab-xml2rfc-03, "2.12 <br>"

[julian.reschke at gmx.de (Julian Reschke)]

On 2016-05-11 16:19, Paul Hoffman wrote:
> On 10 May 2016, at 21:34, Julian Reschke wrote:
>
>> On 2016-05-11 02:24, Paul Hoffman wrote:
>>> ...
>>>> Other than that:
>>>>
>>>> - What is "It is always expressed as <br />" about?
>>>
>>> So that we do not have the common problem in HTML that people use <br>
>>> unclosed.
>>
>> a) That is not a problem in HTML, it's actually the right way to do
>> it. It *is* a problem in XHTML.
>>
>> b) Why call out <br/>? We are in XML land, this applies to *any* empty
>> element.
>
> Yes, but <br> is one that is known to many folks from HTML editing. The
> text is here to prevent expected common mistakes by novices; I think it
> is reasonable to do so.

IHMO it's both incorrect (the following are just fine: "<br/>" and 
"<br></br>"), and misleading, as the problem you're referring to is very 
specific to serving XHTML content as text/html to ancient browsers.

>>>> - "Multiple successive instances of this element do not cause blank
>>>> lines to appear in the output, and is thus not useful." -- maybe "are
>>>> not useful" - or just state that they'll be ignored?
>>>
>>> Good call: ignored.
>>>
>>>> What if there's whitespace in between, such as with "<br/> <br/>"?
>>>
>>> Yeeps. That would indeed be a way to insert blank lines in a cell. I
>>> guess we should allow that in order not to create an arms war with
>>> people who want blank lines in their cells.
>>>
>>> Proposed:
>>>
>>> Multiple successive instances of this element are ignored. Successive
>>> instances with an
>>> intervening white space (such as "&lt;br /&gt; &lt;br /&gt;") will
>>> create a single blank line.
>>
>> Devils advocate: does this apply to *any* Unicode whitespace character?
>
> Any that is allowed in XML input in our tools, yes.
>
>> Proposal: don't try to prevent this on the vocabulary level; but maybe
>> mention that if you want a single empty line, "<t>" is the thing to use.
>
> Note that I didn't try to prevent it. That's the point of the addition.

But the addition puts additional burden on formatters - are they 
supposed to be aware of all whitespace-y Unicode code points? I would 
recommend to just drop this.

Best regards, Julian