W3C home > Mailing lists > Public > public-i18n-bidi@w3.org > July to September 2010

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

From: fantasai <fantasai.lists@inkedblade.net>
Date: Mon, 13 Sep 2010 11:15:51 -0700
Message-ID: <4C8E6A57.8000803@inkedblade.net>
To: "Aharon (Vladimir) Lanin" <aharon@google.com>
CC: public-i18n-bidi@w3.org, Ehsan Akhgari <ehsan@mozilla.com>, Behdad Esfahbod <behdad@behdad.org>, Adil Allawi <adil@diwan.com>, Shachar Shemesh <shachar@shemesh.biz>, "Phillips, Addison" <addison@lab126.com>
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

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.

Received on Monday, 13 September 2010 18:16:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:24:37 UTC