Re: Splitting 'display'

On Wed, Apr 21, 2010 at 10:12:34AM +0300, Mikko Rantalainen wrote:

> In addition, I agree with Andrew Fedoniouk that splitting the 'display'
> property does not change anything in itself. However, I still believe
> that this change would be beneficial in the long run, because it would
> simplify defining new features as Tab Atkins Jr. reasoned. In addition,
> it would make explicit to UA vendors that the engine must be able to use
> separate algorithms for the the inside and outside of any element.

A possible resolution of these points would be to change the spec's description
of the 'display' property and change terminology ("inline elements",
"block-level" etc.) to be terms of these orthogonal inside/outside concepts,
even if we don't make any UA-visible changes (such as introducing new
properties or values to be parsed & accepted) until there's more pressing gain.

If flexbox or template get added to CSS, then part of the change might be to
make the property split for real, but the conceptual groundwork will already
have been added to the spec as a separate change, making it easier to evaluate
the two independently.

I think there's enough value in changing the textual explanation to
make this change now even before adding flexbox/template/multicol.

Avoiding (or delaying) making a true property split also means being able to
get the conceptual changes in without (or before) much of the trouble with
list-item: making purely textual changes doesn't require the degree of
consideration necessary for UA-visible behaviour that needs to be supported
into the future; and text regarding list-item can largely stay unchanged.

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


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

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.

pjrm.

Received on Saturday, 1 May 2010 08:15:57 UTC