Re: roadmap for new CSS specs: template, grid, regions and floats

-----Original Message----- 
From: Alex Mogilevsky
Sent: Monday, March 14, 2011 1:04 AM
To: Andrew Fedoniouk ; www-style@w3.org
Subject: RE: roadmap for new CSS specs: template, grid, regions and floats

>-----
>> From: Andrew Fedoniouk [mailto:andrew.fedoniouk@live.com]
>> Sent: Friday, March 11, 2011 11:24 PM
>
>> Consider this set: Flexbox, Template, that Grid are all about the same –
>> layout manager/method.
>> And all of them use flex units in one form or another.
>
>I am not sure what you are suggesting here. There can be different ways to
>group functionality in modules and share functionality (such as units)
>across modules. We are looking for a good balance...

Let's consider CSS Multi-column Layout Module:
http://www.w3.org/TR/css3-multicol/
and any other layout module, let's say Grid:
http://www.w3.org/TR/css3-grid/

First of all they are incompatible with each other in the sense that
either one of them can be used at the same time on the same container.
And both of them seems like in conflict with Flexbox. Or at least
I cannot predict effect of applying all these:

div {
  display: box;            // flexbox
  box-orient: horizontal;  // flexbox
  column-width: 50%;       // multi-col
  column-count:2;          // multi-col
  grid-columns: 50% * * 4em // the grid
  grid-rows: 50% 50%        // the grid
}

In general *layout* modules are mutually exclusive. So it should
be single property the defines which layout module to use.

It is also desirable that all layout characteristics be defined
in this property. Something like this:

div {
  flow: multi-columns
           columns(25%, 25%, 50%)
           gap(10px)
           ruler(red, dotted,1px);
}

div {
  flow: grid
          columns(25%, *, 25%)
          rows(10%,*,10%);
}

So all details will be applied on all-or-none basis.

>
>> I really would like to know what exactly this:
>> #grid > :nth(1)
>> {
>> width: 60%;
>> }
>>
>> means and how content inside such grid will be accessible/readable?
>
>It means the same as anywhere else ... these are selectors setting
>properties on child elements. It is of course possible to produce layout
>that is difficult to understand, but same is true for any other system that
>is complex enough, isn't it?

Say you have table cell with applied Grid Layout with rows/columns defined.
What would be value of min/max-intrinsic sizes of such cell?
Values defined in grid-rows/columns or dimensions of elements themselves?
Related question about computation of outline rectangle for
overflow/scrollbar purposes. So far CSS is pretty stable in respect
of these calculations. Adding parallel dimensional requisites will
break CSS layout principles as far as I can tell.

>
>> In general layout method shall not try to define any dimensions ...
>> So the Template, I think, is the only really feasible way of defining
>> grid layouts
>
>I don't think I agree with the first statement, and I don't see how it 
>leads
>to the conclusion.

I mean if to exclude from Template any dimensional definitions and
left only "topological" attributes:

flow: "1 2 3"
      "4 4 5";

In this case dimensions will be computed using [min-/max-]width and
[min-/max-]height properties of elements involved.

This simple flow declaration allows to reproduce all features of the Grid.
At least in the way as Grid defined at the moment.

>
>> I think it is enough to have just single property named  ‘text-flow’ so 
>> we
>> will be able to define these:
>> p.in-content {
>>     text-flow: selector( div.content );
>> }
>> will work with the same result.
>
>True, it can work like this -- content relocation happening without any
>consent of content, by just specifying a selector that points at it, or
>"pulls" content from it.
>
>It is a possibility. It is similar to earlier GCPM syntax of
>"content:from(flow-name)". It is pretty powerful though - it can pull
>content from multiple elements into multiple containers, and there is no
>way to restrict what can provide content. I'd like to be more conservative
>there.

But selector() approach will require one property rather than two.
And yet it will not require parallel naming mechanisms other
than existing class/attribute/tag-name selectors.

As far as I understand CSS Regions is a superset of multi-columns
or at least they overlap a lot. That is another reason to have
layout modules to be defined by single property. We can safely
obsolete/add particular flow value (layout module).
And it appears as we already running out of meaningful names so
there are those 'columns', 'grid-columns', etc.

>
>> ... non-rectangular shapes.
>> I think we should have more generic mechanism of defining such things...
>
>This is discussed in a separate thread, right? SVG is an obvious candidate.
>We'll have to see more use cases to understand what exactly we need there.

Yep, that is different topic indeed.

-- 
Andrew Fedoniouk

http://terrainformatica.com

Received on Tuesday, 15 March 2011 04:10:43 UTC