Aharon (Vladimir) Lanin | 1 Nov 01:37 2010
Picon

directional images

The following is a proposal for a small addition to CSS3 Images in order to make it easier to build web apps that support both LTR and RTL interfaces. For use cases and discussion, see http://www.w3.org/International/docs/html-bidi-requirements/#image-flip.

Expand the syntax of each of the possible ways that an <image> can be specified in CSS3 Images, e.g. <url>, <image-list>, and <gradient>, by allowing a new keyword: rtlflip. Examples would be:

  • background-image: linear-gradient(45deg, white, black) rtlflip
  • list-style-image: url('sprite.png#xywh=10,30,60,20') rtlflip

The presence of the rtlflip keyword means that the image must be horizontally flipped when the element's CSS direction (or, in the case of list-style-image, the list item marker's direction, as defined by the list-style-direction CSS property) is rtl.

Alternatively, instead of rtlflip, the syntax could be to allow one of two new keywords: ltr or rtl. The presence of one of these would declare the image's direction and specify that the image should be horizontally flipped when this direction does not match the element's CSS direction (or, in the case of list-style-image, the list item marker's direction). Being declarative as opposed to instructive, this alternative is more elegant than rtlflip, but requires two new keywords instead of one. It is up to the CSS WG to choose the better syntax.

Aharon Lanin
Andrew Fedoniouk | 1 Nov 01:40 2010

Re: [css3-grid-align] -- proposed new grid layout module

--------------------------------------------------
From: "François REMY" <fremycompany_pub <at> yahoo.fr>
Sent: Sunday, October 31, 2010 2:38 PM
To: "Andrew Fedoniouk" <news <at> terrainformatica.com>; "Alex Mogilevsky" 
<alexmog <at> microsoft.com>; <www-style <at> w3.org>
Subject: Re: [css3-grid-align] -- proposed new grid layout module

> ?If I can add my 5 cents, too, I would like to say I don't like the 
> Template proposal anymore. While it seemed better at first glance, it adds 
> a lot of complexity and make it difficult to modify the style dynamicly 
> using a script.

That is pretty easy to solve. For example in my implementation this

flow : "1 1"
        "2 3";

is an equivalent of

flow : "1 1|2 3";

so to set it from script you can use:

element.style.flow = "1 1|2 3";

>
> In fact, I don't think Template is easy at all. You say it's easier when 
> you move your objects in the DOM. I think it's not. What if you want to 
> put on a layout manager an element that previously had 'display: a' ? It 
> becomes a nightmare. You should check if the template defines an 'a' slot. 
> Then, you need to check if it's alreay used by another element. In such 
> case, you need to modify the CSS display property of your new element to 
> use another letter, which is not used in the defined template. At last, 
> you should parse the content of the 'display: "aaabbb/ccddee"' property 
> and add new line of a new column where you want to put your element. The 
> ECMAScript code needed to do something like that is incredibly big. And 
> you just wanted to add one column or one row to your display.
>
> Template display is also non-extensible. It does not work if you don't 
> know how many element you want to put on your grid. Then, you are also 
> limited to the 'usable' ASCII range. What if you end up with a grid layout 
> needing more than the available char range ?

As I said I've ended up with use element indexes rather than named
cells.

So if you have defined:
flow : "1 1"
        "2 3";
you can add in that container as many elements as you want.
They will be added as if you have defined this:
flow : "1 1"
        "2 3"
        "4 4"
        "5 5"
        ...
        "N N";

And so you can insert elements in the middle, etc.
Numbers are also not limited by char ranges.

But as I said flow:"template" is an exception - if you have
list of items then it is better to use flow:horizontal[-flow] or
flow:vertical[-flow].

Yet I've seen couple of cases where list items (<li>) by
themselves use template layout inside.

>
> On the other side, the grid proposal is already implemented in some known 
> and widely used products and it's really easy to use. If you want to add a 
> row, you just need to add an element specifying that row index as 
> grid-row. If you want to delete the row, just drop the element. You don't 
> need to care about the template. It just works.

I am not aware about any existing implementation of grid layouts in CSS
except of mine. Will be interesting to take a look. Could you provide
a link?

>
> And if you really want something fully written in CSS for your dynamic 
> grid layout, you can extend the use of 'counter' and allow something like 
> that :
>
> #myGrid div.labelColumn {
>    counter-increment: myGridRow 1;
>    counter-reset: myGridColumn 1;
>    grid-row: counter(myGridRow); grid-column: 1;
> }
>
> #myGrid div.dataColumn {
>    counter-increment: myGridColumn 1;
>    grid-row: counter(myGridRow);
>    grid-column: counter(myGridColumn);
> }

But why not to use <table #myGrid> in this case?
I believe that for tabular data as in your case it is
exactly what doctor have prescribed, no?

>
> I don't think it's possible to do something like that with the Template 
> proposal.

As I said it should be a system of various layout managers that
better suit different cases. There is no silver bullet. And that is the
point.

E.g. in Java there are 8 layout managers available out of the box:
http://download.oracle.com/javase/tutorial/uiswing/layout/visual.html

I have 7 implemented so far

flow: vertical | vertical-flow |
        horizontal | horizontal-flow |
        grid | /*obsolete*/
        stack |
        "template"

all of them use flex units. This is a superset of layout
managers found in Java.

-- 
Andrew Fedoniouk

http://terrainformatica.com

>
> Regards,
> François
>
> -----Message d'origine----- 
> From: Andrew Fedoniouk
> Sent: Sunday, October 31, 2010 9:58 PM
> To: Alex Mogilevsky ; www-style <at> w3.org
> Subject: Re: [css3-grid-align] -- proposed new grid layout module
>
> Well put, Alex!
>
> But here are my 5 cents as this appears close enough to my initial
> flow:grid approach[2] to implement such a layout manager.
>
> The only difference in my case is that I am [re]using
> left/top/right/bottom properties (they are not used in position:static)
> for defining cell element binding to rows/columns.
>
> So this of yours:
>  #board    { grid-column: 2; grid-row: 1; grid-row-span: 2 }
> in my case is this:
>  #board    { left: 2#; top:1#; bottom:2# }
> where '#' is a special "grid location unit".
>
> My variant of defining bindings to rows/columns is very far from being
> perfect. Yours appears as to be better but they share the same set
> of problems.
>
> So all below is based on real experience using them and why
> I've decided to drop this layout manager in favor of something close
> to the Template[1].
>
> At some point I've decided to add Drag-n-Drop support to
> CSS. DnD in CSS is actually another and interesting story per se,
> but for now is this: it raised some set of requirements that forced
> me to revisit problem of grid alike layout[manager]s in CSS.
>
> 1) definition of a child of the Grid should not contain
> grid positions like grid-column and grid-row in your case.
> It is highly desirable to define layout in one place that you can
> [re]define children flow on all-or-none basis.
> Think about of moving #board element in runtime to different container
> that uses its own grid layout.
>
> 2) Way of binding of elements to cells has to be as less error prone
> as possible. E.g. it is too easy to get element overlapping with either
> my flow:grid or display:grid of yours.
> It is also very easy to get grids that will have e.g. only [1,1] and
> [10,10] cells filled by some elements with the rest of the grid filled by
> holes that still occupy space (due to the grid-columns). Grid 
> inconsistency
> errors (overlapping and holes) are very easy to get and very hard to find
> and maintain.
>
> 3) Dimensions of cells must be dependent only on
> dimensions of elements in rows/columns.
> If you have some element with min-width:150px placed
> into column with grid-columns: 100px then it is not
> clear who will win. Dimensions defined in two
> different places, as an option, is bad as it is.
>
> 4) Ideally any layout manager shall keep congruency
> of element position on screen and its position in the DOM.
> E.g. if you have consequent elements A, B and C in the DOM then
> B should be in between A and C visually. Vertically, horizontally or in
> flow.
>
> For example DnD in flow:horizontal (e.g. tabs) containers.
> In such layouts, for any given mouse location, task of finding
> insertion DOM position of the element is trivial and
> very predictable (for the user).
>
> In fact #4 is not only about DnD but also about text selection on the
> page, tab[index] navigations, screen readers (accessibility) and so on.
> I mean that the Grid layout must be used as an exception - as a last
> resort when no other natural layouts are working.
>
> That means we ought to have *system* of layouts where the
> Grid (in one form or another) is just one of them.
> If we have a system of layout[manager]s then we shall try to unify
> them. If all of them use flexes then we shall have flex units defined.
> E.g. your proposal uses 'fr' units, David use "box-flex:" property and 
> Bert
> use '*' for flexes in his proposal.
>
> And again about use of 'display' for defining layout managers.
> I believe that we agreed already that it will not fly.
> What if I want to layout *children* of display:listitem elements
> using your grid layout? Or [inline-]table-cell?
>
> So far layouts like these:
> http://www.interoperabilitybridges.com/css3-grid-align/CSS%20Grid%20Alignment_files/game-portrait.png
> and
> http://www.interoperabilitybridges.com/css3-grid-align/CSS%20Grid%20Alignment_files/game-landscape.png
> we use templates with numbers - indexes of DOM elements:
>
> flow: "1 2"
>      "3 2"
>      "4 4"
>      "5 5";
>
> flow: "1 4"
>      "2 4"
>      "3 5";
>
> and flex units on width/height properties of cell elements.
>
>
> [1] http://www.w3.org/TR/2007/WD-css3-layout-20070809/
> [2] http://www.terrainformatica.com/htmlayout/flow.whtm
>
> -- 
> Andrew Fedoniouk
>
> http://terrainformatica.com
>
>
>>From: Alex Mogilevsky
>>Sent: Tuesday, October 26, 2010 6:20 PM
>>To: www-style <at> w3.org
>>Subject: [css3-grid-align] -- proposed new grid layout module
>>
>>
>>There is increased interest lately in layout mechanisms that are good for
>>developing application UI.  To address this interest, the IE team would
>>like to explore a two-dimensional grid layout that is consistent with
>>existing layout systems, while providing new capabilities using algorithms
>>that are clean and well-defined.
>>
>>Attached [1] is a proposed specification for "grid alignment".
>>It targets applications in the same space as Template Layout, Tables
>>(historically and often inappropriately), Grid Positioning, and also
>>multiple script solutions.
>>
>>The goal of this proposal is not to compete with existing modules, but
>>rather add and integrate, to make progress towards something that is a
>>good match for the target requirements, while also generating interest
>>from multiple vendors. The particular syntax and behavior shows what the
>>IE team would be interested in, but by no means are we settled on the
>>details.
>>
>>We would like to present this proposal at the F2F.
>>
>>Looking forward to feedback and discussion.
>>Alex
>>
>>[1] http://www.interoperabilitybridges.com/css3-grid-align/
>
> 

Andrew Fedoniouk | 1 Nov 01:40 2010

Re: [css3-grid-align] -- proposed new grid layout module

--------------------------------------------------
From: "François REMY" <fremycompany_pub <at> yahoo.fr>
Sent: Sunday, October 31, 2010 2:38 PM
To: "Andrew Fedoniouk" <news <at> terrainformatica.com>; "Alex Mogilevsky" 
<alexmog <at> microsoft.com>; <www-style <at> w3.org>
Subject: Re: [css3-grid-align] -- proposed new grid layout module

> ?If I can add my 5 cents, too, I would like to say I don't like the 
> Template proposal anymore. While it seemed better at first glance, it adds 
> a lot of complexity and make it difficult to modify the style dynamicly 
> using a script.

That is pretty easy to solve. For example in my implementation this

flow : "1 1"
        "2 3";

is an equivalent of

flow : "1 1|2 3";

so to set it from script you can use:

element.style.flow = "1 1|2 3";

>
> In fact, I don't think Template is easy at all. You say it's easier when 
> you move your objects in the DOM. I think it's not. What if you want to 
> put on a layout manager an element that previously had 'display: a' ? It 
> becomes a nightmare. You should check if the template defines an 'a' slot. 
> Then, you need to check if it's alreay used by another element. In such 
> case, you need to modify the CSS display property of your new element to 
> use another letter, which is not used in the defined template. At last, 
> you should parse the content of the 'display: "aaabbb/ccddee"' property 
> and add new line of a new column where you want to put your element. The 
> ECMAScript code needed to do something like that is incredibly big. And 
> you just wanted to add one column or one row to your display.
>
> Template display is also non-extensible. It does not work if you don't 
> know how many element you want to put on your grid. Then, you are also 
> limited to the 'usable' ASCII range. What if you end up with a grid layout 
> needing more than the available char range ?

As I said I've ended up with use element indexes rather than named
cells.

So if you have defined:
flow : "1 1"
        "2 3";
you can add in that container as many elements as you want.
They will be added as if you have defined this:
flow : "1 1"
        "2 3"
        "4 4"
        "5 5"
        ...
        "N N";

And so you can insert elements in the middle, etc.
Numbers are also not limited by char ranges.

But as I said flow:"template" is an exception - if you have
list of items then it is better to use flow:horizontal[-flow] or
flow:vertical[-flow].

Yet I've seen couple of cases where list items (<li>) by
themselves use template layout inside.

>
> On the other side, the grid proposal is already implemented in some known 
> and widely used products and it's really easy to use. If you want to add a 
> row, you just need to add an element specifying that row index as 
> grid-row. If you want to delete the row, just drop the element. You don't 
> need to care about the template. It just works.

I am not aware about any existing implementation of grid layouts in CSS
except of mine. Will be interesting to take a look. Could you provide
a link?

>
> And if you really want something fully written in CSS for your dynamic 
> grid layout, you can extend the use of 'counter' and allow something like 
> that :
>
> #myGrid div.labelColumn {
>    counter-increment: myGridRow 1;
>    counter-reset: myGridColumn 1;
>    grid-row: counter(myGridRow); grid-column: 1;
> }
>
> #myGrid div.dataColumn {
>    counter-increment: myGridColumn 1;
>    grid-row: counter(myGridRow);
>    grid-column: counter(myGridColumn);
> }

But why not to use <table #myGrid> in this case?
I believe that for tabular data as in your case it is
exactly what doctor have prescribed, no?

>
> I don't think it's possible to do something like that with the Template 
> proposal.

As I said it should be a system of various layout managers that
better suit different cases. There is no silver bullet. And that is the
point.

E.g. in Java there are 8 layout managers available out of the box:
http://download.oracle.com/javase/tutorial/uiswing/layout/visual.html

I have 7 implemented so far

flow: vertical | vertical-flow |
        horizontal | horizontal-flow |
        grid | /*obsolete*/
        stack |
        "template"

all of them use flex units. This is a superset of layout
managers found in Java.

-- 
Andrew Fedoniouk

http://terrainformatica.com

>
> Regards,
> François
>
> -----Message d'origine----- 
> From: Andrew Fedoniouk
> Sent: Sunday, October 31, 2010 9:58 PM
> To: Alex Mogilevsky ; www-style <at> w3.org
> Subject: Re: [css3-grid-align] -- proposed new grid layout module
>
> Well put, Alex!
>
> But here are my 5 cents as this appears close enough to my initial
> flow:grid approach[2] to implement such a layout manager.
>
> The only difference in my case is that I am [re]using
> left/top/right/bottom properties (they are not used in position:static)
> for defining cell element binding to rows/columns.
>
> So this of yours:
>  #board    { grid-column: 2; grid-row: 1; grid-row-span: 2 }
> in my case is this:
>  #board    { left: 2#; top:1#; bottom:2# }
> where '#' is a special "grid location unit".
>
> My variant of defining bindings to rows/columns is very far from being
> perfect. Yours appears as to be better but they share the same set
> of problems.
>
> So all below is based on real experience using them and why
> I've decided to drop this layout manager in favor of something close
> to the Template[1].
>
> At some point I've decided to add Drag-n-Drop support to
> CSS. DnD in CSS is actually another and interesting story per se,
> but for now is this: it raised some set of requirements that forced
> me to revisit problem of grid alike layout[manager]s in CSS.
>
> 1) definition of a child of the Grid should not contain
> grid positions like grid-column and grid-row in your case.
> It is highly desirable to define layout in one place that you can
> [re]define children flow on all-or-none basis.
> Think about of moving #board element in runtime to different container
> that uses its own grid layout.
>
> 2) Way of binding of elements to cells has to be as less error prone
> as possible. E.g. it is too easy to get element overlapping with either
> my flow:grid or display:grid of yours.
> It is also very easy to get grids that will have e.g. only [1,1] and
> [10,10] cells filled by some elements with the rest of the grid filled by
> holes that still occupy space (due to the grid-columns). Grid 
> inconsistency
> errors (overlapping and holes) are very easy to get and very hard to find
> and maintain.
>
> 3) Dimensions of cells must be dependent only on
> dimensions of elements in rows/columns.
> If you have some element with min-width:150px placed
> into column with grid-columns: 100px then it is not
> clear who will win. Dimensions defined in two
> different places, as an option, is bad as it is.
>
> 4) Ideally any layout manager shall keep congruency
> of element position on screen and its position in the DOM.
> E.g. if you have consequent elements A, B and C in the DOM then
> B should be in between A and C visually. Vertically, horizontally or in
> flow.
>
> For example DnD in flow:horizontal (e.g. tabs) containers.
> In such layouts, for any given mouse location, task of finding
> insertion DOM position of the element is trivial and
> very predictable (for the user).
>
> In fact #4 is not only about DnD but also about text selection on the
> page, tab[index] navigations, screen readers (accessibility) and so on.
> I mean that the Grid layout must be used as an exception - as a last
> resort when no other natural layouts are working.
>
> That means we ought to have *system* of layouts where the
> Grid (in one form or another) is just one of them.
> If we have a system of layout[manager]s then we shall try to unify
> them. If all of them use flexes then we shall have flex units defined.
> E.g. your proposal uses 'fr' units, David use "box-flex:" property and 
> Bert
> use '*' for flexes in his proposal.
>
> And again about use of 'display' for defining layout managers.
> I believe that we agreed already that it will not fly.
> What if I want to layout *children* of display:listitem elements
> using your grid layout? Or [inline-]table-cell?
>
> So far layouts like these:
> http://www.interoperabilitybridges.com/css3-grid-align/CSS%20Grid%20Alignment_files/game-portrait.png
> and
> http://www.interoperabilitybridges.com/css3-grid-align/CSS%20Grid%20Alignment_files/game-landscape.png
> we use templates with numbers - indexes of DOM elements:
>
> flow: "1 2"
>      "3 2"
>      "4 4"
>      "5 5";
>
> flow: "1 4"
>      "2 4"
>      "3 5";
>
> and flex units on width/height properties of cell elements.
>
>
> [1] http://www.w3.org/TR/2007/WD-css3-layout-20070809/
> [2] http://www.terrainformatica.com/htmlayout/flow.whtm
>
> -- 
> Andrew Fedoniouk
>
> http://terrainformatica.com
>
>
>>From: Alex Mogilevsky
>>Sent: Tuesday, October 26, 2010 6:20 PM
>>To: www-style <at> w3.org
>>Subject: [css3-grid-align] -- proposed new grid layout module
>>
>>
>>There is increased interest lately in layout mechanisms that are good for
>>developing application UI.  To address this interest, the IE team would
>>like to explore a two-dimensional grid layout that is consistent with
>>existing layout systems, while providing new capabilities using algorithms
>>that are clean and well-defined.
>>
>>Attached [1] is a proposed specification for "grid alignment".
>>It targets applications in the same space as Template Layout, Tables
>>(historically and often inappropriately), Grid Positioning, and also
>>multiple script solutions.
>>
>>The goal of this proposal is not to compete with existing modules, but
>>rather add and integrate, to make progress towards something that is a
>>good match for the target requirements, while also generating interest
>>from multiple vendors. The particular syntax and behavior shows what the
>>IE team would be interested in, but by no means are we settled on the
>>details.
>>
>>We would like to present this proposal at the F2F.
>>
>>Looking forward to feedback and discussion.
>>Alex
>>
>>[1] http://www.interoperabilitybridges.com/css3-grid-align/
>
> 

Aharon (Vladimir) Lanin | 1 Nov 02:27 2010
Picon

Re: directional images

[+public-i18n-bidi <at> ]

On Sun, Oct 31, 2010 at 8:37 PM, Aharon (Vladimir) Lanin <aharon <at> google.com> wrote:
The following is a proposal for a small addition to CSS3 Images in order to make it easier to build web apps that support both LTR and RTL interfaces. For use cases and discussion, see http://www.w3.org/International/docs/html-bidi-requirements/#image-flip.

Expand the syntax of each of the possible ways that an <image> can be specified in CSS3 Images, e.g. <url>, <image-list>, and <gradient>, by allowing a new keyword: rtlflip. Examples would be:

  • background-image: linear-gradient(45deg, white, black) rtlflip
  • list-style-image: url('sprite.png#xywh=10,30,60,20') rtlflip

The presence of the rtlflip keyword means that the image must be horizontally flipped when the element's CSS direction (or, in the case of list-style-image, the list item marker's direction, as defined by the list-style-direction CSS property) is rtl.

Alternatively, instead of rtlflip, the syntax could be to allow one of two new keywords: ltr or rtl. The presence of one of these would declare the image's direction and specify that the image should be horizontally flipped when this direction does not match the element's CSS direction (or, in the case of list-style-image, the list item marker's direction). Being declarative as opposed to instructive, this alternative is more elegant than rtlflip, but requires two new keywords instead of one. It is up to the CSS WG to choose the better syntax.

Aharon Lanin

Aharon (Vladimir) Lanin | 1 Nov 03:03 2010
Picon

[css3 lists] list-style-direction

The following is a proposal for some bidi-related changes to CSS3 Lists.

1. An additional list-related property: list-style-direction.

The property would determine the direction of the list marker, when it is a separate box, i.e. when list-item-position is "outside". The effects of the marker's direction include:
  • The location of the marker box, since it is on the "start" side of list-style-direction. For example, with list-item-direction:ltr, the marker box is to the left of the list item.
  • The bidirectional ordering of the marker text. For example, with list-item-direction:rtl, the marker text "1." is displayed visually as ".1".
list-style-direction would take one of the following values:
  • ltr
  • rtl
  • match-list
  • match-item
For backward compatibility with CSS2, the default value would be match-item.

Note, however, that since the marker box is displayed in the margin, and since a list by default only creates a margin on its start side, match-item works poorly for  list items whose direction is opposite to the list's direction. This is the reason why currently, most or all of the marker is invisible for such items in all major browsers. Furthermore, it turns out that in many or most use cases (at least in Hebrew, Arabic, and Persian), the preferred look is to have all markers appear on the same side, even though different items have different direction. Thus, we would really want the default to be match-list, but can not make it so because of CSS2 behavior.

As a workaround, we therefore propose that the default style sheet would specify list-item-direction:match-list for all ol and ul elements.

2. Currently, there is no interoperability regarding whether text-align applies to the list item marker when list-item-position is "outside". IE, Firefox and Opera keep the marker with the item, i.e. apply the alignment to the marker. WebKit, on the other hand, applies the alignment only to the item, but keeps the marker location constant regardless of text-align. As a result, there is a big difference between the way <ul style="text-align:end> is displayed in WebKit and the other browsers.

I bring this up in this context because the same issue would come up for list-style-direction:match-list in combination with text-align:start as it applies to opposite-direction items.

IMHO, WebKit's approach here is more useful. When users want the marker kept together with the item, they should use list-style-position:inside. With list-style-position:outside, the markers should line up.

Aharon

John Daggett | 1 Nov 08:13 2010

[css3-writing-modes] new editor's draft


The new editor's draft of the CSS3 Writing Mode spec contains a very broad proposal for the inclusion of
logical properties in CSS.  I would encourage everyone with any interest to look over this new draft
published today.

Regards,

John Daggett

Markus Mielke | 1 Nov 10:06 2010
Picon

RE: [css3-writing-modes] new editor's draft

Can you please repost the link?

-----Original Message-----
From: www-style-request <at> w3.org [mailto:www-style-request <at> w3.org] On Behalf Of John Daggett
Sent: Monday, November 01, 2010 12:14 AM
To: www-style <at> w3.org CSS
Subject: [css3-writing-modes] new editor's draft


The new editor's draft of the CSS3 Writing Mode spec contains a very broad proposal for the inclusion of
logical properties in CSS.  I would encourage everyone with any interest to look over this new draft
published today.

Regards,

John Daggett


fantasai | 1 Nov 10:11 2010
Picon

Re: [css3-writing-modes] new editor's draft

On 11/01/2010 12:13 AM, John Daggett wrote:
>
> The new editor's draft of the CSS3 Writing Mode spec contains a very
> broad proposal for the inclusion of logical properties in CSS.  I
> would encourage everyone with any interest to look over this new
> draft published today.

http://dev.w3.org/csswg/css3-writing-modes/

~fantasai

Philippe Wittenbergh | 1 Nov 10:19 2010

Re: [css3-writing-modes] new editor's draft


On Nov 1, 2010, at 6:06 PM, Markus Mielke wrote:

> Can you please repost the link?

http://dev.w3.org/csswg/css3-writing-modes/

Philippe
---
Philippe Wittenbergh
http://l-c-n.com/

François REMY | 1 Nov 11:11 2010
Picon

Re: [css3-grid-align] -- proposed new grid layout module

?It seems you kinda solved the char range problem with your numbered slots. 
Well thought. Still, it's pretty difficult to modify the layout dynamicly 
due to the complexity of the template string parsing (see later in this 
mail).

BTW, when I spoke about 'grid' implementation, I wasn't speaking about CSS. 
I was thinking to WPF/Silverlight [1], Java [2], and similar UI builders.

As for the 'why would you use grid and not a table' question, I think the 
application is immediate. Imagine you would like to build an Excel Web App, 
you don't want to define a 80000*10000 table, even with a script. With a 
Grid layout, you can only fill the cells which are non-empty. I don't think 
you can with the template proposal (you still need a pretty huge template 
definition).

Also, with the Grid proposal, it's easy to merge two cells (you just need to 
take one cell and set 'grid-row-span' to 2). With a template, you would need 
to parse your entire template string, make the right adjustement and then 
have the browser reparse your string entirely.

To conclude, I don't say the template proposal is not usable, but I argue 
it's only suitable for case where the number of elements is relatively 
small, and not likely to change.

Regards,
François

[1] http://wpftutorial.net/GridLayout.html
[2] 
http://download.oracle.com/javase/1.4.2/docs/api/java/awt/GridLayout.html 


Gmane