- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 08 May 2014 15:54:24 -0700
- To: "Kang-Hao (Kenny) Lu" <kanghaol@opera.com>, Koji Ishii <kojiishi@gluesoft.co.jp>, WWW Style <www-style@w3.org>
On 11/11/2013 10:37 PM, Kang-Hao (Kenny) Lu wrote:
> (2013/11/12 14:15), Koji Ishii wrote:
>> On 11/10/13 10:21 PM, "Kang-Hao (Kenny) Lu" <kanghaol@oupeng.com> wrote:
>>
>>> Our internal channel reveals that for this case
>>>
>>> data:text/html,<style>body { width: 0; }</style><input> <input>
>>>
>>> , there should be a soft soft wrap opportunity after the NO-BREAK SPACE,
>>> while this contradicts css-text + UAX#14 at this moment:
>>
>> Maybe I missed something here, but why do you think there should be?
>
> Because our client reports the "not breaking behavior" as Presto's bug
> and all other browsers break this? As an amatuer, I personlly don't
> think there should be a soft wrap opportunity in this line.
>
>> It's GL+CB, and LB12 prohibits break before/after GL.
>
> Right.
>
>>> Only Presto is following the spec here, every IE mode I tested, WebKit,
>>> Firefox all behave otherwise, and I doubt other browsers will want to
>>> follow the spec because our client reports this as Presto's bug.
Okay, Koji and I updated the spec as follows:
# The line breaking behavior of a replaced element or other atomic inline
# is equivalent to that of the Object Replacement Character (U+FFFC)
appending...
# and introduces a soft wrap opportunity both before and after itself.
# For Web-compatibility, this rule take precedence over WJ and GL handling;
# in terms of [UAX14], this shifts the CB rule (LB20) immediately above
# the WJ and GL rules (LB11/LB12).
The implication here is that UAs will have to update their U+FFFC
line breaking to match that of atomic inlines. I doubt this is
a significant problem, however...
Let me know if that seems to make sense.
>> I might want to ask other experts opinion here, but as far as I
>> understand, CSS does not require UA to follow CB line breaking class, so I
>> suppose the case for GL+CB is undefined. CSS does require GL, so I might
>> be mistaken here. Is this what you're talking about?
>
> Right. If
>
> # * Regardless of the ‘white-space’ value, lines always break at
> # each preserved forced break character: for all values,
> # line-breaking behavior defined for the BK, CR, LF, CM, NL, and SG
> # line breaking classes in [UAX14] must be honored.
> #
> # * When ‘white-space’ allows wrapping, line breaking behavior
> # defined for the WJ, ZW, and GL line-breaking classes in [UAX14]
> # must be honored.
>
> only target pairs in which *both* characters are in any of BK, CR, LF,
> CM, NL, SG, WJ, ZW, GL, then that should be clarified. I interprete
> these as targeting pairs in which *at least* one character is in.
Yes, your interpretation is correct.
~fantasai
Received on Thursday, 8 May 2014 22:54:53 UTC