Re: per-paragraph auto-direction, a.k.a. dir=uba (was: meeting results - f2f on additional requirements for bidi in HTML)

On Mon, Aug 23, 2010 at 11:09 AM, Aharon (Vladimir) Lanin
<aharon@google.com> wrote:
> - Is there a large pool of pre-existing multi-paragraph plain data that
> needs dir=uba to be displayed correctly? To exist, it must have been created
> in an editor that displays each paragraph in the direction of its first
> string character. However, no Microsoft product of which I am aware supports
> this feature. The only mass-market editors I know that do support it are
> gedit and some Mac editors. These products are not all that well-known among
> RTL users. Thus, I tend to doubt that such a large pool of data already
> exists.

I agree that it's probably not realistic to assume that such a large
pool of plain text data exists.

> - Where such a pool of data does exist, it is easy enough to preprocess it
> for display in <pre> by dividing into paragraphs at each B-class character
> and wrapping each paragraph in a <div dir=auto
> autodirmethod="first-strong">.

This is, I think, the main point here.  This can't be done entirely in
the markup level, which is kind of unfortunate, but I don't believe
that we should be aiming to support every conceivable use case at the
markup level.

> - While bidi users indeed often do want to enter a multi-paragraph piece of
> text where some paragraphs are LTR and some RTL, sites can already address
> this by using a rich text editor widget for such data instead of a
> <textarea>. For example, TinyMCE (http://tinymce.moxiecode.com/) is an
> excellent rich-text editor control available for free that allows the user
> to explicitly control the direction of each paragraph. <textarea> is not
> exactly a super-cool feature.

Agreed.

> To summarize, I think that the feature is too complicated to justify in the
> absence of overwhelming need. I think that we simply got carried away at the
> f2f, and proposing the feature to broader circles will harm the overall
> proposal's chances for acceptance and implementation.

I agree with Aharon in that the feature as discussed in the f2f
meeting is overly complex, and I'm not convinced that it brings enough
value in order to be included in this specification.  Therefore I'd
like to support retracting it from the proposal.

Cheers,
--
Ehsan
<http://ehsanakhgari.org/>

Received on Monday, 23 August 2010 17:44:14 UTC