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


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

You used the term "block-inside".  I assumed that meant you were
talking about retaining all of display-outside, display-inside, and
flow.  If that's not what you meant, then never mind.


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


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


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

etc.

~TJ

Received on Friday, 7 May 2010 18:06:01 UTC