mathiassm / sassdoc-theme-stysis Goto Github PK

That is, creating @component component-name rules to add info to components, like html examples, local palettes, uses and the like. If css rules and other elements can somehow link in a non-intrusive way to the component they belong to (or rather, have the component list what it depends on) the better.

Clean the SASS source code in the process.

Currently nothing is parsed. @color rules are the only way to define the brand colors. I'll like a easy-to-use system for managing brand colors (like a map of maps with useful utility functions). Something like that is currently being designed, but no implementation to parse the SassDoc-acquired code (for the map, for example) can be done until a decision is taken.

It would, of course, be an super opinionated system most would not like or use, so it's not that important. As this theme will be used in a side project, I'll keep this idea on the table, as it'd be great to have such functionality in that project.

Swig is no longer maintained and I don't like the idea of using dead software... I'm looking into alternatives like Pug, Haml and Handlebars...

Right now, I believe:

• The brand should be only one per project. Therefore, there should only be one global palette.
• Components should be able to have its own palettes (maybe as subsets of inherited colors, but that'd be a different awesome feature). For now, @colors are global.
• This theme should aim to showcase the three (3) most important colors, more prominently. Opinion: A palette (global or not) should have at most 5 colors... but may contain more.
• As there should be few colors, shades and tints of such colors should be displayed. Maybe toggled via yaml.
• Shades and tints should be configured by a different @-rule, like @shades. Opinion: Only one set per project should maintain consistency in branding.

First, I should learn how web designers usually organize a site's font stack. As far as I know, one or two fonts are usually what's used (with maybe a third for monospaced/code blocks. I therefore don't think localized fonts (per-component font declarations) should be a thing.

The biggest issue with documenting both things at the same time. I guess. It's a design dilemma.