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

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

Received on Tuesday, 14 September 2010 23:48:24 UTC