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

> I'm thinking more about form controls, and I think 'plaintext' should
> not be requiring dir=auto. In most cases, you want to use the inherited
> direction for styling the form control: you don't want margins and
> borders suddenly shifting around because the user has entered RTL text,
> you want them to remain steady and match the surrounding UI's direction.
> What you want to shift is only the base paragraph direction and the
> text's horizontal alignment-- and "unicode-bidi: plaintext" alone will
> handle for you.

I am not sure what you mean here. Form controls? Could you give an example?

Aharon

On Wed, Sep 15, 2010 at 1:47 AM, fantasai <fantasai.lists@inkedblade.net>wrote:

> On 09/14/2010 02:35 PM, Aharon (Vladimir) Lanin wrote:
>
>>
>> I assume that the parts that to which you object are the ones you then
>> mentioned (which I list below), while everything else (e.g. adding the
>> uba - or plaintext - value to the unicode-bidi CSS property) is ok.
>>
>
> I already put it in the spec right after the F2F, so yes. :)
>
>
>   If uba cannot in fact be triggered on anything
>>>  other than a <textarea>, then it should not be allowed on anything other
>>>  than a <textarea>. I suggest having
>>>  dir=ltr|rtl|auto|plaintext
>>>  autodirmethod=first-strong|any-rtl
>>>
>>
>> I presume you mean that dir=plaintext is ignored on elements other than
>> <textarea>.
>>
>
> Ignored and invalid, yes.
>
>
>  Also, unicode-bidi:plaintext is ignored (i.e. treated as
>> unicode-bidi:normal) on elements other than <textarea>.
>>
>
> You cannot disable CSS functionality on a per-element basis, only on a
> per display type basis. <textarea> is not a special display type.
>
> As currently defined, unicode-bidi: plaintext, like unicode-bidi:
> bidi-override, only affects text directly contained within a
> block-display box, not the contents of any descendant block-display
> boxes.
>
>
>  In my opinion, having both dir=auto and dir=plaintext, especially when
>> there is also autodirmethod, seems clunky to me. What's wrong with
>> having just dir=auto, with plaintext being one of the autodirmethod
>> values?
>>
>
> I'm fine with that as long as it's only a valid value for <textarea>,
> i.e. triggers a validation error and otherwise has no effect on
> anything else.
>
> I'm thinking more about form controls, and I think 'plaintext' should
> not be requiring dir=auto. In most cases, you want to use the inherited
> direction for styling the form control: you don't want margins and
> borders suddenly shifting around because the user has entered RTL text,
> you want them to remain steady and match the surrounding UI's direction.
> What you want to shift is only the base paragraph direction and the
> text's horizontal alignment-- and "unicode-bidi: plaintext" alone will
> handle for you.
>
> Also I'm still concerned about expanding 'plaintext' to <pre>. I think
> we do need that, for display of plaintext emails in mail archives and
> webmail clients, for example. They are not going to use <textarea
> readonly> because it's got scrollbars, doesn't paginate when printing,
> and is not fully styleable. I think the pathological cases you're
> concerned about wrt margin-start etc. should not be our concern
> here: people styling <pre> text with margins and suchlike should be
> doing the work to split the text into real <p> paragraphs. Our concern
> should be the common case, which is plain text with font and color
> styling and maybe some text-decoration.
>
> If we are addressing <textarea>, we can't not similarly address <pre>:
> one is used to edit and view the other.
>
> ~fantasai
>