Re: Splitting 'display'

--------------------------------------------------
From: "Tab Atkins Jr." <jackalmage@gmail.com>
Sent: Monday, May 03, 2010 9:56 AM
To: "Peter Moulder" <Peter.Moulder@infotech.monash.edu.au>
Cc: "www-style list" <www-style@w3.org>
Subject: Re: Splitting 'display'

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

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

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.

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.

'block-inside' is always a box by itself and always contains boxes (explicit
and implicit a.k.a. anonymous boxes).
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.

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.

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.

Things I don't like in Flexbox proposal:

Flexbox is de facto definition of one of possible layout managers.
But it introduces bunch of specific properties that are really not needed
and even worse - conflicting or synonyms of existing properties (e.g. 
vertical-align).
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...
But the worst thing is that strange box-flex. box-flex is clearly mutually
exclusive with width/height property values. That "preferred width" concept 
is
too far from what we have now in CSS.

-- 
Andrew Fedoniouk

http://terrainformatica.com

Received on Tuesday, 4 May 2010 05:41:56 UTC