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

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