Using Elements I am struggling to find a way to select individual columns in grid to resize each. When I add the grid to the page it shows as a single column even when the base 4 column setting is in place. I would like to be able to make each column a specific size. If I choose to have 5 columns in the grid I would to be able to set the 1fr value.
After you have dragged the grid on to the page you won’t see the columns until you drag some content into the grid. Drag and drop a CONTAINER into the grid and it will be shown at whatever number of columns you have set. Then when you drag the next container into the grid an insertion point will be displayed to the right or left of the first container you dragged in. Drop the container and there will now be two columns. Keep repeating for the number of columns you have setup.
When you drag these containers into the grid you can change their type to GRID ITEM, which will then allow you to control their width. For a 4 column grid I set the grid to 4 columns and each grid item to 1. Or alternatively you can set the grid to 12 and each column to 3, which is essentially the same thing. I find it easier to use the first approach.
Grids can be very confusing to say the least.
NOTE: if you are doing a mobile-first design and you start with the smallest breakpoint. You will need to start with a different setting for the number of columns. You would start out with a SINGLE column. Then as you work through your different breakpoints you will get to a width where you want to have the columns side by side. You will then have to override the number of columns to your desired number of 4. Now all of the columns will be side by side.
1 Like
Thank You for your wonderful support!
2 Likes
@handshaper that’s a great explanation, I think we’ll “borrow” that to get started with the Grid page in the manual, if that’s okay? 
Not a problem, as long as it was accurate.
1 Like
I don’t think this really solves the problem.
For instance, I am wanting to have a 3 column grid with fixed size outer-columns (e.g. max-content) with the middle column consuming the remaining space (e.g. 1fr).
Currently there are approximations which can be done by altering the total number of grid columns at different breakpoints, along with the span of the middle content, but it’s a complicated and less satisfactory method than just specifying grid-template-columns: max-content 1fr max-content;.
There’s also an approximation by using available Tailwind classes, but I believe these are limiting, not to mention confusing.
Creating a custom class and inserting a link to an external CSS file would be a solution. But would it be overridden by Elements’ styling?
Also, I could create a custom component and create the HTML myself. Feels a bit too hard.
I suppose I’m asking: if Elements doesn’t have a UI setting for column dimensions, is there any way of injecting styling code directly into a component?
Right now, the Grid component is based on a set number of columns—anywhere from 1 to 12.
I definitely agree it would be great to support more advanced column and row definitions, like the example you gave: grid-template-columns: max-content 1fr max-content;
Not sure when (or if) this might make its way into the Grid component, but it’s definitely something I think would be a valuable addition 
You can achieve a custom grid definition by using the Advanced → CSS Classes field and applying a Tailwind arbitrary value class, like this:
grid-cols-[max-content_1fr_max-content]
That way, you can get the layout control you need without having to resort to a full custom component or external stylesheet.
1 Like
Hey, that actually worked.
I saw the custom option in the TailWind docs, but imagined it must be a limited number of possible combinations.
I’d not heard of TailWind prior to Elements, so don’t claim to understand it. I’m guessing it uses a dynamic css file in there where non-defined classes are passed through an interpreter and the server returns a calculated response.
1 Like
In tailwind this “custom” option is known as Arbitrary Values.
Tailwind’s arbitrary values let you use custom values not included in the default design system. You write them in square brackets.
Some examples of arbitrary classes:
Padding: p-[2rem]
Translate: translate-x-[25vw]
Grid: grid-cols-[repeat(3,_200px)]
Elements processes all of your pages and only generates only the CSS it needs - this keeps the CSS very minimal as there’s no CSS generated for things that aren’t required or being used.
This is all done on the fly as you edit your site in Elements. When you publish, Elements publishes the required CSS to your server. There’s nothing fancy going on with interpreters on the server.
Hope that explains things some more, let me know if you have more questions 
Becoming clearer. So tailwind offers a “translation” service which Elements utilises to generate the classes? The result of this translation then gets included in the final site, rather than the site referencing online tailwind classes? That makes more sense.
Is this still to be implemented?
Why I ask is because I just created the simplest page I could think of (single text component with no additional formatting) and exported the site.
Looking at the resulting html, I see it includes 14 script files containing roughly 12500 lines of code, plus a css file containing 600 lines of styles. And the styles include lots of redundant formatting, such as “<something here>:inherit”, “text-opacity: 100%” etc.
There are also styles for form components and many other things which aren’t on the page.
Basically, yes! Elements uses a tailwind CSS generation tool in the app to generate all the CSS your site needs. That CSS file(s) is then published alongside your site - there is no referencing of online tailwind classes. Everything becomes standard CSS and lives on your server.
When you write a class like p-[123px] the generated CSS will be:
.p-\[123px\] {
padding: 123px;
}
We are still working on the javascript inclusion, and hope to have a more concise, minified set of default javascript in the near future.
Side now: The javascript files are a completely separate issue from the CSS generation.
We include a “reset” CSS file which contains styles for normalising a lot of things, including form inputs.
Hope that helps