Just realizing that it’s not currently possible to set display:grid for plain DIVs. It’s only available for Query Templates and repeaters.
I think this should be an option as well.
1 Like
I agree. Also it would be nice to have an option to set display: grid to sections as well.
This feature would solve my problem of native table that is for now terrible.
The reason I’m not so keen in introducing display:grid is the fact that it isn’t that useful on its own.
Do you have a specific use case in mind?
I think it is pretty useful. I use it a lot for various purposes very often. The reason why Grid layout may be helpful for us is that we can easily style the layout of child elements (like col-span etc).
1 Like
Wouldn’t you use just the columns block in that case? It is basically just a div which gives you full control about the child elements, using the Grid Layout Editor.
I mean, yeah. Why not add the grid value to the display property.
But as @Louis mentioned, it is pretty useless on its own.
But I can see scenarios when working with a framework or additional/global classes where people will find it useful.
2 Likes
I’ve been busy, but an issue I’m facing over here has reignited this issue for me.
I know Cwicly’s column block is, in effect, a grid container. It works, but it has been designed with a very specific approach to grid building. It feels a bit unintuitive. I’m often using trial and error to achieve the results I need.
CSS Grid is tricky. And implementing it in a no-code fashion is definitely challenging, but I don’t know that the column block is doing a good job of it.
1 Like
Sorry to hear that the Columns block doesn’t fit your needs.
I’d love to hear what you find is unintuitive and see how we can improve things.
It is restrictive in some ways, I will agree with you on that. But I do find that personally it takes away from the hassle of grid which is sometimes a bore to keep tabs on.
Make sure to check out our video on the Columns Block also 
Hi Louis,
I will preface all of this by saying that I am bit of a purist.
I like when the tools get out of the way and allow me the freedom to create. This is why I am such a massive supporter and evangelist of Cwicly. You have built Cwicly on a foundation of basic HTML building blocks and best practices, which we can then use to create complex layouts. And always so elegant in execution.
For example, the implementation of flex box, along with exposing just about all flex properties (grow, shrink, basis, wrap/wrap-reverse, etc) is a level of elegance that’s unmatched outside of something like Webflow.
I feel like the columns block is one of the exceptions. It works in a very specific way. It works, though, and I’m able to get what I want done eventually with a bit of trial and error.
That said, a few quirks I don’t really enjoy:
- That it adds blocks (additional containers) to create grid child elements feels unintuitive to me.
- The min-height issue (which I see you have confirmed), so that will go away soon enough.
- Gap units are restricted to pixels only (may be worth a separate feature request?)
- Overall it tends to feel a bit fiddly, if that makes sense. I feel less confident in the results, and it takes some trial and error. I’m sure I will eventually learn how this specific element works, but it definitely feels like a departure from how Cwicly does other things (again, see flexbox). Maybe you’ve spoiled me
This isn’t an urgent request, of course. Just one of those quality of life things.
2 Likes
“Gap units are restricted to pixels only (may be worth a separate feature request?)”
I didn’t even noticed that so far. This would definitely be a good feature request.
2 Likes
Thanks for taking the time to write down your thoughts and impressions @owynter.
Overall, I can understand and appreciate your concerns about the way we’ve handled the Columns block in a whole. We might review it in the future (maybe have a Pro Columns block) which allows more precise control over the Grid element.
Good point.
We based ourselves on how the Gutenberg Columns block was designed at the start, which is a limiting factor for us now since the container is necessary and cannot be removed. But a Pro Columns block could be the solution.
Fixed in our next update 
Good point, will add that to our to-do.
I’m sad to hear that. We certainly did focus on trying to make the Grid easy to use:
3 Likes
This is actually the only main issue/limitation I have so far with the columns block.
All in all I can’t complain at all with that particular block.
I really appreciate that it is a part from the very beginning which takes away so much headache.
I’m really happy how Cwicly generally is designed when it comes to the basic structure (solved with grid) and positioning (solved with flex as default).
1 Like
It might not be a good use case to put it on a Section. The Div makes perfect sense as it’s a stand-alone container. The Section uses an inner wrapping Div by default, which is good. But, placing Grid on a Section would stop you, for instance, from easily placing a heading above the Grid as it would have to be placed above the Section.
@Louis Is the Pro Columns Block on radar? I also find the current implementation somewhat rigid like @owynter said.
I do notice a “display: grid” option under the layout panel, but it doesn’t seem to do much except add the declaration. I don’t see anything that allows for grid manipulation with the child elements, except via CSS. In any case, I’m fine with the current grid/columns implementation and haven’t run into anything that made me think we needed something different.
I suppose having the option to set display: grid to a div, with the grid settings, where we can manually add child divs would be handy, but I haven’t run into a use case for myself personally.
I would, however, really like to see the section element displayed in the navigator as a section with a div inside, rather than just the section. It’s easy enough to work with it via relative styles, but I think having the correct structure would make it even better.
These are more “nice to haves” and not necessary since everything works perfectly fine as is.
4 Likes
Hi @anon32808828,
Thanks for bringing this up again.
Honestly, I don’t think a Pro Columns block is on the radar.
The reason is because we’re planning to bring all CSS Grid properties to the display: grid; option as @msguerra74 pointed out. A sort of mini grid generator directly available within the display property.
This will allow complete freedom as to how the inner elements are put together, while allowing you to control every aspect of the CSS Grid with the properties themselves.
We’re still working on the specifics, but that’s the plan.
13 Likes
If it’s possible to squeeze in, I’d also love if you could manually set the ‘grid-template’ property.
I find that I often use grid-template-columns: 5fr 7fr, but with most page builders I need to set it with custom CSS.
You’d think you could just set the grid to 12 fractions and adjust your two columns accordingly, but your grid gap actually gets applied to every single fraction. That means if you if you have a 12 fraction grid with a 200px gap, your page will have a horizontal overflow (in Firefox) for any viewport under 2400px (12fr x 200px gap).
4 Likes
I’m really looking forward to this.
Being able to set a grid template column like this:
grid-template-columns: fit-content(40%) 1fr 1fr;
directly in the Cwicly interface will be a great help since adding it into the Advanced > Custom CSS area can end up being a bit of a pain if you need to change things for smaller viewport sizes.
4 Likes
Glad to see this is still getting some attention. Definitely a nice-to-have.
And Louis would be happy to know that I’ve fallen in love with the simplicity of the columns block. Didn’t like it at first, and chose to go with flexbox, but it’s proven to be a timesaver. The freedom to add my variable units is also a really welcome addition.
Getting display:grid as an advanced feature is mouthwatering. Can’t wait to see how it’s implemented.
8 Likes
Extending existing functionality and interface instead of adding a new option with overlapping or colliding features sounds like a good plan to me
2 Likes