Why does the grid class exist?

[dev-willis]

I understand that providing a complete grid system is beyond the scope of Pico and I think this is the right choice. So why provide the .grid class at all? It breaks separation of concerns by describing presentation in the structure, doesn't apply in every situation and so is semantically problematic, and it can't be used without writing custom CSS anyway so it doesn't really save any time. So why not drop it and shave a little weight off? Or is there a use-case I'm not seeing?

[ethanpil]

@dev-willis please see my notes here: #582

[dev-willis]

My issue isn't with the functionality of the .grid class (although the functionality does leave something to be desired as well) but with the philosophy of its existence. Classes should not describe presentation. I'll modify my question to make this clearer.

[Deufel]

its pretty useful for concise modification like this one liner is pretty nice to add to your grid classes.

grid-template-columns:repeat(auto-fill, minmax(300px), 1fr))

[dev-willis]

I can see how it could be handy sometimes but, to me, layout is a design decision and, for philosophical reasons, I don't think classes or IDs should describe layout. Elements that display as a grid on large screens and landscape orientations often do not on small screens and portrait orientations. Also, there are lots of situations where a utility class might be handy, so where do you draw the line on which ones to include? If you don't draw a line at all, you get Tailwind.

[Deufel]

pico is described as a Symantec css style sheet. Maybe I don't understand what your proposing here; are saying remove grid because it does not describe the default functionality well enough? (of of row on big screen, column on small screen?)

[dev-willis]

No, I'm saying remove it because it's describing the presentation of the content. We want separation of concerns but this mixes presentation with structure. Classes should not describe how the content is displayed.

[pixobit]

I'm glad there's a classless version, so you can have your cake, and eat it too. That being said, I also see a lot of value in .grid, since you can achieve a lot with very minimal weight... I would like to suggest the use of variables. With a tiny change to the current .grid class, we can actually open a lot of possibilities:

(I didn't put much thought into the variable names...):

:root {
--pico-grid-cols: auto-fit;
--pico-grid-col-span: 1;
}
.grid > * {
grid-column: --var(--pico-grid-col-span);
}

Now we can do cool things like

<div class="grid" style="--pico-grid-cols: 5">
  <div style="--pico-grid-col-span: span 2">1</div>
  <div>2</div>
  <div>3</div>
  <div>4</div>
</div>

[dev-willis]

Respectfully, your example is rather Tailwind-y which, to me, is the opposite of cool (I really dislike Tailwind's entire philosophy lol). You've got inline styles and a class name all describing the presentation of the content, which not only breaks separation of concerns but also cannot apply to every situation and will need to be overridden somehow. When that happens, not only will you have to work against your markup/framework but you'll also wind up with a container that says it's a grid but isn't and columns which say they're a certain width but aren't.

I would much rather have markup like this:

<div class="callouts">
    <div>Callout One</div>
    <div>Callout Two</div>
    <div>Callout Tre</div>
    <div>Callout For</div>
</div>

Here, the class is describing what the content is rather than how it should look in one particular situation. This opens up the maximum number of possibilities as it doesn't require to me to work against my framework. I can take advantage of default behavior (display:block) for small screens and then apply custom styles (e.g. display:grid) for larger screens. And, philosophy aside, having the .grid class doesn't save me any time as I still have to write custom CSS to override it in situations where display:grid is not appropriate or when more than one row is necessary.