Re: Splitting 'display'

--------------------------------------------------
From: "Tab Atkins Jr." <jackalmage@gmail.com>
Sent: Friday, May 07, 2010 11:05 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 Thu, May 6, 2010 at 10:49 PM, Andrew Fedoniouk
> <news@terrainformatica.com> wrote:
>> 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?
>
> Sorry, I'll try to use "normal flow" in the future.  Defined here:
> http://www.w3.org/TR/CSS2/visuren.html#positioning-scheme
>

You can just use flow:normal ;) then.

>
>>>> 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.
>
> Incorrect.  display:table is actually relatively common.  It's been
> evangelized since before IE8 came out, both as a proper layout
> technique and as a hack to approximate "width:intrinsic".  It's
> definitely far past the point where we could drop it.
>

Don't need to worry about display: table then.

I suspect though that its primary use case for the moment is
that width:max-intrinsic case .  It just deserves to be introduced
by its own. width:min/max-intrinsic is especially useful with flexes.

>
>> 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.
>
> Yes, I know.  That's the whole point of this email thread.  Now, are
> you objecting to anything?
>

I am against any changes of 'display' and especially against
any attempts to add definition of layout managers to the display.

At the moment 'display' defines requirements of the element
to its container. And let's try to leave it in its current state.

BTW: I have no idea why David decided to introduce display:box in
his FlexBox. What is the problem with just this:

  display:block;
  box-orient: horizontal;

?

That is precisely what I did. It is just 'flow' instead of 'box-orient'.

The same apply to Templates. Why do we need to change 'display'
for it again?

>
>> 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:*; }
>
> ul {
>  display-outside: block; /* or whatever */
>  display-inside: flexbox;
> }
>
> And then some flexbox stuff to control the width/height of the boxes.
>

The same question then. Why it cannot be just this:

ul {
   display: block; /* or whatever */
   [display-]flow: horizontal; /* or whatever */
}

Why do you need to change the 'display'? That is the question I've asked few
times but seems like there is no answer on it so far. I really don't
understand your motivation.

>
>>> 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.
>
> I think I agree with you here, actually.  I don't think that the
> layout behavior of display:inline elements (merging their lineboxes
> with those of their parent) is actually useful for anything but them.
> So that means it should probably just be a special value that only
> they can use, similar to how table-inside is a special value that only
> table-* elements can use.
>
> So, the mapping would be something like:
>
> block
> : block normal
>
> inline-block
> : inline-block normal
>
> inline
> : inline inline
>

Yeah. And that drift us to the point where we can
agree that 'display' is perfect in its current ugliness -
don't need to be changed at all.

If we want to add property that will define layout
method to be used inside block elements then let
it be just new property. I've proposed 'flow' but
it can be 'layout' or something else.

The only thing left is to add flex units instead that
strange 'box-flex' that changes existing box model and we
will get exactly what I've already proposed :)

-- 
Andrew Fedoniouk

http://terrainformatica.com

Received on Saturday, 8 May 2010 02:57:18 UTC