W3C home > Mailing lists > Public > www-style@w3.org > October 2012

Re: [css-display] Unofficial draft of a Display spec ready for consumption

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Tue, 23 Oct 2012 11:46:01 -0700
Message-ID: <CALRQH79NiN49CNK=_4EMkfKQ6NwODuMmPK3rh16vEZcqnDyLJw@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: www-style list <www-style@w3.org>
On Tue, Oct 23, 2012 at 9:12 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

>> So the only way to remove multi-column layout is:
>> columns: auto auto;
>
> No.  "columns: auto" is fully sufficient. It sets one of the
> properties to "auto" explicitly (doesn't matter which), then sets the
> other to its initial value, which is "auto".

Still "columns: auto" for disabling columns layout looks controversial.
"columns:none" is more clear. But, sigh, seems like we should live with
that for now and beyond.

>
>> But see how fragile is the whole system is:
>> 1.  Each LM has different rules to apply/remove
>>      given layout.
>> 2. List of LMs is an open set - we will add more
>>    layout methods/managers. And with each LM
>>    you don't know upfront their precedence.
>
> No.  All layout modes are controlled by display-inside.  There's no
> "precedence", because an element can only be in one at once.

Ok, seems like we both pretty close on that. The only things left:

'display-inside' as name of the entity may work for the list of
layout modes we know of for now.

Implied modes (cannot be set by explicitly), calculated when
display-inside:auto (do we have 'auto' there BTW?):
1. {text}, {text-rtl}, {text-ttb}
2. {blocks}, {blocks-rtl}
3. {table},{table-rtl} ,{table-rtl}
Explicit layout modes:
4. flex, flex-vertical, flex-vertical[-wrap], flex-horizontal[-wrap]
5. grid
6. regions

All these fall in category display-inside but I can imagine
that in future someone will want for example flow:toolwindows
when elements like <footer>,<header>,<nav>,etc. to be placed
in sort of dockable windows, so out of the box. So that '-inside'
in the name of property would be quite restrictive.

As I said already: technically we can live with existing display property
as it is declared now. The only thing we need is something like
   layout: auto | flex | grid | regions | etc.

Ideally these values shall accept extended function notation like

layout: flex( direction:row, wrap: nowrap );
layout: grid( columns: 50% * * 4em, rows: 4em (0.25em 1em) );
layout: multi-column( columns: 450px );

In this case we don't need to pollute common property namespace
by things like grid-columns, grid-rows, etc.

And the last, about that 'display-box' thing again.
We already have two properties that describe visibility somehow:
'display' and 'visibility'. Do we need one more here?

It is clear that we need some property that will allow
to exclude the element from rendering tree and that property
should be orthogonal to the 'display'.

visibility:visible | hidden | collapsed | none | contents;

will just work perfectly for that. All values there are mutually
exclusive by their nature. So this will look quite natural:

function show(el, onOff) {
   if(onOff)
     el.style.visibility = "visible";
   else
     el.style.visibility = "none";
}


-- 
Andrew Fedoniouk.

http://terrainformatica.com
Received on Tuesday, 23 October 2012 18:46:29 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:01 GMT