the elements to which unicode-bidi:plaintext can apply

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

>From the spec (http://dev.w3.org/csswg/css3-text-layout/#unicode-bidi):

> plaintext: [...] the base directionality of each "paragraph" for which the
>element is the containing block element is determined not by the
> element's computed ‘direction’ as usual, but by following rules P1, P2,
> and P3 of the Unicode bidirectional algorithm. [...] Note this value has
> no effect on inline elements.

Just noticed this: <textarea> is formally an inline element!

How can this be fixed?

BTW, here (I think) is your rationale for restricting plaintext to block
elements:

> An inline element can contain the entire contents of a paragraph, or
> a fragment of it, or the last sentence of one paragraph and the first
> sentence of the next. Blocks at least contain a whole number of
paragraphs.
> [...]
> In other words, I don't think it makes sense an inline element to be
> setting the base direction of the paragraph just because it happens
> to wrap around its first few letters.

Well, one way of dealing with this is to make plaintext include the effects
of isolate. Thus, on an inline element, unicode-bidi:plaintext would force
its contents into a separate UBA paragraph (or sequence of UBA paragraphs).

What bothers me more is what the effects of text-align:start|end be on a
display:inline unicode-bidi:plaintext element, since it might contain only
part of a line box.

Come to think of it, I do not see the spec above give any reference to the
effects of text-align:start|end on a unicode-bidi:plaintext generally. It
was supposed to make the line boxes align to the UBA paragraph direction.

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
>