Re: [CSS21] Issues with inline formatting model (particularly 10.8)

On 02/09/2010 22:56, fantasai wrote:
> 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.

You're right of course, "inline-level" was a slip-up.  It should have been:

   | Line boxes which contain only empty inline boxes having zero-width
   | padding, borders and margins must be treated as zero-height line
   | boxes.

Anyhow, it's pretty clear from what I wrote that I'm not trying to 
introduce a technical change, but merely an editorial rewrite that 
removes the failings of the original sentence.  Obviously that rewrite 
needs to match what the current sentence tries to say (including any 
line break magic if necessary).  The question is whether you agree with 
the principle that line boxes do not contain text.  They certainly don't 
in any other sentence of Chapters 9 and 10; they contain boxes.


> 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.

Well I'm not sure CSS can have much say on the matter.  Aside from the 
implied requirement to define "forced line break" in a wider context 
than just HTML, I don't see that a line break could be translated as 
non-preserved by the UA but still be treated in this sentence as 
preserved (ie triggers a line box of non-zero height); presumably the UA 
translates it to non-preserved for good reason.  (Not that I know of 
such a UA.)

Note that Appendix D suggests the following as an appropriate default 
for the HTML br element:
br:before {content:"\A"; white-space:pre-line}


>> 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.

Fair enough.  I don't see much typographical advantage to allowing 
inline boxes that consist only of horizontal margin to trigger a line 
box of non-zero height, but I can't say it overly concerns me.  (I was 
merely interested in whether there /were/ any important such advantages.)

>> (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.

True.  Then this is a matter of taste, to be taken up with the IE and 
Opera teams. ;-)  The Gecko behaviour is definitely incorrect though.


>> 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

Great, thanks.


Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Friday, 3 September 2010 06:50:36 UTC