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

>> 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 suspect this is unnecessarily difficult to implement, because it
> means that partway through processing an element I'd have to go back
> and change whether I'm doing per-paragraph or first-strong.

Perhaps there was a misunderstanding. What I meant was that the check for
children elements would be made at the time that dir=uba is encountered on
an element, before any content has been processed. I guess this assumes a
DOM-like representation where it is possible to look ahead - I am not sure
if that is a problem. I certainly did not mean that the browser would have
to go back and change anything when it starts to process the child element.

>> <pre dir=uba>
>>
>> an ltr line (and thus uba paragraph).<input type=button
>> value="b1" style="margin-start:20px" /><input type=button
>> value="b2" style="margin-start:20px" />
>>
>> AN RTL LINE (AND THUS UBA PARAGRAPH).<input type=button
>> value="B3" style="margin-start:20px" /><input type=button
>> value="B4" style="margin-start:20px" />
>>
>> </pre>
>>
>> B3 and B4 would inherit the CSS direction of their parent, i.e. <pre
>> dir=uba> element, which would be ltr due to the way its content
>> begins. Will B3 and B4's margins be on their left or their right? If
>> it's on the left, as per their CSS direction, they will not do what
>> the author intends, which is to put a bit of space between the button
>> and what precedes it. And if it's on the right, the definition of start
>> and end becomes quite esotoric, no longer depending on the CSS
>> direction, but on the paragraph direction, which scripts can't even
access.

> margin-start would be margin-left, since those input elements have
> inherited an ltr direction. If the author wants proper control of
> presentation, he should be using proper markup.

The problem that I was trying to point out is that the proper mark-up in
this case is misleading and difficult to use.

> Note that the lack
> of spacing problem is present in
>
> AN RTL LINE (AND THUS UBA PARAGRAPH).<input type=button
> value="B3" style="margin-start:20px" /><input type=button
> value="B4" style="margin-start:20px" /> MORE RTL TEXT
>
> regardless of whether the paragraph direction is set correctly or not.

In that case, I would have authored it to have a margin-end as well as a
margin-start. And the original problem still exists if margin-end and
margin-start do not have the same value.

> Note also that <pre> is not allowed to contain <input> elements.

This is obviously a tangent, but is that really so? From the 4.01 spec, I
see that PRE allows inline elements except for IMG|OBJECT|BIG|SMALL|SUB|SUP.

> Also, I should mention, it might make sense for dir=uba to be restricted
> to <pre> and <textarea> elements (where it would do per-paragraph) and
> to inline elements (where it would be the same as first-strong).

I agree that <pre> and <textarea> are what we are mostly after. However, I
am not really sure what the restriction as stated above achieves:

- I don't see anything inherently "safe" about the <pre> element. The
problem I pointed out above appears as soon as direction-aware mark-up like
the CSS *-start properties occurs inside the <pre>.

- Inline elements are allowed to contain <br>, which (per the proposal)
constitutes a UBA break (by default), so I see no particular reason to
differentiate between inline elements and block elements. We could just as
successfully define dir=uba to act as first-strong on all elements except
<pre> and <textarea>, I think.

- Preformatted text is often displayed using white-space:pre on an element
other than <pre>. This as the advantage of allowing control over the font,
minimum spacing around <pre>, and so on. If we can do per-paragraph
direction on <pre> (which, as I said above, I am not sure we can without
further restrictions), I don't see why we can't do it on other elements.

>> If dir=uba is going to have the same meaning as first-strong for
>> inline elements, then why should it be allowed on those elements at
>> all?
> The only reason I suggest that is because it should be possible to get
first-strong
> on an inline element.

There should indeed, but there are ways to achieve this other than dir=uba.
We never got around to discussing at the f2f whether dir=auto would mean
specifically the "statistic" algorithm (e.g. char-count). The alternative,
as proposed in discussions prior to the f2f, is that dir=auto would mean the
algorithm specified by the autodirmethod attribute, which would be
inherited. Thus, setting autodirmethod on some element would set the
estimation algorithm for any elements with dir=auto below that. The values
allowed by autodirmethod would include first-strong and any-rtl. If and when
we succeed in making a persuasive case for some specific statistic algorithm
(e.g. char-count with some specific, defensible coefficients for different
scripts), then that would be included as well. And if, at some stil llater
date, a new and truly brilliant estimation algorithm is discovered, it could
be added that way as well.

For that matter, if dir=uba is restricted in one of the ways suggested so
far, autodirmethod values could also include uba, I think, instead of a
separate dir=uba value. That would be nicer than having both auto and uba
values for the dir attribute.

> Since there seems to be considerable disagreement re dir=uba, maybe that
can
> be removed from the current draft proposal and reconsidered separately
later?

Unless we get somewhere really soon, this will probably have to be the case.

Aharon

On Fri, Sep 3, 2010 at 9:34 PM, fantasai <fantasai.lists@inkedblade.net>wrote:

> On 09/02/2010 08:31 PM, Ehsan Akhgari wrote:
>
>> On Thu, Sep 2, 2010 at 2:14 PM, fantasai<fantasai.lists@inkedblade.net>
>>  wrote:
>>
>>> Also, I should mention, it might make sense for dir=uba to be restricted
>>> to<pre>  and<textarea>  elements (where it would do per-paragraph) and
>>> to inline elements (where it would be the same as first-strong).
>>>
>>
>> If dir=uba is going to have the same meaning as first-strong for
>> inline elements, then why should it be allowed on those elements at
>> all?
>>
>
> The only reason I suggest that is because it should be possible to get
> first-strong
> on an inline element.
>
> If we go with the idea that dir="uba" means "behave like a standalone piece
> of plaintext" then it's consistent with that idea.
>
> ~fantasai
>