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

> Browsers have to deal with incremental rendering,
> meaning that they start rendering a document before it has completely
> loaded. It does not make sense for bidi resolution of a block of text
> to change if an element happens to load in later.

On the face of it, this seems to make any kind of dir=auto (not just uba)
difficult, since the first few descendant nodes received may not contain
decisive content.

So, do we have to get rid of dir=auto or uba completely?

And if not, should we resurrect uba for elements with no child elements, not
just <textarea>?

Aharon

On Mon, Sep 13, 2010 at 8:15 PM, fantasai <fantasai.lists@inkedblade.net>wrote:

> On 09/13/2010 04:31 AM, Aharon (Vladimir) Lanin wrote:
>
>>  >> 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.
>>
>
> This is not the case. Browsers have to deal with incremental rendering,
> meaning that they start rendering a document before it has completely
> loaded. It does not make sense for bidi resolution of a block of text
> to change if an element happens to load in later.
>
>
>   >> <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.
>>
>
> The proper markup is to mark each paragraph independently in a <p>
> instead of relying on <pre>. I don't think that is misleading at all.
>
>
>   > 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.
>>
>
> Hm, you are correct. Not sure why I missed that.
>
>
>   > 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>.
>>
>
> I don't think the problem you point out is that significant. What's
> safe about the <pre> element is that it is not allowed to contain
> other block elements, so the fact that uba behavior doesn't inherit
> is not a problem.
>
>
>  - 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.
>>
>
> Inline elements can contain forced breaks, sure, but that doesn't mean
> they should have any role in determining the paragraph base direction.
> 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.
>
>  - 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.
>>
>
> I don't understand your point here. <pre> is exactly as formattable as <p>.
> It just has a different default styling.
>
> ~fantasai
>