Re: <br> as paragraph separator

> >  Regardless of what <br> is supposed to be, authors
> >  usually assume it is the equivalent of a newline in
> >  plain text, and bidi users (but not monodirectional
> >  users!) are very unpleasantly surprised when it does
> >  not behave the same way.

> What newline does in plain text depends on the
> application and operating system, and is often
> surprising by itself.

The bidi effects of newline and carriage return and their combinations (as
well as other B-class characters) in a plain text are definitively specified
by the Unicode standard and implemented that way on every significant
platform I know.

> The expectations of MS Word users are different than those of GNU Emacs
users, etc.

I am not talking about what any particular app does when a user hits the
Enter key. That is the app's business. I am talking about the bidi effects
of a newline in a plain text document. A Word document, of course, is not
plain text.


On Thu, Dec 16, 2010 at 1:05 AM, Amit Aronovitch <aronovitch@gmail.com>wrote:

>
> On Wed, Dec 15, 2010 at 11:30 PM, Aharon (Vladimir) Lanin <
> aharon@google.com> wrote:
>
>> > In IE7, and IE8 and IE9 Beta in quirks mode, <br>
>> > is treated as a paragraph separator. However, in
>> > IE8 and IE9 in standards mode, it is treated as a
>> > line separator and does not end the bidi paragraph.
>>
>> Wow! I had not noticed this.
>>
>> I guess standards really means standards, which is good. And they can
>> always fall back on quirks and "strict" mode, to keep existing documents
>> from breaking.
>>
>> The question is whether this means that the change re <br> in HTML5 should
>> be rolled back.
>>
>> My gut feeling is it should not. Regardless of what <br> is supposed to
>> be, authors usually assume it is the equivalent of a newline in plain text,
>> and bidi users (but not monodirectional users!) are very unpleasantly
>> surprised when it does not behave the same way.
>>
>
> What newline does in plain text depends on the application and operating
> system, and is often surprising by itself. The expectations of MS Word users
> are different than those of GNU Emacs users, etc. Any way you do it, there
> will be some people more surprised than others, and I have no clue exactly
> which audience you should target.
>
>
>> Using <p> and </p> is challenging in many scenarios, and so the use of
>> <br> where <p> really should have been used is rampant. As a result, it is
>> that much more difficult to work bidi support into web apps, since they must
>> be changed to stop using <br> as a paragraph separator. This request is
>> often treated as unreasonable and never implemented.
>>
>
> If the standard is clear enough, and if web authors want to write HTML5
> compliant sites, there should be no problem with their new sites.
> The bidi problems would always remain for HTML4 sites, but there is nothing
> HTML5 can do about it.
>
> There is no point in forcing the standard to follow some behavior only
> because it is a strong market trend.
> If you do that too often, there would be no incentive for people to follow
> standards. Why spend time on making your site HTML5 compliant, when if you
> follow the strongest market trend instead, it would probably BECOME the
> standard in HTML6?
>
>
>> Thus, IMO, we should leave HTML5 in its present state, i.e. with <br> as a
>> paragraph separator. Since standards seem to be being followed in standards
>> mode, I hope that IE9 will revert to the old behavior.
>>
>> However, I would be very interested in hearing others' opnions, in both
>> directions.
>>
>>
> As I already said, I do not like the current situation. At the current
> state of things, my opinion is that it would be best if <br> is deprecated
> and, in due time, completely removed from HTML.
>
> This can be done gradually: at first stage (HTML5), the standard should
> MANDATE implementation of unicode entities for (both) LS and PS in any
> visual browser - these should be used by CSS (or other display mechanism) to
> control the flow of lines. In addition, at the description of <br>, a remark
> should be added that this is a feature kept for backwards compatibility and
> easing migration, and that <br> is not recommended in new sites (use either
> <p> or the LS/PS entities instead).
> The next release (5.9? 6.0?) would completely remove it.
> If this suggestion is accepted - I think (not sure though) that the current
> fix should be reverted (this is in light of Simon Montagu's recent findings
> - backwards compatibility is a tricky thing...).
>
> Since my time is limited right now, I intend to try pushing this suggestion
> via the bugzilla system in January - unless you people convince me
> otherwise.
>
>
>> > Even more surprisingly, in IE8 in standards mode,
>> > a line break in preformatted text is also treated as
>> > a line separator.
>>
>> Bug.
>>
>> > IE9 Beta has reverted to treating it as a paragraph
>> > separator.
>>
>>
> Is that in standards mode or in quirks?
>
>
>>  Good.
>>
>> > I also discovered strange behaviour in Safari 5.0.3:
>> > if a <br> or line break in preformatted text is followed
>> > by a rtl embedding, e.g.
>> > <div>ltr RTL,<br><span dir="rtl">MORE RTL</span></div>
>> > the comma at the end of the first line is rendered to the
>> > left of the rtl text, as if there were another rtl character
>> > following it.
>>
>> Very strange. Also happens in Chrome. Looks like a WebKit bug.
>>
>>
> Apologies for being more argumentative than informative (theoretical
> arguments are less time consuming than actually checking up stuff :-) )
>
>    AA
>
>