Re: Splitting 'display'

--------------------------------------------------
From: "Tab Atkins Jr." <jackalmage@gmail.com>
Sent: Thursday, May 06, 2010 11:40 AM
To: "Andrew Fedoniouk" <news@terrainformatica.com>
Cc: "Peter Moulder" <Peter.Moulder@infotech.monash.edu.au>; "www-style list" 
<www-style@w3.org>
Subject: 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.)

You again use term "static layout" that sounds wrong to me for some
reasons. Usually "static" is opposing to "dynamic". So if you have
"static layout" than you should have something like "dynamic layout".
Are you considering table layout as dynamic one? If "yes" then why?

'position: static' means that you cannot change position of border box of 
the
element by means of CSS. And position: absolute & co.  allow to
change position dynamically and freely.  That is why
position: static and the rest.

flow: vertical | horizontal | table | "template" | etc.
and flexes are all about replacement of elements in position:static
mode. <table> based multi-column page designs are in
principle more stable than any attempts to emulate columns
using floats or position:absoulte|fixed. Reason is simple: <table>
is a static layout schema when size of actual content is driving
its dimensions and the whole layout.

If you have doubts about this then just take a look on front page of
http://www.w3.org/. Resize browser window and you will
see that at some width you will not be able to access information
on it. E.g. "standards | paricipate | ..." tabs/links will go to somewhere
near to Alpha Centaurus I believe. Text on sidebars is also not
readable in full. That is clearly a bug and it is there due to the
nature of current CSS.

This page : http://www.terrainformatica.com/ is knowingly
<table> based for precisely these reasons.

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

There are no "inline replaced elements" in HTML4 that
have visible sub elements inside. All existing inline
replaced elements (in HTML4) that behave as solid
boxes exactly as if they are glyphs - solid non breakable boxes.
You can declare <img> as display:inline and it will not
change anything. UA simply have no options rather than to replace
such elements as boxes in line.

display: inline and display: inline-block matters when
you apply it to elements like <span> with text or
sub-elements inside.  And as I said - there are no such elements
in HTML by default - this is what I meant.

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

This:

   <div #first>foo<i>bar</i>baz</div>

has flow:text layout manager as div contains purely inline-* elements
when this:

   <div #second>foo<p>bar</p>baz</div>

is quite different, it has flow:<default-block-flow> layout manager -
subjects of layout here are blocks but not glyphs inside line-boxes.
CSS box model mandates "foo" and "baz" to be wrapped in
anonymous boxes. So as soon as you have display:block
in sequence of inlines it triggers use of quite different LM.

And this is what I am talking about, if you declare:

div#second { flow: horizontal; }
div#second > p { margin: 0 1*; }

You will see this:

+---+---------------+---+
|foo|      bar      |baz|
+---+---------------+---+

rather than default and completely uncontrollable:
+---------------------+
|foo                  |
|bar                  |
|baz                  |
+---------------------+

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

What do you mean by "good slicing" here?

a) Existing 'display' and new 'flow' or rather
b) New 'display's properties and bunch of new flex-*,
template-*, grid-*, etc. ?

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

I am not missing them.  Take a look on 'flow: table'.

flow: table is a layout manager that replaces <tbody>, <tr>, etc.
by rules of HTML tables.

As of display:table-***....

Web now is at position when display:table-***
are not used as no one except of developers of browsers have
any idea of how they work.

In any case display:table-*** make no sense without flex units.

To make things even more ugly - proposed flex-** stuff is
not suitable or directly conflicting with display:table-***.
You cannot write display:table-cell and display:box at the same time.
In the same way you cannot use display:table-cell with the Template.

If someone would think that display:table-*** values are useful for
some reasons then we can left display:table-*** as they are.
The 'flow' is orthogonal to them. But flex units can give this
display:table-*** really good value making them as flexible as
<table>s now. But again, when you will have 'flow' people
will forget about display:tables pretty soon. If you
need table alike something then semantically is more correct
to use <table> rather than anything else.

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

I've got an impression that we are talking about different things.

Could you translate into display-outside and display-inside this:

ul { flow:horizontal;  }
ul > li { display: block; width:*; height:*; }

?

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

It should be 'inline-block' actually. And what about 'table-cell' then...?
Again: 'display' in any form cannot be used for definition of layout 
manager.

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

We don't need to change 'display'. Too many things rely on its current
values. And that is the point.

Problem with your display-outside/inside are the same as with original
display-model/role - values of display-outside and display-inside are not
orthogonal - they are related. You cannot say:

display-outside: inline;
display-inside: block-inside;

as it make no sense. You have to use this:
display-outside: inline-block;
display-inside: block-inside;

I assume you won't to go that far and change the
meaning of existing 'inline' value - that will not be
backward compatible.

-- 
Andrew Fedoniouk.

http://terrainformatica.com

Received on Friday, 7 May 2010 05:49:41 UTC