Conversation
|
Interesting solution to trim the prefix. That way we can migrate to bootstrap/ without impact or at least none that I can think of. Kinda like that solution, but this needs a comment or at the very least a commit message explanation on why this was done. |
| @@ -0,0 +1,6 @@ | |||
| module.exports = { | |||
| plugins: [ | |||
| require('tailwindcss'), | |||
There was a problem hiding this comment.
So tailwind needs postcss to function?
Is this a full requisite or mainly for changes?
I assume this will lead to errors on the user side, if they don't have postcss-cli installed again.
So hugo (non extended) should work, hugo extended without postcss might fail and hugo extended with the right packages should be fine. Any thoughts?
| @@ -0,0 +1,36 @@ | |||
| const colors = { | |||
There was a problem hiding this comment.
So tailwind.config.js would be in addition to style changes within config.toml? That sounds a bit more advanced. Can we grab the colors from config.toml instead?
Any other way to reduce the need to have a tailwind.config.js?
| {{- $sassTemplate := resources.Get "styles/index.scss" -}} | ||
| {{- $options := (dict "targetPath" "style.css" "outputStyle" "compressed" "enableSourceMap" true "includePaths" (slice "node_modules" "styles")) -}} | ||
| {{- $styleTemplated := $sassTemplate | resources.ExecuteAsTemplate "main.scss" . -}} | ||
| {{- $style := $styleTemplated | resources.ToCSS $options | resources.PostCSS | resources.Minify | resources.Fingerprint | resources.PostProcess }} |
There was a problem hiding this comment.
Note: PostCSS (needs to integrate the changes from #816, when merged)
| {{- $sassTemplate := resources.Get "styles/tailwind/index.scss" -}} | ||
| {{- $options := (dict "targetPath" "tailwind.css" "outputStyle" "compressed" "enableSourceMap" true "includePaths" (slice "node_modules" "styles")) -}} | ||
| {{- $styleTemplated := $sassTemplate | resources.ExecuteAsTemplate "main.scss" . -}} | ||
| {{- $style := $styleTemplated | resources.ToCSS $options | resources.PostCSS | resources.PostProcess }} |
There was a problem hiding this comment.
Note: PostCSS (needs to integrate the changes from #816, when merged)
|
This was just to try and implement a simpler fragment using the same design but using Tailwind. I have to figure out a way to simplify the "install" process. If the user doesn't have to do anything besides loading the fragment and configuring it, I'm way happier. If it's possible, move the tailwind config and try and figure out a way to handle postcss in another way. But still this PR is to show how a fragment using tailwind will be developed and used. Theme of the fragments need to be different IMO. Or we can implement the same designs and allowing the user to choose between them, kind of a basis for custom fragments, but I don't like that idea. I prefer a totally new theme. Tailwind UI would be awesome. Or I can go ahead and design a new theme. Colors have to be fetched from config.toml. Colors would be the same as Bootstrap by default, but IMO we can add recommended color schemes to docs, maybe even for Bootstrap. I'll continue working on Tailwind and "variants" if you agree with how the structure looks and how it's handled (except for colors not imported and postcss/tailwind config files), but let me know if you think a new theme should be developed or not. |
|
Generally agree with the direction. Question is what do you define as a new "theme"? |
|
A new style in general for the Tailwind variant, if we decide not to go with Tailwind UI or add Tailwind UI as another variant. Tailwind can be used to implement any style, Bootstrap style as well. We can implement the entire Bootstrap look using Tailwind or we can take this opportunity to create a new style. |
|
We could think of a new theme, but we also have to keep a check on the time spend as it's mainly duplicating functionality. I kinda like the thought of having a tailwindUI theme with all the things it enables or doesn't. |
|
Needs a rebase due to the dep updates, but you wanted to finalize the general design ideas before merge anyway or? |
|
I'm gonna extract the variant code and create a pr for that and will work on design and create a few fragment using that. So this pr will be a point of reference and shouldn't be merged. Is that a good plan? |
|
Sounds like a plan :)
…On Fri, Aug 7, 2020, 2:32 PM Mahdi Pourismaiel ***@***.***> wrote:
I'm gonna extract the variant code and create a pr for that and will work
on design and create a few fragment using that. So this pr will be a point
of reference and shouldn't be merged. Is that a good plan?
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
<#812 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA4YAXAJ4ZUI4ERZNJDJP2DR7PX43ANCNFSM4PHQSEUA>
.
|

What this PR does / why we need it:
Special notes for your reviewer:
Release note: