Re: [Bug 10828] i18n comment 4 : new attribute: bidibreak

Entities alone will not do the trick, since HTML 4 specifically excluded
support for U+2028 and U+2029. I am ok with supporting these as an
alternative to a soft <br>, but it seems to me that <br ubi> - provided that
ubi is actually accepted - would be sufficient.

Aharon

On Wed, Oct 20, 2010 at 8:00 PM, Amit Aronovitch <aronovitch@gmail.com>wrote:

> (just an idea - not replying in bugzilla, because I'm not entirely sure it
> is a good one)
>
> Seems like the gatekeepers are willing to change the spec of <br> to become
> "hard" (like ie/webkit),
> but are reluctant to add a new attribute, or even a new element, which
> would make the soft break functionality available,
> suggesting &#x2028; as an alternative (i.e. adding to the spec a
> requirement that it should be supported).
>
> A possible compromise might be to add named entities, perhaps &sbr; (soft
> break) or &vbr; (visual break) for U+2028, and &br; for U+2029 (this might
> increase the chance that browser-makers would actually add support for these
> characters).
>
> Personally, I think that poetry and addresses alone (not to mention other
> use cases mentioned in the bug) are good enough use cases for adding the
> missing functionality as a 1st class citizen (element or attribute). At
> least it seems that it was important enough to be added to early versions of
> HTML.
>
> Amit
>
>
> On Wed, Oct 20, 2010 at 11:31 PM, <bugzilla@jessica.w3.org> wrote:
>
>> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10828
>>
>> Adil <adil@diwan.com> changed:
>>
>>           What    |Removed                     |Added
>>
>> ----------------------------------------------------------------------------
>>                 CC|                            |adil@diwan.com
>>
>> --- Comment #18 from Adil <adil@diwan.com> 2010-10-20 21:31:56 UTC ---
>> (In reply to comment #17)
>> > If this request is just to change the <br> element's definition to match
>> IE,
>> > then that is definitely something we can do. Should I just change the
>> spec to
>> > instead say "A br element must separate paragraphs for the purposes of
>> the
>> > Unicode bidirectional algorithm. [BIDI]" ?
>>
>> I would like to see <br> defined as paragraph separator by default.
>> However,
>> this alone does not solve a specific use case that affects my work. I am
>> developing a web app that displays text extracted from a book or a
>> newspaper in
>> a similar way to this site:
>> http://newspapers.nla.gov.au/ndp/del/article/1118868.
>>
>> The requirement is to match exactly the line breaks in the original
>> document
>> regardless of the font width. The problem is, for mixed rtl-ltr text, I
>> need to
>> insert a line break that is not a bidi paragraph break.
>>
>> If <br> is redefined as a bidi paragraph break instead of a line-break
>> then, in
>> this case, the <br> will give the wrong reordering for the broken line.
>>
>> --
>> Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
>> ------- You are receiving this mail because: -------
>> You are on the CC list for the bug.
>> You reported the bug.
>>
>>
>