4 ms·

Picnic is another very nice and compact option: https://picnicss.com/ https://picnicss.com/

by spking 6y ago

yellowapple 6y ago
I've been meaning to put picnic to use in future projects. I very much like the minimal reliance on JS and the semantic class names (nothing irks me quite like CSS concerns bleeding into the HTML).
- wuschel 6y ago
  What is the difference to Skeleton [1]? [1] https://skeleton-framework.github.io/ https://skeleton-framework.github.io/
  - dingdingdang 6y ago
    I can vouch for skeleton, modified a few variables (default page max-width not fit for modern monitors) and tweaked things to my liking but hurrah - base functionality makes for super simple & nice layout and works on everything from desktop to phone. Have no regrets on fact that it hasn't been updated for 4 years at present.
- naasking 6y ago
  > (nothing irks me quite like CSS concerns bleeding into the HTML) Don't knock it till you try it! If you're generating HTML dynamically, define functions in code for your custom style classes which consist of a set of atomic styles provided by something like Tachyons.css. Then just call those in your template while rendering. All the benefits of CSS variables and tooling like Sass/Less/etc. without the need for any special tooling!
  - yellowapple 6y ago
    Typically, by the time I'm at the point where I'm dynamically generating HTML, I'm also at the point where I've got enough tooling around it already that adding Sass/Less to the mix ain't much of a big deal.
    - naasking 6y ago
      So not only are you unnecessarily adding to your tools, but also unnecessarily adding to your build steps, which costs time every time you make any sort of visual change. Workflow under Tachyons: change html, reload page to see change, change html, reload, change html, reload, .... Workflow under Sass/Less/etc.: change css, build css, (maybe) change html, reload, change css, build css, (maybe) change html, reload, ...
      - yellowapple 6y ago
        > So not only are you unnecessarily adding to your tools, but also unnecessarily adding to your build steps, which costs time every time you make any sort of visual change. Most frameworks nowadays ship with Sass/Less built-in, or at the very least make it trivial to bolt it on. Further, most frameworks nowadays fully support the ability to automatically rebuild stylesheets when regenerating the HTML, in which case it's quite literally: change CSS, reload, change CSS, reload, etc. The build times are negligible (especially if I'm using Erlang/Elixir or C# or something else that needs compilation on changes anyway). Also, since I'm in the habit of keeping the HTML I write or generate concerned solely with describing the content rather than the appearance thereof, there's rarely (if ever) a separate "change HTML" step there; the HTML (or the templates to generate it) is already written alongside the content, and it's just a matter of adding enough CSS to make it look decent. Importantly, since the HTML makes no assumptions about its appearance, it's straightforward to define different stylesheets for different contexts (whether interactive v. print, or reusing a given page on multiple sites/applications with very different styles, or what have you).

Picnic is another very nice and compact option: https://picnicss.com/ https://picnicss.com/

by spking 6y ago

Picnic is another very nice and compact option: https://picnicss.com/ https://picnicss.com/

I've been meaning to put picnic to use in future projects. I very much like the minimal reliance on JS and the semantic class names (nothing irks me quite like CSS concerns bleeding into the HTML).

wuschel 6y ago
What is the difference to Skeleton [1]? [1] https://skeleton-framework.github.io/ https://skeleton-framework.github.io/
- dingdingdang 6y ago
  I can vouch for skeleton, modified a few variables (default page max-width not fit for modern monitors) and tweaked things to my liking but hurrah - base functionality makes for super simple & nice layout and works on everything from desktop to phone. Have no regrets on fact that it hasn't been updated for 4 years at present.
naasking 6y ago
> (nothing irks me quite like CSS concerns bleeding into the HTML) Don't knock it till you try it! If you're generating HTML dynamically, define functions in code for your custom style classes which consist of a set of atomic styles provided by something like Tachyons.css. Then just call those in your template while rendering. All the benefits of CSS variables and tooling like Sass/Less/etc. without the need for any special tooling!
- yellowapple 6y ago
  Typically, by the time I'm at the point where I'm dynamically generating HTML, I'm also at the point where I've got enough tooling around it already that adding Sass/Less to the mix ain't much of a big deal.
  - naasking 6y ago
    So not only are you unnecessarily adding to your tools, but also unnecessarily adding to your build steps, which costs time every time you make any sort of visual change. Workflow under Tachyons: change html, reload page to see change, change html, reload, change html, reload, .... Workflow under Sass/Less/etc.: change css, build css, (maybe) change html, reload, change css, build css, (maybe) change html, reload, ...
    - yellowapple 6y ago
      > So not only are you unnecessarily adding to your tools, but also unnecessarily adding to your build steps, which costs time every time you make any sort of visual change. Most frameworks nowadays ship with Sass/Less built-in, or at the very least make it trivial to bolt it on. Further, most frameworks nowadays fully support the ability to automatically rebuild stylesheets when regenerating the HTML, in which case it's quite literally: change CSS, reload, change CSS, reload, etc. The build times are negligible (especially if I'm using Erlang/Elixir or C# or something else that needs compilation on changes anyway). Also, since I'm in the habit of keeping the HTML I write or generate concerned solely with describing the content rather than the appearance thereof, there's rarely (if ever) a separate "change HTML" step there; the HTML (or the templates to generate it) is already written alongside the content, and it's just a matter of adding enough CSS to make it look decent. Importantly, since the HTML makes no assumptions about its appearance, it's straightforward to define different stylesheets for different contexts (whether interactive v. print, or reusing a given page on multiple sites/applications with very different styles, or what have you).