Support grid

[dbaynard]

It needs a new module.

https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layout/Grids

https://css-tricks.com/snippets/css/complete-guide-grid/

[BebeSparkelSparkel]

I would like to help create this.

1. What is the best file to pattern off of for this, src/Clay/FlexBox.hs?
2. Is https://drafts.csswg.org/css-grid-1/ a good reference for the grid spec?

[bsima]

Yes Clay.FlexBox is a good module to study. I always use MDN docs for web stuff, they have really high quality docs https://developer.mozilla.org/en-US/docs/Web/CSS/grid I’ll just search “mdn <term>” like “mdn css grid” and it pops right up on DuckDuckGo I would be happy to review the code when you get something together and help however I can. I’m in the process of moving and starting a new job, but I’m also heavily invested in Clay and want to see it succeed. (FYI I’ve thought about forking this repo and applying some patches I’ve made myself in a closed codebase, but haven’t found the time to yet)

…

Sent from my iPhone

On May 28, 2019, at 14:56, William Rusnack ***@***.***> wrote: I would like to help create this. What is the best file to pattern off of for this, src/Clay/FlexBox.hs? Is https://drafts.csswg.org/css-grid-1/ a good reference for the grid spec? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[dbaynard]

I offered to help maintain clay but despite a positive response, the repo owner never made any moves.

I've written some extras in dbaynard/cascade (it was meant to be a high level wrapper with examples of styles but it has mutated a little.)

As it happens, there are design choices made in clay that I think might be improved, so I'm holding off on repeating my offer until I've investigated these alternatives.

(Edit: links and typos)

[BebeSparkelSparkel]

@dbaynard Which other ones have you seen that you like?

[dbaynard]

@BebeSparkelSparkel I don't quite understand your question, but if you mean other design choices: something which integrates with a parser, or the technique used by https://hackage.haskell.org/package/type-of-html.

[turion]

Hi @dbaynard, new maintainer here. Sounds like a good and popular feature to support. If you have an idea how to approach this, feel free to create a PR, I'll review and merge :)

[github-actions]

Stale issue message

[turion]

@BebeSparkelSparkel are you interested in this issue and would like to contribute?

[BebeSparkelSparkel]

@turion Sorry haven't looked at this for a while. I have switched to Shakespeare Lucius for now.
I do like how clay has much better type support and will come back when I have finished the biparsing package I am working on now.

Also, I see that clay has new maintainers, have you been refactoring/updating the core?

[turion]

@BebeSparkelSparkel Yes, I'm the new maintainer currently. (More would be welcome.) I haven't done any refactoring, and no plans to do that, since I'm no clay nor CSS expert. I currently only do the communication, PR reviews, keeping CI alive, and so on.

[turion]

Glad to hear you want to come back to clay :) Feel free to reopen this issue and work on it. Also, if you have bigger refactoring plans, I'll review them and work on them with you.

[JosephLucas]

Grid is a killer css feature. I would love to see it in Clay.

[turion]

@JosephLucas Ok, reopening due to reasonably popular request ;) do you have any good hints how to implement, or want to contribute a pull request?

[JosephLucas]

Currently I plan to use the "-:" ultra generic Clay operator. I don't even know if it's gonna work.

[JosephLucas]

body ? do 
    display        grid
    "grid-template" -: " \"header           header  \"  max-content  \n\
                       \ \"navbar           navbar  \"  max-content  \n\
                       \ \"sidebar          content \"  auto   \n\
                       \ \"footer           footer  \"  max-content /\n\
                       \   max-content      auto"

".header" ? do
    "grid-area"   -:  "header"

does the job.

I think will stick with it 😄 even though I'm sure that's not the way we are supposed to write clay expressions 😕

[turion]

@JosephLucas What does that code do? What CSS does it result in?

[JosephLucas]

The corresponding CSS code is

body {
  display: grid;
  grid-template: "header               header"      max-content
                 "navbar               navbar"      max-content
                 "sidebar              content"     auto
                 "footer               footer"      max-content
                  max-content          auto;
}

.header {
  grid-area:   header;
}

According to the syntax of grid, this CSS code creates a layout template with 4 rows and 2 columns. The first area of the template is named "header" (it's an area of the grid), it spans the first row and the two columns. "navbar" is the second row area. The "sidebar" area spans the cell of the grid at the third row and first column whereas the area at second column of this row is named "content". I let you guess what is the footer area.

[turion]

Ok, that makes sense. It would be a great addition to have a datatype corresponding to grid specifications and a module containing it with some useful operators. PRs welcome.

[turion]

Reopening because it's a popular requested feature.

[turion]

Hmmm I've configured the bot poorly. The issue should stay open.

[github-actions]

This issue has not seen any activity in a long time. If no further activity occurs, it will be closed after ten weeks.

[l-monnier]

Hi,

I've codded a different implementation for grid-row-start, grid-row-end, grid-column-start, grid-column-end, grid-row, grid-column and grid-area than the current pending pull-request.
Using type classes, the syntax is a bit closer to CSS, some examples:

gridArea 2
gridArea $ 2 // "nav"
gridArea $ ("nav", 2) // span_ 3 // 4

More examples can be found in the tests I've added in my branch:
https://github.com/l-monnier/clay/blob/master/spec/Clay/GridSpec.hs

If any interest, just let me know and I can further explain the pros/cons of the approach, ask some design questions, fine-tune the code and perform a pull request.

[turion]

Feel free to open a PR :)

[l-monnier]

Great thank you :-)

Just one question: how should the exceptions be implemented? I know from previous discussion threads that you would prefer the functions not to be partial. However, Clay is currently handling errors with partial functions. You also rightly mentioned that the situation with Clay is rather particular as people use Clay at init time (or at compile time using template Haskell), so a partial function in this case is not really problematic.

My proposal would be to:

• clearly document the functions as partial and the conditions under which they would fail;
• provide a safe version of the functions prefixed with "safe" returning an Either;
• create an Exceptions module with a sum type for the various exceptions which could be extended if someone would like to provide a safe version of a given function.

Let me know if that would work and I'll then come with a pull request in this spirit.

[turion]

That sounds great, but how about first doing only:

clearly document the functions as partial and the conditions under which they would fail;

After that we can see whether we need the two additional points.

[l-monnier]

Simpler! I'll perform the pull request once the partial functions are properly implemented.