W3C home > Mailing lists > Public > www-international@w3.org > January to March 2014

Re: [css-text] Arabic letters connecting between elements with display: inline

From: Aharon (Vladimir) Lanin <aharon@google.com>
Date: Mon, 10 Feb 2014 14:20:15 -0500
Message-ID: <CA+FsOYbK-Dc8y0vUOUNXLCyQhYxp-V9GrzXhKSabdFrzAmj6vA@mail.gmail.com>
To: fantasai <fantasai.lists@inkedblade.net>
Cc: Simon Montagu <smontagu@mozilla.com>, Behdad Esfahbod <behdad@google.com>, "Amir E. Aharoni" <amir.aharoni@mail.huji.ac.il>, jfkthame@gmail.com, "public-i18n-bidi@w3.org" <public-i18n-bidi@w3.org>, "www-style@w3.org" <www-style@w3.org>, WWW International <www-international@w3.org>
See below


On Fri, Feb 7, 2014 at 3:44 PM, fantasai <fantasai.lists@inkedblade.net>wrote:

> So, probably this thread should be copied over to the bidi and ww-style
> lists. :)
> Adding them and topping off with a summary... and presuming that smontagu
> doesn't
> mind being quoted. ;) Reply here!
>
> The issue is (as the title says) whether Arabic letters connect between
> elements with 'display: inline', for example in this case:
>   <p>foo<span color="blue">bar</span>baz</p>
>

I think that there is little question that this is useful. And, barring
complications like font changes, it works in IE and FF. That it doesn't
work in WebKit and Blink is a bug.


>
> Browsers differ in their behavior. Simon Montagu suspects FF only connects
> if
> they are using the same font (face, style, and weight).
>
> Existing tests/discussion -
> Simple testcase: http://www.unics.uni-hannover.
> de/nhtcapri/temp/nastaliq.html
> Mediawiki bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=60916
> Mozilla bug (resolved WORKSFORME): https://bugzilla.mozilla.org/
> show_bug.cgi?id=236135
> Webkit bug: https://bugs.webkit.org/show_bug.cgi?id=6148
> Chromium bug: https://code.google.com/p/chromium/issues/detail?id=6122
>
> Smontagu notes:
>
>>  I think it would be very reasonable to expect cursive scripts not to
>> connect
>> and shape across boundaries of "block" elements with display: inline, just
>> as we make such elements do bidi reordering in isolation from one another
>> (https://www.w3.org/Bugs/Public/show_bug.cgi?id=10815).
>>
>
> Aharon suggested that we overload 'unicode-bidi: isolate' for this.
> Smontagu pointed out it's not a bidi issue and also affects non-RTL
> scripts.
>
> My take:
> Affecting non-RTL scripts isn't an issue; you can use bidi isolation on any
> element even if you are not changing its direction. And while it makes
> sense,
> it is overloading a bidi property for non-bidi reasons. I wouldn't object
> to
> it, given the correspondance of desired behavior is probably 1:1, but I see
> the point about joining behavior being "off-topic" for bidi.
>
> A reasonable switch might be whether there is positive
> padding/border/margin
> between inlines. It seems unlikely that joining behavior is desired across
> a non-zero margin, or that block elements would be inlined together without
> either whitespace or margin/border/padding as a separator.
>

This is an interesting approach. In fact padding/margin should probably act
as a virtual space character in the input to the UBA, not just in terms of
shaping. That it currently does not has bitten me more than once. I doubt
that there is much reason to worry about backward compatibility for the
shaping aspect because tags break the shaping in WebKit and Chrome anyway
(see above).


>
> I don't think change of font or color should cause a joining break,
> however.
>
> ~fantasai
>


Received on Monday, 10 February 2014 19:21:07 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 21 September 2016 22:37:36 UTC