W3C home > Mailing lists > Public > public-i18n-bidi@w3.org > July to September 2010

Re: per-paragraph auto-direction, a.k.a. dir=uba

From: Aharon (Vladimir) Lanin <aharon@google.com>
Date: Wed, 1 Sep 2010 21:02:14 +0300
Message-ID: <AANLkTikrdY=60ddJDQAYFDd3Gsk=XeA0Zg3QvQQUxTp7@mail.gmail.com>
To: Ehsan Akhgari <ehsan@mozilla.com>
Cc: Behdad Esfahbod <behdad@behdad.org>, Adil Allawi <adil@diwan.com>, Shachar Shemesh <shachar@shemesh.biz>, public-i18n-bidi@w3.org, "Phillips, Addison" <addison@lab126.com>
I've had sufficient negative feedback on suggesting a new element to kill
that idea.

So, what do people think of the proposal that there is no restriction on the
elements on which dir=uba can appear, but it will act as first-strong (not
per-paragraph) on any element that has any child elements, and only work in
the per-paragraph mode otherwise?

I am looking for any feedback at all, since I am not sure whether this is
something people actually want, and if not, whether they want some form of
per-paragraph direction, or are happy enough without dir=uba at all.


On Sun, Aug 29, 2010 at 2:17 PM, Aharon (Vladimir) Lanin

> Yet another possibility is to forego <plaintext>, but specify that dir=uba
> only works in the per-paragraph mode when the element does not have any
> children that are elements (i.e. it congtains no mark-up). Otherwise, it
> falls back to first-strong (i.e. gives all its UBA paragraphs the same
> direction). I am pretty sure that this would be quite simple to implement,
> but have no idea if such a definition would fly in a spec.
> BTW, script can display some plain text in a <pre> (with or without
> dir=uba) using the textContent property (except in IE, where one has to use
> innerText...).
> Aharon
> On Sun, Aug 29, 2010 at 1:43 PM, Aharon (Vladimir) Lanin <
> aharon@google.com> wrote:
>> So, should I include the <plaintext> version of dir=uba in the next draft
>> of the proposal?
>> Aharon
>> On Thu, Aug 26, 2010 at 10:41 AM, Aharon (Vladimir) Lanin <
>> aharon@google.com> wrote:
>>> They would be quite different. <textarea readonly>:
>>>    - is an inline element
>>>    - has size controlled by rows and cols attribute; in some browsers,
>>>    can be resized by the user
>>>    - is submitted with form
>>>    - receives focus and appears in taborder
>>>    - has a border
>>> On the other hand, <pre>:
>>>    - is a block element
>>>    - sized the same way as a div, e.g. can be minimal size needed to
>>>    display content.
>>>    - is not submitted with forms
>>>    - does not receive focus or appear in taborder
>>>    - does not have a built-in border
>>> In all these respects, I would want the new element to be like <pre>,
>>> since it is meant for the display of (pre-formatted plain-text) data. The
>>> only way it is similar to <textarea> is that it does not allow mark-up and
>>> has a modifiable value property.
>>> Aharon
>>> On Wed, Aug 25, 2010 at 9:09 PM, Ehsan Akhgari <ehsan@mozilla.com>wrote:
>>>> On Wed, Aug 25, 2010 at 10:02 AM, Aharon (Vladimir) Lanin
>>>> <aharon@google.com> wrote:
>>>> > <textarea> allows user input, has the look and feel of an input (e.g.
>>>> the
>>>> > border around it), and serves as a field in a form.
>>>> >
>>>> > The new element is for display only, like <pre>.
>>>> But textarea's already support all of the features that you have in
>>>> mind.  Example:
>>>> data:text/html,<textarea readonly
>>>> style="border:none;overflow:none;resize:none">foo&#10;bar&#10;baz</textarea>
>>>> I don't think that we should add a new HTML element, unless there's a
>>>> compelling reason to do so.
>>>> --
>>>> Ehsan
>>>> <http://ehsanakhgari.org/>
Received on Wednesday, 1 September 2010 18:03:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:24:37 UTC