[Bug 11211] Need a way to force a line wrap with the bidi semantics of LINE SEPARATOR when necessary.


Amit Aronovitch <aronovitch@gmail.com> changed:

           What    |Removed                     |Added
                 CC|                            |aronovitch@gmail.com

--- Comment #16 from Amit Aronovitch <aronovitch@gmail.com> 2010-11-12 17:44:24 UTC ---
(In reply to comment #13)
> I talked to fantasai about this in #css earlier.
> I recommend that we try using &#x2028; for now, and see where that gets us.
> Since the CSS layer doesn't yet support this, there's not much we can do right
> now. If &#x2028; works, then we can get the MathML WG to add a &ls; named

Was that a typo? AFAIK MathML has nothing to do with this. Maybe XML WG?
Can't/shouldn't html add entities beyond the predefined XML set? (I do not know
- this is for my general knowledge...)

> charref for us in the future to make it more usable. If it doesn't, we can try
> to find a better solution (like a new element). I'm a little reluctant to add
> an attribute to <br> for this because I can't really come up with a good name
> and any name longer than three characters is longer than "&#x2028;" would be.

How about <br ubi> as suggested by Aharon in bug 10828, comment 22?

As for later comments - I'm not sure I understand the current direction: was
the intention to: (a) Add some new attribute/element and use &#x2028; in the
specification of its required behaviour? 
or: (b) Add nothing new, and have the content-authors implement the linebreak
&#x2028; ?

I must say that I do not like option (b).

The objections that Ian raised on comment 11 are probably correct: <br> *is* a
presentational thing, which causes all use cases to be some sort of "abuse".
But the same can be said about the parabreaking <br> (bug 10828).

Now, it seems that we are going to keep <br> in HTML despite that (this seems
to be a concensus, apparently for practical reasons), but decide to *change*
its behavior, to match one sort of "abusive" usage (re: comments 8 and 11: for
usecases we should probably search Mozilla bug-reports), and not the other
(usecases in comments 7 and 10). For one thing, this is aesthetically awkward.
Furthermore, from the POV of those browser-makers that stuck to HTML4 standard
despite pressure from their customers, it would seem like the standards are
following implementation (so why should they want to keep following it?).

If it is in the scope of HTML to *require* implementation of entities, then a
possible solution would be to require compliant application to properly handle
both U+2028 and U+2029, and to add a comment in the <br> spec, saying that
users should prefer using U+2029 (or better yet, named entity e.g. &ps;)
instead of <br> ( or using U+2028 (or named entity e.g. &ls;), for the usecase
described in this bug).

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Friday, 12 November 2010 17:44:28 UTC