- 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