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

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

From: Alex Mogilevsky <alexmog@microsoft.com>
Date: Mon, 14 Mar 2011 08:04:40 +0000
To: Andrew Fedoniouk <news@terrainformatica.com>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <D51C9E849DDD0D4EA38C2E539856928411ECBE3C@TK5EX14MBXC212.redmond.corp.microsoft.com>
> 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... 

> 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?

> 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 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.

> ... 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.

Received on Monday, 14 March 2011 08:05:15 UTC

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