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

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.

Aharon



On Sun, Aug 29, 2010 at 2:17 PM, Aharon (Vladimir) Lanin
<aharon@google.com>wrote:

> 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/>
>>>>
>>>
>>>
>>
>