- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 02 Sep 2010 13:56:56 -0700
- To: Anton Prowse <prowse@moonhenge.net>
- CC: "www-style@w3.org" <www-style@w3.org>
On 09/01/2010 02:11 PM, Anton Prowse wrote: > > 9.4.2 Inline formatting context > (http://www.w3.org/TR/CSS2/visuren.html#inline-formatting) : > > # Line boxes that contain no text, no preserved white space, no > # inline elements with non-zero margins, padding, or borders, and no > # other in-flow content (such as images, inline blocks or inline > # tables), and do not end with a line feed must be treated as > # zero-height line boxes. For the purposes of margin collapsing, this > # line box must be ignored. > > > Issue 20a: If a line box contains no preserved white space then it > can't end with a line feed. So that clause in the first sentence is > superfluous. > > Issue 20b: Line boxes never contain text; they contain inline-level > boxes (which may contain text). The first sentence needs reformulating, > along the lines of the following: > > | Line boxes which contain only empty inline-level boxes having > | zero-width padding, borders and margins must be treated as > | zero-height line boxes. This is not an editorial change, Anton. The spec text also collapses things like <p><span><span/></span> and does not collapse things like <p><span style="display: inline-block"/> So I don't think we can simplify the clause this way. However, the use of "line feed" here is indeed inappropriate. It should be "forced line break", because <br/> is intended as a trigger, whether or not it's translated to a preserved line feed by the implementation. > Issue 20c: Assuming that we *want* zero-height line boxes in some of > the cases listed (Issue 199; [1]) then, if a line box contains only an > (empty) inline box with zero padding and border area but some non-zero > margin, is it reasonable to want the line box to have non-zero height, > and if so, why? And what about negative margin? The purpose of this clause in the spec is backwards-compatibility with regards to the handling of unstyled empty inline elements. It's not going to make a whole lot of sense in any case. The goal here is to define clearly exactly which cases are covered, and have UAs align on a single set of exceptional cases -- as you note, there isn't a whole lot of interop on this case. > (There's currently no interop here – although that seems to be due to > bad handling of margin on empty inline boxes in general in all browsers > other than Safari: > <!DOCTYPE html> > <body><div> > <span style="margin-right: 500px;"></span> > <span style="margin-right: 500px;"></span> > <span style="margin-right: 500px;"></span> > text > </div> > </body> > Sf5 follows the current spec; Op10.6 and IE8 don't find any line > breaking opportunities; and Fx3.6 treats the margins as having no > influence on the inline boxes which follow.) The case of line-breaking opportunities between empty inlines seems to be a broad class of non-interop. Line breaking isn't defined in the spec, so you can't really say any implementations are non-conformant for not breaking there. > Issue 20d: The second sentence is currently needed because 8.3.1 does > not regard margins separated by line boxes to be adjacent. I'm not sure > I like this editorial approach though. (IMO secret overrides are > undesirable in the core text.) Can we link 8.3.1 back to this sentence > where appropriate? Not a bad idea. Filing as CSS2.1 LC Issue 204: http://wiki.csswg.org/spec/css2.1/last-call-2010#issue-204 ~fantasai
Received on Thursday, 2 September 2010 20:57:32 UTC