Re: Splitting 'display'

On Mon, May 3, 2010 at 10:41 PM, Andrew Fedoniouk
<news@terrainformatica.com> wrote:
> If to forget for the moment about table specifics then all elements in
> CSS in principle can be described by these two properties:
>
> display-model: inline-inside | block-inside
> display-role: inline | block

Correct, if you ignore table layout, flexbox layout, template layout,
or any other new layout modes (in other words, if you only look at
static layout), then those are all you need.  (You still have the
special types, like list-item and run-in, but those generally act like
some combination of the above, plus some additional magic.)


> Using these two properties, elements in HTML can
> be classified as:
>
> By default elements like <div>,<ul>,<dl>, <table>, etc. are
>    display: block-inside block;
> - they are boxes by themselves and contain boxes (blocks).
>
> Elements like <span>, <strong>, <em>, etc. are
>   display: inline-inside inline;
> - they are not boxes and contain only text and/or inline/inline-block
> elements.
>
> Elements like <p> (text blocks) are
>  display: inline-inside block;
> - they are boxes and contain text and inline/inline-block elements.
>
> There are no elements in HTML4 that have
>  display: block-inside inline; combination.
> This "artificial" configuration is known as display: inline-block in
> modern CSS.
> Note:
>   It appears as HTML5 introduces inline-block elements.
>   At least <figure>is very close to display: inline-block as
>   far as I understand it. Not sure though.

Replaced elements act like they're inline-block.  The rules for
"inline replaced elements" are basically identical to that of
inline-block elements.


> All combinations except of  display: inline-inside inline;
> mandate creation of a box (for layout purposes) associated with the
> element. That is why only such elements may have width/height
> defined for them.
>
> 'inline-inside' blocks have layout manager (LM) that is known as text layout
> - it replaces character glyphs and boxed elements in line boxes.

Yes.


> 'block-inside' is always a box by itself and always contains boxes (explicit
> and implicit a.k.a. anonymous boxes).

This isn't right, or at least not right wrt the element list you had
before.  For example, <div>foo <i>bar</i> baz</div> is perfectly okay,
and both the anonymous text and the <i> are combined into a single set
of lineboxes.  <p> and <div> handle these children identically.
Basically, if you have display-outside:block, there's no difference
between display-inside:inline and display-inside:block.


> To replace boxes inside it may have different LMs.
> By default in CSS2.1 it uses something close to flow:vertical - boxes are
> replaced one by one vertically. Tables can be thought as also 'block-inside'
> containers with flow:table layout manager.

Sure, that's valid if you want to separate out display-inside from
flow.  I don't think that's a good slicing of the abstraction, though.


> If to speak about ideal system of orthogonal properties...
> These two appears to be 100% compatible with existing content:
>
> display: inline | inline-block | block | list-item | run-in;
> flow: default  | vertical | horizontal | vertical-wrap | horizontal-wrap |
>        table | "template" | stack ;  and so on.

You're missing all the table display types in the display property.


> If some element directly contains text and/or inline/inline-block elements
> then this triggers text layout (manager) to be used on such element.
> That is what all UAs are doing at the moment.
> If it is a box (inline-block | block | list-item) and contains only blocks
> then the
> 'flow' specifies how to replace boxes inside.
> flow:default is a LM that is defined by current CSS box model with
> float treatments, etc.
>
> flow:default is mutually exclusive with, say, flow: horizontal or
> "template".  And the flow is pretty much orthogonal to the display
> property.

This is where we keep talking past each other.  The division I make
between display-outside and display-inside is *precisely* the division
you make between display and flow.  I suspect that if I did a
search-and-replace in my email you'd agree with nearly everything I've
said.


> Things I don't like in Flexbox proposal:

Could you bring these up in the threads about Flexbox?

I will, however, address one point, which is relevant to display:

> And yet if it declares display:box then we will need display:inline-box.
> And so on for each LM in future. E.g. I don't know how we are going to deal
> with templates that are inline blocks...

Well, templates accept an 'inline' token before the actual template starts...

But I agree with you.  Completely.  This should be crystal clear from
my very first post in this thread, and everything I've said since
then.  The entire *point* of this thread is to split "display" so we
can separate out the layout manager (display-inside) from the role in
a layout (display-outside), and we don't have silliness like every new
display value coming in an inline version, and there being a lot of
combinations that are simply impossible (like a template cell being a
flexbox, frex).

~TJ

Received on Thursday, 6 May 2010 18:40:53 UTC