- From: Øyvind Stenhaug <oyvinds@opera.com>
- Date: Thu, 24 May 2012 11:31:45 +0200
- To: www-style@w3.org, "Roger Baker" <tstartme@hotmail.com>
On Wed, 23 May 2012 15:09:57 +0200, Roger Baker <tstartme@hotmail.com> wrote: > I'm trying to understand the inline formatting model's behavior in > regards to inline box splitting with padding. Specifically, why is it > that when an inline box has right padding that is distributed to the > following line, it takes preceding text (words) with it, even though > there's still room for those words on the initial line box. Furthermore, > the wider the padding, the more text is displaced to the following line > box. > > Here is an example where the right padding (46px wide) ends just at the > end of the line box: > > http://tinkerbin.com/ZmmhofCB These examples are dependent on the browser's text rendering and whatever font is used as the default on the browser/OS combination being tested. So on my system the line breaks are different from what you describe. (The Ahem font, <http://www.w3.org/Style/CSS/Test/Fonts/Ahem/>, would be a way to get around that.) > Here is the same example where the padding is one pixel wider, causing > the browser to displace the padding to the following line box. Why is > the word "top" also displaced? > > http://tinkerbin.com/QI1s35Lq I don't think this is covered in CSS 2.1, it just says that it "does not fully define where line breaking opportunities occur". The Text Level 3 draft adds that "[f]or break opportunities given by the first or last character of a box, the break occurs immediately before/after the box rather than breaking the box". > And the wider the padding is made, the more text is displaced to the > following line box... 100px displaces the words "at the top": > > http://tinkerbin.com/67xb2Ef4 > > 200px displaces the words "other, beginning at the top": > > http://tinkerbin.com/Gr0tVzNd > > And so on. > > Perhaps the browser is trying to "equalize the text wrapping margins" or > something like that, but that would just be guessing. And also, if that > were true, you'd think the browser would displace more text than it did > in the 100px right padding example. Anyway I've looked in section 9.4.2 > and elsewhere in the spec, but there doesn't seem to be an explanation. Did you test in Firefox or some other browser based on the Gecko rendering engine? It seems to be a Gecko bug, doesn't happen in Chromium or Opera. (It is not a CSS compliance bug since CSS doesn't define which line breaking opportunities to take; one could even break at every opportunity no matter what, even though most would agree that this would be pretty broken.) -- Øyvind Stenhaug Core Norway, Opera Software ASA
Received on Thursday, 24 May 2012 09:32:21 UTC