Re: Splitting 'display'

On Sat, May 1, 2010 at 1:15 AM, Peter Moulder
<Peter.Moulder@infotech.monash.edu.au> wrote:
> I've some reservations about the display-inside property/concept:
> 'table' seems more like it belongs alongside block vs. inline formatting
> contexts than being analagous to the distinction between display:inline and
> display:inline-block: it describes how its children are placed wrt each other,
> whereas the display:inline vs. inline-block describes placement wrt inline
> siblings of the box.  This objection to the separation disappears if the change
> to the spec is just a textual one, because there's no problem with having three
> concepts of display-outside, content-parent interaction (i.e. inline vs
> inline-block), and arrangement-among-children (which isn't determined entirely
> by the box's 'display' value), whereas it would be objectionable to try to
> split 'display' into three or more actual properties that aren't orthogonal to
> each other.

I'm not sure I understand what you're saying.

You say that 'table' "describes how its children are placed wrt each
other", which is precisely what display-inside is supposed to capture.
 It is indeed analogous to the block/inline context, in terms of how
blocks and inlines handle their children.

Your statement that the display:inline vs. inline-block describes
placement wrt inline siblings of the box" seems incorrect.  Inlines
and inline-blocks act the same wrt their siblings (that is, they have
the same display-outside value, 'inline').  The difference is that an
inline has display-inside:inline, which means that any initial or
final linebox children get merged into the lineboxes of its parent,
while an inline-block has display-inside:block, which doesn't do that.


> (I didn't understand Andrew Fedoniouk's paragraph "In any case it is not enough
> to say display-model: block-inside" paragraph in message-id
> 1E4B29D4082D42BABFE02ED76DA9BD12@terra3, but possibly that too involved an
> objection to the proposed separation that would be easier to accommodate if we
> were just to make an explanatory change to the spec rather than introduce new
> properties and values.)

I don't truly understand that point either, but I think it's a bit of
confusion resulting from model mismatches - the model he's holding in
his head is different from the one I am, or in other words, we're
talking past each other.  ^_^


> In addition to the benefits that have already been mentioned, the CSS21 spec
> seems full of undefined phrases involving the words `inline' or `block' that
> seem particularly unclear as to how they pertain to the box generated by
> inline-block elements; e.g. even in the very definition of the `inline-block'
> value and the term `inline-level' (§9.2.2: "Inline-level elements generate
> inline boxes" versus "[The `inline-block'] value [of 'display'] causes an
> element to generate a block box"), I'm not sure whether an inline-block element
> generates a single box that's both a block box and an inline box, or one block
> box and one inline box, or whether there's simply a mistake in the spec left
> over from when inline-block elements were changed from being block-level to
> inline-level.  Possibly splitting display into more than one concept will
> correspondingly allow clearer phrases than the existing ones involving `block'
> and `inline'.

The full text of the 'inline-block' value makes it clearer: "This
value causes an element to generate a block box, which itself is
flowed as a single inline box, similar to a replaced element. The
inside of an inline-block is formatted as a block box, and the element
itself is formatted as an inline replaced element. "

It's attempting to describe that the element acts like an inline
outside, but a block inside.  By saying that it "generates a block
box", the text makes it clear that inline children of the inline-block
stay within it rather than flowing with similar inline boxes outside
of it.  I agree that it's not the best wording, but given the concepts
being used at the time, I think it works sufficiently.  It's much
easier now to just say that display:inline-block is shorthand for
display-outside:inline and display-inside:block.


> Somewhat related is that rule 2 of §10.1 seems to be missing `inline-table'
> from its list: in limited testing (gecko & webkit), percentage padding values
> on a table-cell seem to be relative to the content-width of the inline-table
> (and not either the table-cell itself or the anonymous inline-block box that is
> said to contain any table), suggesting that the cell's containing block is the
> cell's nearest inline-table ancestor box, which is (presumably) neither
> block-level nor inline-block.  Of course we can add `inline-block' to the list
> whether or not we adopt the proposal, but the list might become shorter if we
> do introduce such concepts, and maybe such an omission would never have occurred
> if we'd previously had it in the spec.

Correct, that is an oversight.  The desired phrasing, using
display-outside/inside, is that the containing block is the nearest
block with a display-inside value of 'block' or 'table'.  This will
need to be expanded when flexbox and template come into play, as they
should establish containing blocks as well.  (Phrasing it the opposite
way, in terms of what display values *don't* create containing blocks,
is similarly vulnerable to needing expansion, as we already need to
deal with inline, table-inside, ruby, and ruby-inside.)

~TJ

Received on Monday, 3 May 2010 16:56:55 UTC