W3C home > Mailing lists > Public > www-style@w3.org > March 2011

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

From: Andrew Fedoniouk <andrew.fedoniouk@live.com>
Date: Fri, 11 Mar 2011 23:23:39 -0800
Message-ID: <BLU159-ds18E694F173C3560AFD7951F8CA0@phx.gbl>
To: "Alex Mogilevsky" <alexmog@microsoft.com>, "w3c-css-wg" <w3c-css-wg@w3.org>, <www-style@w3.org>
Alex, all these modules that you’ve mentioned below define the same entity - layout managers. 
Layout manager is a method of replacement elements or line boxes. 
It would be architecturally wise to provide common “umbrella”/foundation for all of them. 

It should be a property that defines layout method. I propose ‘flow’ or ‘layout’ 
Flex units are one of corner stones of the layout methods foundation too.

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. 

As of proposed “CSS Grid Positioning” and “CSS Grid Alignment”... They both suffer from the same
problem as original Flexbox did: they introduce parallel set of properties that define widths and 
heights of elements – now in form row/column width/heights. I really would like to know what 
exactly this:

grid-columns: auto 1fr;
grid-rows: auto 1fr;

#grid > :nth(1)
  width: 60%;
#grid > :nth(2)
  width: 40%;

means and how content inside such grid will be accessible/readable?

In general layout method shall not try to define any dimensions. Intrinsic and defined
dimensions of each element involved in layout shall define final replacement.
This appears as the only way of achieving non-controversial system of dimensional 

So the Template, I think, is the only really feasible way of defining grid layouts – simple
and sufficient to define any other grid layout you’ve mentioned. 

As of “CSS Regions” proposed by Adobe team.

In my understanding this document introduces two pretty much orthogonal entities:

1) Concept of “text-flow” – [method of] layout of line boxes. 

2) Non-rectangular shapes in CSS (actually that document misses border-radius
   with text-flow)

As of #1 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 );

  p.in-quote { 
      text-flow: selector( div.quotations );

And for that region-index feature this:
  p.in-content { 
      text-flow: selector( div.content:nth-child(1) )
                    selector( div.content:nth-child(3) )
                    selector( div.content:nth-child(2) ) ;
will work with the same result. 

As of #2 – non-rectangular shapes. 

I think we should have more generic mechanism of defining such things. 
E.g. I have multiple requests to provide mechanism in CSS that will allow to 
define shapes like tabs here:

Ideally it should be common mechanism that will allow to define border and
content outline shapes in the same CSS-ish way.

Andrew Fedoniouk


From: Alex Mogilevsky 
Sent: Thursday, March 10, 2011 9:36 PM
To: w3c-css-wg ; www-style@w3.org 
Subject: roadmap for new CSS specs: template, grid, regions and floats

At the F2F we have discussed new proposals for Grid Layout and for CSS Regions. They logically led to questions on how they relate to existing specs and how to proceed further. Follow-up discussions seemed to get to spec landscape that I will try to describe here.


I am making no assumptions here on who should edit what specs, just trying to figure out what is the right set of documents.



Specs discussed (in order of introduction)


* CSS Template Layout -- http://www.w3.org/TR/css3-layout/ 

Defines a  grid (specified with ASCII art) with named slots for flow content (possible irregular shaped and/or disjoint). Grid can auto-size to cell content.


* CSS Grid Positioning Level 3 -- http://www.w3.org/TR/css3-grid/ 

Defines how positioned elements (absolute or page floats) can address grid lines. Also introduces syntax for specifying a fixed grid.


* CSS Grid Alignment Level 3 -- http://dev.w3.org/csswg/css3-grid-align/ 

Defines a grid that positions its children in rows and columns which can be addressed by row/column number, named lines or named cells.

Grid can auto-size to cell content.


* CSS Regions -- http://lists.w3.org/Archives/Public/www-archive/2011Mar/att-0011/CSS_Regions.pdf 

Defines named threads that flow content through a set of containers.  Containers can have irregular shapes and exclusions.



Also relevant in this context


* CSS Generated Content for Paged Media -- http://www.w3.org/TR/css3-gcpm/ 

Includes definition of Page Floats  that can be positioned anywhere (including backwards in flow) and possibly use grid positioning.



Spec transitions


My understanding of what we want to happen is as follows:


1. (new) CSS Grid Layout Level 1 

-          publishing CSS Grid Alignment Level 3 as first working draft

-          include grid-related features from Template Layout


2. (new) CSS Regions Level 1

-          merge Adobe’s region proposal with template slots of Template Layout and with named flows of GCPM

-          “regions” name is tentative, it may change when we have a deeper discussion


3. (new) CSS Floats Level 3

-          Extract Page Floats from GCPM and extend with capability of tight wrap and control of exclusions

-          Include the use of grid positioning


4. Archive Template Layout -- http://www.w3.org/TR/css3-layout/ 

-          If there is content in current version that doesn’t naturally merge with either grid or regions, it may need a separate new spec, but I am not sure if there is any.

*OR*  keep the “Template Layout” name and combine with Regions. 

-          It depends on naming preference, otherwise the combined document should be same – defining how content can be flown into one or more containers.


5. (maybe) Archive Grid Positioning

-          Considering that its most prominent use is Page Floats, it may not have too much left when floats are fully defined.

-          It may still be preferable to keep as a separate spec (as it applies to absolute positioning too and doesn’t need to have a float dependency). 


Is this what we want to do? Thoughts?


Received on Saturday, 12 March 2011 07:24:13 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:13:57 UTC