W3C home > Mailing lists > Public > www-style@w3.org > April 2010

Re: Splitting 'display'

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Fri, 16 Apr 2010 23:04:49 -0700
Message-ID: <1E4B29D4082D42BABFE02ED76DA9BD12@terra3>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: "www-style list" <www-style@w3.org>

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

'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

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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:45 UTC