Re: Splitting 'display'

--------------------------------------------------
From: "Tab Atkins Jr." <jackalmage@gmail.com>
Sent: Friday, April 16, 2010 9:06 PM
To: "Andrew Fedoniouk" <news@terrainformatica.com>
Cc: "www-style list" <www-style@w3.org>
Subject: Re: Splitting 'display'

> On Fri, Apr 16, 2010 at 8:46 PM, Andrew Fedoniouk
> <news@terrainformatica.com> wrote:
>> If so then I don't think any change in 'display' will have any chance.
>> Legacy reasons and so on.
>
> I'm confused.  A change in display would indeed be impossible.

You can provide some feature that will make some values of
the display obsolete - they will die by themselves.
But that should be killer feature literally.

>
> Turning display into a shorthand property that still accepts all the
> single-token values is completely backwards-compatible.
>

But what is the point to introduce such new 'display'?

So far changes that you propose are not adding
any new value. Yes, conceptually display-model should be
there from the very beginning but now it will give us almost
nothing.

'flow'/flexes are really that feature that brings
new quality to CSS.

For example screen window layout of Outlook
can be reproduced with flow:horizontal + flexes as
it is. Applications like GMail are simply not comparable in this
respect - there is simply no way in CSS to reproduce this reliably.

>
>> In my opinion the 'flow' as a definition of layout manager of some
>> [block] container - definition of the way how it layouts its children
>> has significantly more chances.
>>
>> 'flow' is orthogonal to 'display' in the sense that only
>> 'block', 'inline-block', 'table-cell' and that strange 'list-item' may 
>> have
>> 'flow'
>> defined and meaningfully interpreted. For all other values of the display
>> property computed value of the 'flow' is 'auto' (default).
>>
>> In general 'flow' makes sense only for block elements - those that
>> establish box context and so have width and height.
>
> Take a look at what I've actually done, and how I've split things up.
> I think it's much closer to what you are thinking than you realize.
>

I did, that is why my question. If it is a first step on the way to 
something else
then your intention is not clear, sorry. At least to myself.

>
>> In my opinion addition of table-*** values to the display was strategic
>> mistake. They do not create any reasonable solutions - just problems.
>> I believe that the flow with its values: vertical , horizontal ,
>> vertical-wrap ,
>> horizontal-wrap and "template" will make table-*** stuff obsolete.
>> If CSS is ought to define <table> as it is now then it will be enough
>> to add flow: table value with wording: "HTML table layout manager -
>> replaces TR,TD,TH elements using HTML table rules".
>
> That's very nearly what I've specced.  There is a single 'table' value
> for display-inside (the "flow" property).  All the other table values
> are display-outside values, which just describe how they interact
> inside of a table flow.
>
> (There is also a 'table-inside' value for display-inside, but it's
> just to make everything work a little more smoothly.  It doesn't
> actually *do* anything.)
>

For some reason
display-model: block-inside | inline-inside
sounds more understandable than 'display-inside'.

In any case it is not enough to say display-model: block-inside.
You should have to define how exactly you will replace those blocks.
The 'flow' does just that - it specifies that a) content has
to be treated as a sequence of boxes - e.g. inlines (if any) should
be wrapped in anonymous boxes and b) how child blocks
should be replaced.
Therefore 'flow' de facto is display-model: block-inside plus
definition of layout manager.

-- 
Andrew Fedoniouk

http://terrainformatica.com

Received on Saturday, 17 April 2010 06:05:20 UTC