Proposal: Simplify Grid Column and Row Definitions

[dotMorten]

Summary

The proposal is to simplify the definition syntax of Rows and Columns by:

• Allowing rows and columns within a Grid to be defined by a collection that is delimited by commas and single quotes.
• Assigning the content property of ColumnDefinition to Width and RowDefinition to Height, and defining the CreateFromString attribute for ColumnDefinitions and RowDefinitions classes, which will allow the shortened syntax to work.

Goal

The goal of this feature is to make Grid easier and more intuitive to write and learn. A major consideration for this proposal is to assure that any new syntax can work as a generalized language feature to fit other use cases across XAML.

Example

Current Syntax

Defining columns and rows is overly tedious, repetitive and not very productive, as is shown below:

<Grid>
    <Grid.ColumnDefinitions>
          <ColumnDefinition Width="1*" />
          <ColumnDefinition Width="2*" />
          <ColumnDefinition Width="Auto" />
          <ColumnDefinition Width="*" />
          <ColumnDefinition Width="300" />
    </Grid.ColumnDefinitions>
    <Grid.RowDefinitions>
          <RowDefinition Height="1*" />
          <RowDefinition Height="Auto" />
          <RowDefinition Height="25" />
          <RowDefinition Height= "14" />
          <RowDefinition Height="20" />
    </Grid.RowDefinitions>
</Grid>

Proposed Syntax

The same functionality as above with the proposed succinct syntax is shown below:

<Grid ColumnDefinitions="1*, 2*, Auto, *, 300"
      RowDefinitions="1*, Auto, 25, 14, 20">
</Grid>

The following syntax will also be valid after the new language feature is implemented:

<Grid>
    <Grid.ColumnDefinitions>
          <ColumnDefinition>1*</ColumnDefinition>
          <ColumnDefinition>2*</ColumnDefinition>
          <ColumnDefinition>Auto</ColumnDefinition>
          <ColumnDefinition>*</ColumnDefinition>
          <ColumnDefinition>300</ColumnDefinition>
    </Grid.ColumnDefinitions>
    <Grid.RowDefinitions>
          <RowDefinition>1*</RowDefinition>
          <RowDefinition>Auto</RowDefinition>
          <RowDefinition>25</RowDefinition>
          <RowDefinition>14</RowDefinition>
          <RowDefinition>20</RowDefinition>
    </Grid.RowDefinitions>
</Grid>

Rationale

A new grid syntax would not only improve developer satisfaction and productivity but would also minimize the learning curve required to use Grid, one of the most widely used controls. The original syntax would be kept in place to use for more complex scenarios and so older applications don’t have to be changed.

Implementing the succinct syntax will require the creation of a new XAML language feature, as typeconverters cannot be created for or used on read-only collections (which ColumnDefinitions and RowDefinitions are). In creating this new language feature, we wanted to make sure the syntax can be generalized for possible future use cases, including collections that may include Point objects, sets, or even string values that contain commas themselves. A comma-and-quotes-separated list is intuitive for single values (such as column heights), but is also readable for more complex types, such as Points. Examples of different syntax scenarios are below:

Succinct syntax for Grid definitions (numerical values)

<Grid ColumnDefinitions="1*, 2*, Auto, *, 300"/>

Succinct syntax for more complex types of values

// A list of points: 
<Foo PointList=" '1,2', '9,4', '2,6'"/>

// A collection of strings:
<Bar Words=" 'hello', 'world', 'hello, world!', 'it&apos;s a beautiful day'" /> 
//note that apostrophe/single quote character can be escaped by using the HTML entity.

// Collection of dates for CalendarView:
<CalendarView SelectedDates="'1/5/1977', '6/19/1997'" />

Scope

Feature	Priority
Ability for rows and columns to be defined as a collection or list of values (using CreateFromString attribute)	Must
Content properties of RowDefinition and ColumnDefinition are set to Height and Width, respectively	Must
Original syntax will still be fully supported and functional	Must
Uses a syntax that can eventually be generalized across all XAML read-only collection-typed properties	Must
Include support for min/max height/width	Won't
Include support for data binding within definitions	Won't
Include support for blank values or default values	Won't

Appendix

A syntax that uses a list separated by commas and quotes was chosen due to:

• An overwhelming response from the community in favor of a comma delimiter
• The ability of single quotes to separate more complex structures such as Point objects and sets as well as support strings that use commas
• The combination of the two makes it so collections containing only simple types will require only commas as a delimiter, and collections containing more complex types will use single quotes and commas as delimiters, keeping everything intuitive and using familiar syntax patterns for developers.

[mdtauk]

Might I suggest there be consideration for the ability to add a name or key to columns, do you can declare it in XAML.

<Button Grid.Row="Toolbar" />

[dotMorten]

@mdtauk that's part of the bigger issue I link to. This issue was specifically for a small subset that doesn't add any new feature but just simplifies the xaml

[mdtauk]

You mention string conversion, so I thought adding a string value for a name could translate to an int value assigned Inthe definition lists?

[dotMorten]

But named columns is adding an entirely new feature. I purposely tried to keep this suggestion without adding new features.

[michael-hawker]

Yeah, it'd be great if we could add this exact same shortcut to both UWP Grid and WPF Grid.

[MartinZikmund]

Great idea, love it!

[Sergio0694]

This looks great!
Also, I like the fact that we can actually already achieve this with attached properties, while we wait for this to be officially implemented into the various frameworks 😄

I have a small issue with that syntax though, I feel like the ,,, syntax for default rows/columns might be a bit error prone and possibly difficult to read while glancing over the code. 🤔
Also, the fact that having just 3 commas would actually correspond to 4 rows/columns.
What about using *,*,*,* (or 1*,1*,1*,1* if you will), so that it's easier to read and less likely to get wrong?

[bmacombe]

@dotMorten This would probably be a good addition to Xamarin Forms if it hasn't been proposed already. Maybe after it's discussed well here first.

[andrund]

This is great and exactly what som people have done in custom controls, so it feels familiar. Any ideas how to handle Max/Min Width/Height.

[dotMorten]

Any ideas how to handle Max/Min Width/Height.

Ah shucks. Didn't think about that. One simple solution is just to state you don't get that fine grained control with the simple syntax (in order to keep the syntax simple and focus on covering the most common scenarios).

[mdtauk]

We should avoid introducing a simpler syntax that would eventually be replaced by the more robust and powerful new syntax and functionality.

So whatever is decided about this simple width/height syntax, it needs to keep in mind what comes next

[mrlacey]

What about using ,,, (or 1*,1*,1*,1* if you will), so that it's easier to read and less likely to get wrong?

This is inconsistent with other shortcuts (such as margin, or padding) where commas (or spaces) are between values, not after them.
I would find the trailing comma confusing.

[Sergio0694]

@mrlacey wait, I think you misquoted my message 🤔
I 100% agree that having a trailing comma wouldn't be ok, that's exactly why I posted that suggestion. The trailing commas are actually in the first post of this proposal, not in my message.

What I suggested (just as an idea, not necessary the best possible syntax) was to use *,*,*,* or 1*,1*,1*,1* instead of ,,, like the first post suggested, for precisely the reason you just mentioned.

EDIT: I mean, in the first post of this proposal you can actually read RowDefinitions="1*,Auto,25,,", which has indeed the issue of inconsistent syntax, with trailing commas and commas with no values in between.

[mrlacey]

@Sergio0694 my mistake. you are correct.
@dotMorten what did you mean by the syntax RowDefinitions="1*,Auto,25,,"?

[mdtauk]

I don't think you should be able to add empty rows, so each entry would need at least a *, so having a collection of commas without values would be invalid

[Sergio0694]

@mdtauk Precisely what I was suggesting 😄
But that might very well just have been a typo in the first post.

[RichiCoder1]

Some inspiration from CSS Grid would be great here (though possibly throw the scope out)

RowDefinitions="20, 1*, Minmax(30, 2*), Repeat(3, 200)" and so on.

[dotMorten]

@mrlacey

what did you mean by the syntax RowDefinitions="1*,Auto,25,,"?

The equivalent XAML was just above it

[thomasclaudiushuber]

@dotMorten First of all, I really like this issue, as it's a quick win! Great idea to extract this from the bigger issue.

The equivalent XAML was just above it

Yes, but the equivalent XAML for ,, are two 1* RowDefinitions. So, I think - like @mrlacey and @Sergio0694 mentioned - we shouldn't have empty values in the new short-hand syntax, as you should be able to use that syntax also without commas, but spaces instead (like you can for example for Margin).

These should be possible options:

<Grid RowDefinitions="1*,Auto,25,1*,1*"/>

<Grid RowDefinitions="*,Auto,25,*,*"/>

<Grid RowDefinitions="1* Auto 25 1* 1*"/>

<Grid RowDefinitions="* Auto 25 * *"/>

But not empty values like here, as it doesn't allow the space-instead-of-comma-syntax:

<Grid RowDefinitions=",Auto,25,,"/>

[corradocavalli]

I Love it! 👍

[jsuarezruiz]

Very nice idea!

[MichaelRumpler]

Good idea!

The same could be done for cell positions. Instead of

<TextBlock Grid.Column="2" Grid.ColumnSpan="3" Grid.Row="5" Grid.RowSpan="2" Text="Something" />

one could write

<TextBlock Grid.Cell="2-4/5-6" Text="Something" />

(I assume that the ranges are inclusive here, but I may be overruled as I was with System.Range)

This would also not be a new feature, but only a simpler syntax.

I do realize that / and - did not appear in XAML string properties yet, but IMHO this is more readable than just some numbers and ,. I always have the problem with Margin that I don't know which value is top, right, bottom and left as this is different in XAML and CSS. But / and - cannot easily be misinterpreted.

[dotMorten]

@MichaelRumpler interesting idea but it again goes against the premise of this issue by introducing a new API (Grid.Set/GetCell and not sure what the type would be?) and this introducing more red tape to get it through. Issue #51 is where the more advanced stuff is discussed.

[wbokkers]

I like it! It would be nice to still support databinding with this syntax:

<Grid RowDefinitions="{x:Bind Vm.FirstRowDefinition},1*,Auto">

[dotMorten]

@wbokkers I don't think that's possible with a string converter. I think the idea of keeping it simple for the 80% use case, and use full syntax when you need more fine-grained control is the best/simplest/most-achievable way to go.

Trying to solve all possible suggestions will just lead to a complicated design with a million devilled details that we'd never be able to push through.

[Sergio0694]

Also @MichaelRumpler - you probably already know this, but just in case, if you really want to use that Grid.Cell property (or equivalent), you can just implement your own attached property that takes a string with that syntax you used, parses it and then sets all the various Grid.Row, Grid.RowSpan, Grid.Column and Grid.ColumnSpan attached properties on the target control 👍

[thomasclaudiushuber]

Yes, I 100% agree with @dotMorten and @Sergio0694.

@MichaelRumpler I like that syntax, but it would mean we have to add another attached property that gives you exactly the same behavior that we have already with the existing properties. So, it's pretty much a "proxy property". I think what @Sergio0694 said is good, using an attached property that doesn't necessarily have to be in the Grid class works for this.

@wbokkers I think that's a really hard one. x:Bind generates code at compile-time, the string is converted at runtime. In addition, the markup extension is only half of the attribute value. I've never seen something like that. While it could make sense, I think it's a very complicated thing to implement. And I can't remember many cases where I needed a data binding for the sizes of RowDefs/ColDefs, so I'd say, let's keep it simple, and if a dev needs a data binding, they could still go with the normal object element syntax.

So, let's keep this issue simple, so that we can get it through. I think this was also the idea why @dotMorten created this separate issue, because it's a quick win that is not too hard to implement.

If I see it correctly, @Sergio0694, @mrlacey, @mdtauk, and I agreed that we don't want empty values between the commas, and no one else said empty values should be supported (Except the initial proposal from @dotMorten ).

So, @dotMorten, the rest of this comment is for you. :-)

What do you think with adjusting the initial proposal with the possible syntax options I wrote in my previous comment? And getting rid of this:

An empty/no value is equivalent to not setting Width/Height and the default is used.

And add this:

Should be a comma-separated or space-separated list.

And add here additional, and write that you might want to do this for better readability. Ignoring the spaces doesn't give you a better readability, you add them to get a better readability, and the string converter ignores them (The additional spaces, as you should be able to split the values also by spaces):

Additional spaces are allowed/ignored (you might want to add them for better readability).

And maybe write explicitly that min/max values are not supported. Then we can have another issue once this is implemented.

[wbokkers]

You're right in not wanting to overcomplicate things. I use databinding here in maybe 0.01% of the grids I use.

[wbokkers]

This works great with WinUI 3 Desktop. But unfortunately it breaks XAML Hot Reload.

[MikeHillberg]

@RealTommyKlein

[AlexanderBlackman]

This works great with WinUI 3 Desktop. But unfortunately it breaks XAML Hot Reload.

I can confirm this is still a problem in Visual Studio 22 (17.0.4)

It does not affect the app itself, but still gives an error and stops hot reload.
Error XHR0013 The property "RowDefinitions" does not have an accessible setter

[StephenLPeters]

@evelynwu-msft @RealTommyKlein FYI

[RealTommyKlein]

Should be fixable by updating the tooling on WASDK's end to understand how to instantiate collections from strings the same way this feature did for markup loaded normally. But that is more of a feature-level request which wouldn't meet the bar for Windows App SDK 1.1.

[lukasf]

This works great with WinUI 3 Desktop. But unfortunately it breaks XAML Hot Reload.

I can confirm this is still a problem in Visual Studio 22 (17.0.4)

It does not affect the app itself, but still gives an error and stops hot reload. Error XHR0013 The property "RowDefinitions" does not have an accessible setter

Is this being worked on? It's not only that changes to grid definitions do not work, but hot reload is completely broken, if you are using the simplified syntax on a page. That's not acceptable.

[Balkoth]

Can hot reload please be fixed?

[dotMorten]

You should log a visual studio bug using the feedback tool. I agree this is super annoying and the main reason I don't even use the feature I suggested.

[evelynwu-msft]

@Balkoth We've been tracking that issue internally and haven't forgotten about it, but unfortunately it's not likely to be fixed soon (I'm sorry, I'm sure that wasn't the outcome you were hoping for). Feel free to create a separate issue in this repo, though, if you'd like to be notified when the internal status changes.

[Balkoth]

To me its crazy that hot reload always gets mentioned when the question about a real designer comes up and then hot reload gets broken by new features. I will just ignore this feature, as it is not worth the hassle.

[AMArostegui]

To me its crazy that hot reload always gets mentioned when the question about a real designer comes up and then hot reload gets broken by new features. I will just ignore this feature, as it is not worth the hassle.

This is on point. If Hot Reload is meant to be the "alternative" to XAML Designer, at least the team should keep focus on robustness. Not being able to dynamically change cols/rows would be acceptable, but the syntax breaks the feature completely

[MartinZikmund]

I have hit the hot reload issue as well, indeed after the removal of all RowDefinitions and ColumnDefinitions attributes hot reload works reliably.

[AMArostegui]

The problem is for the unsuspecting developer using the feature. After some work he discovers Hot Reload is not working, and needs to traceback until the moment it did. Just then he realizes that the abbreviated syntax provokes this bug. This is time consuming and annoying.