Re: W3C test html5-014: another space that vanished?

> Arguably, the space after the b is, in character order, before a
linebreak, and should disappear.
> On the other hand, it is not visually next to a linebreak.

http://www.w3.org/TR/css3-text/#white-space-rules says that "A sequence of
collapsible spaces at the end of a line is removed." However, this is after
"Inlines are laid out, taking bidi reordering into account". So, does
"spaces at the end of a line" mean logically or visually? I am pretty sure
that it means logically, but I agree that it is not very clear. If it
supposed to be logical, the test is correct.

Please note that previously, due to the UBA's L1, there was never a
difference between logical and visual here. However, after <bdi>, L1 no
longer smudges that differences; see below.

> Also, how does one apply bidi rule L1 in the case of a <bdi>?

You have to keep in mind that the UBA does not know anything about mark-up
generally or <bdi> in particular. By the rules of <bdi>, the various phases
of the UBA need to be applied on the text around the <bdi> as if the whole
<bdi> were U+FFFC, and on the text inside the <bdi> in a separate UBA call.
The first phase is
http://unicode.org/reports/tr9/#Resolving_Embedding_Levels. The second
phase, which includes L1, is
http://unicode.org/reports/tr9/#Reordering_Resolved_Levels. When the second
phase is applied to the <bdi> in our example, the space is not even passed
to the UBA because http://www.w3.org/TR/css3-text/#white-space-rules kills
it. But let's say that we used CSS to apply text-space-collapse:preserve to
the <bdi>. The space would then be preserved. The application of L1 would
only serve to force the space to the base direction of the <bdi>, *not* the
base direction of the text surrounding it. Thus, in the presence
of text-space-collapse:preserve on a <bdi>, a space logically at the end of
a line may wind up being displayed in the middle of the line, despite L1
having been applied. This is actually the way it is implemented in Firefox.
Try these in Nightly:

data:text/html,<html dir=rtl><div style="white-space:pre">&%23x05d0; <span
dir=ltr>b </span></div></html>
data:text/html,<html dir=rtl><div style="white-space:pre">&%23x05d0; <span
dir=rtl>b </span></div></html>
data:text/html,<html dir=rtl><div style="white-space:pre">&%23x05d0; <bdi
dir=ltr>b </bdi></div></html>
data:text/html,<html dir=rtl><div style="white-space:pre">&%23x05d0; <bdi
dir=rtl>b </bdi></div></html>

This was not foreseen when <bdi> was defined, but I do not think that it is
all that terrible. Trailing whitespaces at the end of a an
opposite-direction <span> or <bdi> are a bad idea anyway, since when these
are in the middle of a line, where L1 can not help them anyway, either will
result in two spaces visually next to each other. For example, see:

data:text/html,<html dir=rtl><div style="white-space:pre">&%23x05d0; <span
dir=ltr>b </span>&%23x05d2;</div></html>

If so, I do not think that they need special protection when at the end of
a paragraph, as in the preceding examples. On the other hand, I would hate
it if a space in the middle of a <bdi> got rendered in the middle of the
line. However, we already saw that
http://www.w3.org/TR/css3-text/#white-space-rules prevents that when
white-space is collapsable. In fact, it also prevents it when white-space
is not collapsible but line wrapping is still allowed: "If spaces or tabs
at the end of a line are non-collapsible but have ‘text-wrap’ set to
‘normal’ or ‘avoid’ the UA may visually collapse their character advance
widths." This "may" is actually implemented in Firefox Nightly and WebKit:

data:text/html,<html dir=rtl><div style="white-space:pre-wrapped;
width:20px;">&%23x05d0; <span dir=ltr>b c</span> &%23x05d3;</div></html>
data:text/html,<html dir=rtl><div style="white-space:pre-wrapped;
width:20px;">&%23x05d0; <span dir=rtl>b c</span> &%23x05d3;</div></html>
data:text/html,<html dir=rtl><div style="white-space:pre-wrapped;
width:20px;">&%23x05d0; <bdi dir=ltr>b c</bdi> &%23x05d3;</div></html>
data:text/html,<html dir=rtl><div style="white-space:pre-wrapped;
width:20px;">&%23x05d0; <bdi dir=rtl>b c</bdi> &%23x05d3;</div></html>

The bottom line: http://www.w3.org/TR/css3-text/#white-space-rules is not
very clear, but if read as I believe it was intended to be read, it ensures
that wrapping does not produce logically non-contiguous spaces visually
next to each other, even in the presence of non-collapsible spaces in a
<bdi>, despite L1 not being very relevant when appled to a <bdi>.

Aharon


On Tue, Apr 3, 2012 at 8:12 PM, Eric Muller <emuller@adobe.com> wrote:

>  On 3/29/2012 5:14 PM, Eric Muller wrote:
>
> The input starts with:
>
> <div>&#x5d0; &gt; <bdi>b &gt;&gt;&gt;&#xa0;&#xa0;
>
> and the expected output starts with:
>
> b < &#x5d0;
> >>>
>            So the test is constructed to produced a linebreak just before
> the ">>>". On the first line, there is a space after the >, and one after
> the b. Neither is at the end of the line, so both should remain. Shouldn't
> there be two spaces between b and <?
>
>
> Any ruling on that one?
>
> To avoid problems with mailers:
>
> <div>&#x5d0;&#x20;&gt;&#x20;<bdi>b&#x20;&gt;&gt;&gt;&#xa0;&#xa0;
>
> Arguably, the space after the b is, in character order, before a
> linebreak, and should disappear. On the other hand is not visually next to
> a linebreak. I suspect that the question can be rephrased on a slightly
> more compact example:
>
> <div>&#x5d0;<bdi>a&#20;b</bdi>&#x5d1;</div>
>
> Also, how does one apply bidi rule L1 in the case of a <bdi>?
>
> Thanks,
> Eric.
>
>

Received on Tuesday, 3 April 2012 21:20:46 UTC